Re: Fedora 33 System-Wide Change proposal: Mark libdb as deprecated

[Petr Kubat]

On 4/2/20 8:34 AM, Panu Matilainen wrote:

On 4/1/20 8:37 PM, Richard W.M. Jones wrote:

On Mon, Mar 30, 2020 at 10:30:37AM -0400, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Libdb_deprecated

== Summary ==
This change should inform maintainers and developers about effort to
remove libdb in future.

== Owner ==
* Name: [[User:fjanus|Filip Januš]]
* Email: fja...@redhat.com


== Detailed Description ==
We would like to remove libdb from Fedora in future, because
BerkeleyDB 6.x has a more restrictive license than the previous
versions (AGPLv3 vs. LGPLv2) and due many projects can't use it.
Nowadays Fedora uses the old version (5.3.28) and we can't update to
newer. Due to many projects have libdb dependency, we propose few
steps to complete removal. First step would mark libdb as deprecated
package in Fedora 33. Next steps in Fedora 35 would provide converting
tool for existing databases and mark libdb as orphaned.


Is there a way to read old database files?

libguestfs uses libdb (actually utils like db_dump) in order to read
old RPM databases from old guests.  Since these old guests never go
away we'd like to continue to support them.  (And before anyone
mentions librpm, that just moves the problem around.)


Actually, at the end of last year RPM gained the ability to read BDB 
databases without libdb as an x-mas present from Michael Schroeder :)
That's the "bdb_ro" backend mentioned in rpm %changelog on the alpha 
snapshot update.


Rpm will autodetect the on-disk database but as long as real BDB is 
available, it'll use that. So for the time being, to test the 
readonly-backend you'll need to explicitly set the backend to bdb_ro with

--define "_db_backend bdb_ro".



BTW your list of dependencies didn't include libguestfs because the
dependency is indirect (via libdb-utils), so you probably missed other
packages as well.

Also I'm unclear why packaging BDB 6 is a problem.  What's wrong with
AGPLv3?  Still free software surely?


Plenty of material on the subject around the net, eg 
https://lwn.net/Articles/557820/


tldr: We could package it without any issues, as AGPLv3 is accepted by 
Fedora, but most current dependencies are not be able to use bdb6 it at 
all without license changes.


Petr




- Panu -



Rich.


___
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 33 System-Wide Change proposal: Mark libdb as deprecated

[Panu Matilainen]

On 4/1/20 8:37 PM, Richard W.M. Jones wrote:

On Mon, Mar 30, 2020 at 10:30:37AM -0400, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Libdb_deprecated

== Summary ==
This change should inform maintainers and developers about effort to
remove libdb in future.

== Owner ==
* Name: [[User:fjanus|Filip Januš]]
* Email: fja...@redhat.com


== Detailed Description ==
We would like to remove libdb from Fedora in future, because
BerkeleyDB 6.x has a more restrictive license than the previous
versions (AGPLv3 vs. LGPLv2) and due many projects can't use it.
Nowadays Fedora uses the old version (5.3.28) and we can't update to
newer. Due to many projects have libdb dependency, we propose few
steps to complete removal. First step would mark libdb as deprecated
package in Fedora 33. Next steps in Fedora 35 would provide converting
tool for existing databases and mark libdb as orphaned.


Is there a way to read old database files?

libguestfs uses libdb (actually utils like db_dump) in order to read
old RPM databases from old guests.  Since these old guests never go
away we'd like to continue to support them.  (And before anyone
mentions librpm, that just moves the problem around.)


Actually, at the end of last year RPM gained the ability to read BDB 
databases without libdb as an x-mas present from Michael Schroeder :)
That's the "bdb_ro" backend mentioned in rpm %changelog on the alpha 
snapshot update.


Rpm will autodetect the on-disk database but as long as real BDB is 
available, it'll use that. So for the time being, to test the 
readonly-backend you'll need to explicitly set the backend to bdb_ro with

--define "_db_backend bdb_ro".



BTW your list of dependencies didn't include libguestfs because the
dependency is indirect (via libdb-utils), so you probably missed other
packages as well.

Also I'm unclear why packaging BDB 6 is a problem.  What's wrong with
AGPLv3?  Still free software surely?


Plenty of material on the subject around the net, eg 
https://lwn.net/Articles/557820/


- Panu -



Rich.


___
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 32 compose report: 20200401.n.1 changes

[Fedora Branched Report]

OLD: Fedora-32-20200330.n.1
NEW: Fedora-32-20200401.n.1

= SUMMARY =
Added images:0
Dropped images:  6
Added packages:  34
Dropped packages:3
Upgraded packages:   143
Downgraded packages: 0

Size of added packages:  77.46 MiB
Size of dropped packages:82.69 MiB
Size of upgraded packages:   8.34 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-32-20200330.n.1.s390x.tar.xz
Image: Container_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Base-32-20200330.n.1.s390x.tar.xz
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-32-20200330.n.1.s390x.raw.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-32-20200330.n.1.s390x.qcow2
Image: Everything boot s390x
Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-32-20200330.n.1.iso
Image: Cloud_Base vmdk s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-32-20200330.n.1.s390x.vmdk

= ADDED PACKAGES =
Package: catharsis-cormorant-fonts-3.602-2.20200316git83d1fa9.fc32
Summary: Cormorant, a display serif font family inspired by the Garamond 
heritage
RPMs:catharsis-cormorant-fonts catharsis-cormorant-fonts-all 
catharsis-cormorant-fonts-doc catharsis-cormorant-garamond-fonts 
catharsis-cormorant-infant-fonts catharsis-cormorant-unicase-fonts 
catharsis-cormorant-upright-fonts
Size:7.21 MiB

Package: elementary-planner-2.2.14-1.fc32
Summary: Task manager with Todoist support designed for GNU/Linux
RPMs:elementary-planner
Size:3.65 MiB

Package: feedbackd-0.0.0+git20200305-1.fc32
Summary: Feedback library for GNOME
RPMs:feedbackd feedbackd-devel
Size:518.04 KiB

Package: fixedptc-0-6.20200228hgb8acfec.fc32
Summary: Fixed point math header only library for C
RPMs:fixedptc-devel
Size:12.93 KiB

Package: gap-pkg-qpa-1.30-2.fc32
Summary: GAP package for quivers and path algebras
RPMs:gap-pkg-qpa gap-pkg-qpa-doc
Size:1.83 MiB

Package: google-rubik-fonts-2.100-2.20200314git2e360a2.fc32
Summary: Rubik, a sans serif font family with slightly rounded corners
RPMs:google-rubik-fonts
Size:818.55 KiB

Package: js-d3-flame-graph-3.0.2-1.fc32
Summary: A D3.js plugin that produces flame graphs
RPMs:js-d3-flame-graph js-d3-flame-graph-doc
Size:224.82 KiB

Package: libjcat-0.1.0-1.fc32
Summary: Library for reading Jcat files
RPMs:libjcat libjcat-devel libjcat-tests
Size:918.30 KiB

Package: ndiscover-exo-2-fonts-1.100-2.20200316git55728cf.fc32
Summary: Exo 2, a contemporary geometric sans serif font family
RPMs:ndiscover-exo-2-fonts
Size:643.41 KiB

Package: ocaml-zmq-5.1.3-1.fc32
Summary: ZeroMQ bindings for OCaml
RPMs:ocaml-zmq ocaml-zmq-devel ocaml-zmq-doc ocaml-zmq-lwt 
ocaml-zmq-lwt-devel
Size:2.05 MiB

Package: osbuild-composer-8-1.fc32
Summary: An image building service based on osbuild
RPMs:osbuild-composer osbuild-composer-rcm osbuild-composer-worker
Size:28.74 MiB

Package: ossobuffo-jura-fonts-5.103-3.20200314git6e2614a.fc32
Summary: Jura, a sans-serif font family in the Eurostile vein
RPMs:ossobuffo-jura-fonts ossobuffo-jura-fonts-doc
Size:4.53 MiB

Package: php-marcusschwarz-lesserphp-0.5.4-5.fc32
Summary: A compiler for LESS written in PHP
RPMs:php-marcusschwarz-lesserphp
Size:47.82 KiB

Package: production-type-spectral-fonts-2.003-2.20200314git748733e.fc32
Summary: Spectral, an efficient and versatile serif font family
RPMs:production-type-spectral-fonts
Size:1.09 MiB

Package: python-ailment-8.20.1.7-1.fc32
Summary: The angr intermediate language
RPMs:python3-ailment
Size:37.36 KiB

Package: python-aiorestapi-0.1.1-1.fc32
Summary: Rapid rest resources for aiohttp
RPMs:python3-aiorestapi
Size:15.13 KiB

Package: python-ana-0.06-1.fc32
Summary: Python module to provide easy distributed data storage
RPMs:python3-ana
Size:19.71 KiB

Package: python-archinfo-8.20.1.7-1.fc32
Summary: Collection of classes that contain architecture-specific information
RPMs:python3-archinfo
Size:86.02 KiB

Package: python-jack-client-0.5.2-1.fc32
Summary: JACK Audio Connection Kit (JACK) Client for Python
RPMs:python-jack-client
Size:55.86 KiB

Package: python-nikola-8.0.4-9.fc32
Summary: A modular, fast, simple, static website and blog generator
RPMs:nikola python-nikola-doc python3-nikola
Size:1.64 MiB

Package: python-pytest-subtests-0.3.0-1.fc32
Summary: Support for unittest subTest() and subtests fixture
RPMs:python3-pytest-subtests
Size:16.51 KiB

Package: python-sphinx-press-theme-0.5.1-4.fc32
Summary: A Sphinx-doc theme based on Vuepress
RPMs:python3-sphinx-press-theme
Size:66.46 KiB

Package: raysession-0.8.3-1.fc32
Summary: Session manager for audio software
RPMs

Re: CPE Git Forge Decision

[Randy Barlow]

On 4/1/20 1:16 PM, Adam Williamson wrote:

Has it been demonstrated that either Pagure or Gitlab CE are
"not viable" for the purposes Fedora needs?


Hey Adam!

I agree with you that Pagure and Gitlab CE are both viable for Fedora's 
needs in terms of feature matrices and requirements. We have shipped a 
handful or so of Fedora releases over the last 3ish years since src.fpo 
came online as proof!


However, the CPE team does not have the resources to do a good job on 
maintaining that system, and Bodhi, and Koji, and the 187 other apps (I 
think we did count the apps we maintained at one point and ended up with 
a list that was about 190 long!). The responsibility to engineer ratio 
is not healthy or sustainable.


I agree with the sentiment that this decision process was not done in 
the open. There was a thread on a Fedora Council mailing list, but I 
personally was not aware of the existence of that list until someone 
linked that thread here, and I expect that most of the Fedora community 
probably does not closely monitor that list. Thus, I don't think that 
really counts as a venue for open discussion with the community.


I expected to see discussion about it here, on this list, because this 
is where all of the users for the proposed system can reasonably 
expected to be. I also expected that discussion to allow community 
members to be meaningfully involved in the process: requirement 
gathering, analysis, proposals, counter proposals, counter counter 
proposals, etc. That's what an open decision process would have looked 
like in my opinion.

___
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-32-20200401.n.1 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/171 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-32-20200330.n.1):

ID: 564129  Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/564129
ID: 564196  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/564196

Old failures (same test failed in Fedora-32-20200330.n.1):

ID: 564132  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/564132
ID: 564154  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/564154
ID: 564167  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/564167
ID: 564191  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/564191

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

Old soft failures (same test soft failed in Fedora-32-20200330.n.1):

ID: 564088  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/564088
ID: 564089  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/564089
ID: 564093  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/564093
ID: 564097  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/564097
ID: 564100  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/564100
ID: 564101  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/564101
ID: 564123  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/564123
ID: 564146  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/564146
ID: 564148  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/564148
ID: 564180  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/564180
ID: 564202  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/564202
ID: 564212  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/564212
ID: 564221  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/564221
ID: 564230  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/564230
ID: 564246  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/564246
ID: 564254  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/564254
ID: 564255  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/564255
ID: 564258  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/564258
ID: 564260  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/564260

Passed openQA tests: 147/171 (x86_64)

New passes (same test not passed in Fedora-32-20200330.n.1):

ID: 564126  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/564126
ID: 564238  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/564238
ID: 564257  Test: x86_64 universal install_pxeboot
URL: https://openqa.fedoraproject.org/tests/564257

Skipped non-gating openQA tests: 1 of 173

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
1 packages(s) added since previous compose: tcl
1 packages(s) removed since previous compose: jimtcl
4 services(s) added since previous compose: plymouth-quit-wait.service, 
plymouth-quit.service, plymouth-read-write.service, plymouth-start.service
Previous test data: https://openqa.fedoraproject.org/tests/562143#downloads
Current test data: https://openqa.fedoraproject.org/tests/564088#downloads

Installed system changes in test x86_64 Server-boot-iso install_default: 
1 packages(s) added since previous compose: tcl
1 packages(s) removed since previous compose: jimtcl
4 services(s) added since previous compose: plymouth-quit-wait.service, 
plymouth-quit.service, plymouth-read-write.service, plymouth-start.service
Previous test data: https://openqa.fedoraproject.org/tests/562144#downloads
Current test data: https://openqa.fedoraproject.org/tests/564089#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
1 packages(s) added since previous compose: pcre2-syntax
Previous test data: https://openqa.fedoraproject.org/tests/562148#downloads
Current test data: https://ope

Re: CPE Git Forge Decision

[Randy Barlow]

On 4/1/20 11:25 AM, Felix Schwarz wrote:

I don't want to presume too much but I just hope you researched why packagedb
was decommissioned and why people thought integrating the functionality into
pagure was a good idea?


pkgdb was decommissioned because modularity needed a lot of changes 
across the infrastructure, and pkgdb was in a state that made it 
expensive to alter (or even to maintain). That said, I do miss how 
things were back when we had pkgdb. I wish we had been able to rewrite 
or rebase it rather than eliminate it.


I personally think keeping package data separate from the git data makes 
sense (i.e., having a generic git server, and a separate app like pkgdb 
to do Fedora package specific things). Then the git server can just be 
an off-the-shelf program, and infrastructure can focus solely on 
maintaining the code that is unique to Fedora's needs.

___
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

[Test-Announce] Fedora 32 Branched 20200401.n.1 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 32 Branched 20200401.n.1. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
pungi - 20200322.n.0: pungi-4.2.0-1.fc32.src, 20200401.n.1: 
pungi-4.2.1-2.fc32.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/32

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200401.n.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200401.n.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200401.n.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200401.n.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200401.n.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200401.n.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200401.n.1_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@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: CPE Git Forge Decision

[Adam Williamson]

On Wed, 2020-04-01 at 20:16 -0400, Paul Frields wrote:
> On Wed, Apr 1, 2020, 7:53 PM Michael Catanzaro  wrote:
> 
> > On Wed, Apr 1, 2020 at 3:39 pm, Chris Murphy 
> > wrote:
> > > Is the FOSS position adequately represented on the Council?
> > 
> >  From my reading of [1], the Council decision is that we use FOSS in
> > our infrastructure except where it is "not viable and not available."
> > In the case of dist-git, it seems undeniable that FOSS is both viable
> > and available (whether it's Pagure or GitLab CE). Council hasn't
> > actually approved a move to a proprietary version of GitLab yet afaik.
> > 
> > [1]
> > 
> > https://meetbot-raw.fedoraproject.org/teams/council/council.2020-04-01-14.00.log.html
> 
> For a solution to be viable it needs to meet requirements.

Sure. That's just a re-statement of the question. Are there Fedora
requirements here which are met by proprietary Gitlab but not by Gitlab
CE or Pagure?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

[Solomon Peachy]

On Wed, Apr 01, 2020 at 08:16:29PM -0400, Paul Frields wrote:
> > https://meetbot-raw.fedoraproject.org/teams/council/council.2020-04-01-14.00.log.html
> 
> For a solution to be viable it needs to meet requirements.

By that standard, GitLab (in any guise) must be excluded as well.

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
High Springs, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


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: CPE Git Forge Decision

[Paul Frields]

On Wed, Apr 1, 2020, 7:53 PM Michael Catanzaro  wrote:

> On Wed, Apr 1, 2020 at 3:39 pm, Chris Murphy 
> wrote:
> > Is the FOSS position adequately represented on the Council?
>
>  From my reading of [1], the Council decision is that we use FOSS in
> our infrastructure except where it is "not viable and not available."
> In the case of dist-git, it seems undeniable that FOSS is both viable
> and available (whether it's Pagure or GitLab CE). Council hasn't
> actually approved a move to a proprietary version of GitLab yet afaik.
>
> [1]
>
> https://meetbot-raw.fedoraproject.org/teams/council/council.2020-04-01-14.00.log.html


For a solution to be viable it needs to meet requirements.

-- 
Paul
___
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: CPE Git Forge Decision

[clime]

On Wed, 1 Apr 2020 at 23:22, Paul Frields  wrote:
>
> On Wed, Apr 1, 2020 at 7:03 AM Neal Gompa  wrote:
> >
> > On Wed, Apr 1, 2020 at 6:52 AM Nicolas Mailhot via devel
> >  wrote:
> > >
> > > Le mercredi 01 avril 2020 à 11:30 +0100, Leigh Griffin a écrit :
> > > >
> > > > To distill it down:
> > > >
> > > > - Gitlab has more features that are needed right now for our
> > > > stakeholder group
> > > > - Gitlab has an entire company dedicated to roadmap features, we do
> > > > not.
> > >
> > > Unfortunately, Gitlab’s roadmap is also conflicting with Fedora
> > > objectives. The bread and butter of Gitlab is intermediating between
> > > devs and end users, culling free software intermediaries like
> > > distributions, and positionning itself in their stead. That is unlikely
> > > to result in any commitment to making distribution workflows work.
> > >
> > > That would not be a problem if the disintermediation worked, but like
> > > many actors Gitlab sees the $$$ and power in being the
> > > desintermediator, and does not care if the result is deffective, as
> > > long as $$$ and power flows its way.
> > >
> >
> > It's also important to note that at the core of GitLab's incentive
> > model is that they want to remove incentives to use FOSS solutions in
> > favor of their unified proprietary solution. They are constantly
> > integrating features and capabilities into the proprietary parts to
> > make it "juicier" for enterprises who don't really have a compunction
> > about whether they are using Free Software solutions or not, or even
> > may not be willing to support them if it was Free Software because of
> > outmoded thinking.
> >
> > The consequence of this is that it starves interest and development in
> > FOSS solutions, and contributes to making the FOSS ecosystem weaker
> > over time.
>
> That statement rings hollow for me, when Github is arguably the single
> biggest vendor of open source in the world, no part of itself is open
> source, and thanks to its pervasiveness, open source has won the war
> of how development should work.

This is imho a contradictory statement. Github, being closed source
and pervasive, is a proof that open-source has won?

No, the trend obviously is to give up some open-source community part
to get people hooked-in and then earn money on the proprietary version
of the product which has more features.

I am not saying it is wrong but it is clearly something else than
"open source has won the war of how development should work".

But what we are solving here is not about some
closed-source/open-source battle, it's about Fedora keeping its
autonomy and values. Of course, Fedora going for a proprietary
solution also _doesn't_ show that "open source has won the war of how
development should work".

>
> > It wouldn't surprise me if not many people at Red Hat sat down and
> > thought seriously about that particular consequence, because it's not
> > exactly an obvious one.
>
> I don't know how many people do, since it's a growing company. I
> assure you some of us do. :-)
>
> > > At heart, Fedora is a tooling project. It’s a collective of people that
> > > chose to use a specific integration toolchain. Anything involved in
> > > creating Fedora packages cuts deep into the project core. (unlike, say,
> > > calendaring).
> > >
> > > It’s easy to forget this when making tooling decisions,
> > > because it is so pervasive, most do not see it anymore. Tooling is
> > > anything but accessory to the project.
> > >
> >
> > Exactly. This is a huge part of why people are so upset over this,
> > because if you take away our tools, you take away the reason to be
> > passionate about Fedora. And thus, you remove why people use and
> > contribute to Fedora in the first place.
>
> My reason for being passionate about Fedora is mainly about helping
> people use the software and content we provide in ways that serve
> their needs and solve their problems. To do that, I use Inkscape[1],
> Wordpress[2], and Ansible[3] a lot.
>
> [1] https://gitlab.com/inkscape/inkscape
> [2] https://github.com/WordPress/wordpress-develop
> [3] https://github.com/ansible/ansible

That's nice, some people, on the other hand, are passionate about the
way Fedora is able to deliver that software - it delivers it while at
the same time helping the open-source software by using it.

>
>
> --
> Paul
> ___
> 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:/

Re: Orphaned packages looking for new maintainers

[Sérgio Basto]

On Wed, 2020-03-18 at 14:20 +, Sérgio Basto wrote:
> On Mon, 2020-03-16 at 23:44 +0100, Miro Hrončok wrote:
> > sergiomb: maven-injection-plugin, cpptasks, netty, lzma-java, lz4-
> > java, 
> > jetty-alpn-api, randomizedtesting, aalto-xml, mvel, os-maven-
> > plugin, 
> 
> all this packages are related with batik. I think, I will orphan
> batik
> , IIRC it will give 512 packages with broken deps .

I just orphan batik , ENOTIME for it . 

-- 
Sérgio M. B.
___
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 FTBFS packages to be orphaned in 1 week

[Sérgio Basto]

On Wed, 2020-04-01 at 15:31 +0100, Ian McInerney wrote:
> > x11vnc   hubbitus
>  
> It looks like this one just needs a new build kicked off for Rawhide
> and the Rawhide spec merged into f32, since it was a GCC10 failure
> and it appears the spec has been fixed for rawhide since then.

yep , my pull request was merged [1] but no build with it. 
[1] 
https://src.fedoraproject.org/rpms/x11vnc/pull-requests?status=Merged
> -Ian  
> 
> ___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
-- 
Sérgio M. B.

___
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: CPE Git Forge Decision

[Michael Catanzaro]

On Wed, Apr 1, 2020 at 3:39 pm, Chris Murphy  
wrote:

Is the FOSS position adequately represented on the Council?


From my reading of [1], the Council decision is that we use FOSS in 
our infrastructure except where it is "not viable and not available." 
In the case of dist-git, it seems undeniable that FOSS is both viable 
and available (whether it's Pagure or GitLab CE). Council hasn't 
actually approved a move to a proprietary version of GitLab yet afaik.


[1] 
https://meetbot-raw.fedoraproject.org/teams/council/council.2020-04-01-14.00.log.html


___
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: CPE Git Forge Decision

[clime]

On Wed, 1 Apr 2020 at 21:12, Kevin Fenzi  wrote:
>
> On Wed, Apr 01, 2020 at 11:51:01AM +0200, clime wrote:
> > On Wed, 1 Apr 2020 at 10:54, Vít Ondruch  wrote:
> > > Do you mean https://github.com/fedora-infra/pkgdb2/ ? :)
>
> No.
>
> > This is just hilarious, so after going all pagure for dist-git and
> > making it all work, we will now go back to pkgdb, additionally with
> > proprietary git backend, lol.
>
> But pagure doesn't "just work". There's pagure-dist-git that does all
> kinds of things to make src.fedoraproject.org have different things than
> pagure.io.
>
> Do you consider pagure-dist-git to be pkgdb 1.5?
>
> You missed where I said we should adjust our workflow and try and
> minimize this layer. I wasn't suggesting we just make another app in
> front of the git forge. I was suggesting we move all our "special" stuff
> into git or otherwise adjust our workflow to make such a layer
> nonexistant or as small as we can.
>
> How could we do that?
>
> Well, there was the suggestion from Jermey that we use tags to store
> this 'distro metadata'. Or perhaps we have files in each git repo, or a
> branch or a seperate repo. This would not only mean we have less to
> maintain, but it would mean we could move things much easier, people
> could mirror them to another gitforge much easier, etc.
>
> > I mean if there is some alien race (or a human competitor) watching
> > what is happening in one of the leading linux distributions, they must
> > laugh hard. Well, we soon won't be leading.
>
> I think you are misunderstanding me, but sure, laugh away. If you can't
> laugh, you have to cry. ;)

I am all for thinning the layer around our base by using git metadata
or files where possible but some things cannot be done by it like e.g.
links to builds for a given commit, list of actual releases from
bodhi, the bugzilla integration etc. But I think it could be suitable
e.g. for PDC data.

I mean keeping things defined in git is a great goal and it would
definitely help to make things minimal. And keeping the tooling
footprint minimal can help us to keep our open-source spirit.

Anyway, I admit I didn't really understand your email. What you
suggested is a good thing to do - a good technological direction but I
don't want to be doing this on a proprietary platform that belongs to
someone else. That seems to be a huge cut into our identity.

pagure is a very well written technology (with a few UI quirks
perhaps) and we should be proud of it and continue improving it. A
decision like this is likely to make it dead, I mean, guys in the blog
post tried to draw some rainbows but we all know what's going to
happen.

I also think it is sufficient for our needs, whatever the mentioned
"stakeholders" wanted I am sure can be done with quite a little effort
if the requirements are very well specified. Imho, we should do that
instead of immediately switching to some enterprise external hosting
that doesn't align with our culture (at least according my view of
Fedora, I started to use fedora since around .fc3 and it was a cool
and inspiring distribution to me ever since, such feeling can change
for new-comers if we don't keep our values).

clime

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

Fedora rawhide compose report: 20200401.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200330.n.1
NEW: Fedora-Rawhide-20200401.n.0

= SUMMARY =
Added images:0
Dropped images:  4
Added packages:  17
Dropped packages:24
Upgraded packages:   212
Downgraded packages: 0

Size of added packages:  86.16 MiB
Size of dropped packages:352.99 MiB
Size of upgraded packages:   7.95 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   70.27 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200330.n.1.ppc64le.qcow2
Image: Cloud_Base vmdk ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200330.n.1.ppc64le.vmdk
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20200330.n.1.iso
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200330.n.1.ppc64le.raw.xz

= ADDED PACKAGES =
Package: elementary-planner-2.2.14-1.fc33
Summary: Task manager with Todoist support designed for GNU/Linux
RPMs:elementary-planner
Size:3.65 MiB

Package: gnome-extensions-app-3.36.1-1.fc33
Summary: Manage GNOME Shell extensions
RPMs:gnome-extensions-app
Size:439.40 KiB

Package: golang-github-resty-2.2.0-2.fc33
Summary: Simple HTTP and REST client library
RPMs:golang-github-resty-devel
Size:52.12 KiB

Package: hledger-ui-1.14.2-1.fc33
Summary: Curses-style user interface for the hledger accounting tool
RPMs:hledger-ui
Size:32.98 MiB

Package: httprobe-0.1.2-1.fc33
Summary: Probing tool for working HTTP and HTTPS servers
RPMs:golang-github-tomnomnom-httprobe-devel httprobe
Size:9.30 MiB

Package: komikku-0.13.0-1.fc33
Summary: Online/offline manga reader for GNOME
RPMs:komikku
Size:400.18 KiB

Package: man-pages-l10n-4.0.0-1.20200322gitbff338d.fc33
Summary: Translated man pages from the Linux Documentation Project and other 
software projects
RPMs:man-pages-de man-pages-fr man-pages-nl man-pages-pt_BR man-pages-ro
Size:4.01 MiB

Package: pkgtreediff-0.4-1.fc33
Summary: Package tree diff tool
RPMs:pkgtreediff
Size:27.65 MiB

Package: pulseaudio-qt-1.2-1.fc33
Summary: Qt bindings for PulseAudio
RPMs:pulseaudio-qt pulseaudio-qt-devel
Size:719.12 KiB

Package: python-ajpy-0.0.4-1.fc33
Summary: AJP package crafting library
RPMs:python3-ajpy
Size:17.89 KiB

Package: python-fs-2.4.11-2.fc33
Summary: Python's Filesystem abstraction layer
RPMs:python3-fs
Size:202.42 KiB

Package: python-plugnplay-0.5.4-1.fc33
Summary: A generic plug-in system for Python
RPMs:python3-plugnplay
Size:22.59 KiB

Package: rust-assert_cmd-1.0.1-1.fc33
Summary: Test CLI Applications
RPMs:rust-assert_cmd+default-devel rust-assert_cmd-devel
Size:38.66 KiB

Package: rust-extend-0.1.1-1.fc33
Summary: Create extensions for types you don't own
RPMs:rust-extend+default-devel rust-extend-devel
Size:24.82 KiB

Package: rust-flume-0.7.1-1.fc33
Summary: Blazingly fast multi-producer channel
RPMs:rust-flume+async-devel rust-flume+default-devel 
rust-flume+futures-devel rust-flume+select-devel rust-flume-devel
Size:49.27 KiB

Package: ulauncher-5.7.0-1.fc33
Summary: Linux Application Launcher
RPMs:ulauncher
Size:1.50 MiB

Package: wicked-0.6.63-1.fc33
Summary: Network configuration infrastructure
RPMs:libwicked wicked wicked-devel
Size:5.15 MiB


= DROPPED PACKAGES =
Package: apache-commons-jexl-2.1.1-25.fc32
Summary: Java Expression Language (JEXL)
RPMs:apache-commons-jexl apache-commons-jexl-javadoc
Size:308.47 KiB

Package: appframework-1.03-22.fc31
Summary: Swing Application Framework
RPMs:appframework appframework-javadoc
Size:240.83 KiB

Package: bean-validation-api-2.0.1-2.fc32
Summary: Bean Validation API (JSR 349)
RPMs:bean-validation-api bean-validation-api-javadoc
Size:235.42 KiB

Package: clang8.0-8.0.0-8.fc32
Summary: A C language family front-end for LLVM
RPMs:clang8.0-devel clang8.0-libs
Size:89.71 MiB

Package: cuneiform-1.1.0-29.fc31
Summary: Command-line OCR system
RPMs:cuneiform cuneiform-devel
Size:137.87 MiB

Package: freemarker-2.3.29-3.fc33
Summary: The Apache FreeMarker Template Engine
RPMs:freemarker freemarker-javadoc
Size:1.84 MiB

Package: geronimo-jta-1.1.1-27.fc32
Summary: J2EE JTA v1.1 API
RPMs:geronimo-jta geronimo-jta-javadoc
Size:63.55 KiB

Package: gnome-shell-extension-taskwarrior-4.0-6.fc32
Summary: Taskwarrior integration for GNOME
RPMs:gnome-shell-extension-taskwarrior
Size:486.41 KiB

Package: golang-github-osbuild-composer-8-2.fc33
Summary: An image building service based on osbuild
RPMs:golang-github-osbuild-composer golang-github-osbuild-composer-rcm 
golang-github-osbuild-composer-tests golang-github-osbuild-composer-worker
Size:61.45 MiB

Package: jmol-14.6.0-8.2016.06.30.fc33
Summary: An open-source Java viewer fo

Re: CPE Git Forge Decision

[Chris Murphy]

On Wed, Apr 1, 2020 at 6:39 AM Stephen John Smoogen  wrote:
>
>
>
> On Wed, 1 Apr 2020 at 08:16, Pierre-Yves Chibon  wrote:
>>
>> On Wed, Apr 01, 2020 at 11:49:41AM +0200, Clement Verna wrote:
>> >There is also an historical taste to write in house applications for
>> >things that don't really seems critical to the Fedora Project, for 
>> > example
>> >do we really need a custom calendar application ? or election 
>> > application
>> >? It seems that every time we have a problem the solution is let's write
>> >something to solve that problem, instead of trying to find a compromise
>> >and reuse existing solutions.
>>
>> Could please stop this?
>>
>
> This is me also asking this.
>
>
>>
>> The continuous theme of "we're building things because we like it" is unfair 
>> to
>> all the people who have been involved in the infrastructure at some point in 
>> the
>> past.
>> It is assuming that there was no reasons, that they did not do their 
>> research,
>> that they didn't think it through.
>>
>> The requirements for applications 3 years ago were vastly different from what
>> they are today.
>> If you don't know the historical reasons for an app, there are a number of
>> people around who can answer them, but please let's stop assuming things 
>> which
>> are at the end of the day insulting and demotivating for the people who were
>> involved then and are still now.
>>
>> This goes for fedocal, for pagure, for anitya. I've seen this question come 
>> up
>> often enough (here and elsewhere): "Why aren't we using libraries.io instead 
>> of
>> anytia?"
>> Well, the simple reason is: because libraries.io *did* *not* *exist* when 
>> anitya
>> was created. So maybe we are not the bad ones that didn't do their research.
>>
>
> I am also sick and tired of this. For many years, a central drive for Fedora 
> Infra was about building the Free and Open Source tools to allow a community 
> to work together without using closed source tools. This was a constant 
> requirement of the community to us at the time with wanting something to 
> 'compete' against Canonical's forge and Canonicals' other tools. Things have 
> changed but instead of saying "Good job, thanks for all that work but we have 
> decided to change.", our efforts are brought up constantly as a bunch of NIH 
> who wasted time and effort. And it doesn't matter how many times people are 
> reminded that we had reasons and research for doing this from 2005 to 2015.. 
> it gets thrown in our faces that we reinvented the wheel when there were 
> clearly better things to spend our time on.
>

Is the FOSS position adequately represented on the Council?

-- 
Chris Murphy
___
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: ocaml-zip update

[Jerry James]

On Wed, Apr 1, 2020 at 11:26 AM Richard W.M. Jones  wrote:
> Right, this change was made by Olaf (and I reviewed it), see:
>
>   https://github.com/rpm-software-management/rpm/issues/913
>
> We may well need to rebuild everything to handle this.
>
> Olaf - did you have to rebuild all OCaml packages in SUSE after
> you did this?  Anything else we need to be aware of?

Okay, I'm just going to check my changes into git for now then and let
any such rebuild make it all work together again.  Thanks,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

[Paul Frields]

On Wed, Apr 1, 2020 at 7:03 AM Neal Gompa  wrote:
>
> On Wed, Apr 1, 2020 at 6:52 AM Nicolas Mailhot via devel
>  wrote:
> >
> > Le mercredi 01 avril 2020 à 11:30 +0100, Leigh Griffin a écrit :
> > >
> > > To distill it down:
> > >
> > > - Gitlab has more features that are needed right now for our
> > > stakeholder group
> > > - Gitlab has an entire company dedicated to roadmap features, we do
> > > not.
> >
> > Unfortunately, Gitlab’s roadmap is also conflicting with Fedora
> > objectives. The bread and butter of Gitlab is intermediating between
> > devs and end users, culling free software intermediaries like
> > distributions, and positionning itself in their stead. That is unlikely
> > to result in any commitment to making distribution workflows work.
> >
> > That would not be a problem if the disintermediation worked, but like
> > many actors Gitlab sees the $$$ and power in being the
> > desintermediator, and does not care if the result is deffective, as
> > long as $$$ and power flows its way.
> >
>
> It's also important to note that at the core of GitLab's incentive
> model is that they want to remove incentives to use FOSS solutions in
> favor of their unified proprietary solution. They are constantly
> integrating features and capabilities into the proprietary parts to
> make it "juicier" for enterprises who don't really have a compunction
> about whether they are using Free Software solutions or not, or even
> may not be willing to support them if it was Free Software because of
> outmoded thinking.
>
> The consequence of this is that it starves interest and development in
> FOSS solutions, and contributes to making the FOSS ecosystem weaker
> over time.

That statement rings hollow for me, when Github is arguably the single
biggest vendor of open source in the world, no part of itself is open
source, and thanks to its pervasiveness, open source has won the war
of how development should work.

> It wouldn't surprise me if not many people at Red Hat sat down and
> thought seriously about that particular consequence, because it's not
> exactly an obvious one.

I don't know how many people do, since it's a growing company. I
assure you some of us do. :-)

> > At heart, Fedora is a tooling project. It’s a collective of people that
> > chose to use a specific integration toolchain. Anything involved in
> > creating Fedora packages cuts deep into the project core. (unlike, say,
> > calendaring).
> >
> > It’s easy to forget this when making tooling decisions,
> > because it is so pervasive, most do not see it anymore. Tooling is
> > anything but accessory to the project.
> >
>
> Exactly. This is a huge part of why people are so upset over this,
> because if you take away our tools, you take away the reason to be
> passionate about Fedora. And thus, you remove why people use and
> contribute to Fedora in the first place.

My reason for being passionate about Fedora is mainly about helping
people use the software and content we provide in ways that serve
their needs and solve their problems. To do that, I use Inkscape[1],
Wordpress[2], and Ansible[3] a lot.

[1] https://gitlab.com/inkscape/inkscape
[2] https://github.com/WordPress/wordpress-develop
[3] https://github.com/ansible/ansible


--
Paul
___
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: Why is "local" insecure PATH element ?

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 01, 2020 at 09:57:25PM +0200, Lukas Czerner wrote:
> On Wed, Apr 01, 2020 at 11:26:04AM -0700, Samuel Sieb wrote:
> > On 4/1/20 4:27 AM, Lukas Czerner wrote:
> > > I've noticed some failures in automated tests in bodhi, specifically
> > > this one:
> > > 
> > >  {
> > > "arch" : "x86_64",
> > > "code" : "SuspiciousPath",
> > > "context" : {
> > > "excerpt" : [
> > >"PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
> > > ],
> > > "path" : "/usr/sbin/e2scrub"
> > > },
> > > "diag" : "Potentially insecure PATH element /local",
> > > "subpackage" : "e2scrub"
> > >  },
> > > 
> > > I am not sure why it's considered insecure while on all of the Fedora
> > > and RHEL systems I have available "/usr/local/sbin:/usr/local/bin" is a
> > > default part of the PATH.
> > 
> > You don't want a system script to be looking for executables in /usr/local
> > before the regular bin directories.  And it's probably better that it
> > doesn't look in /usr/local at all.
> > It's fine for the admin to put extra things in /usr/local, but those paths
> > don't override the system ones.
> 
> Thanks, that's understandable, but then why the PATH on my system is
> 
> /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
> 
> or
> 
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
> 
> all the systems I try include /usr/local in the PATH.

Yes. And in fact, most of packaged software that uses calls other
binaries will use $PATH to find the appropriate binary, so taking care
to just limit the first "step", i.e. call the first binary by full
path is generally pointless.

There was this pattern in rpm packaging to call utilities with
full path, e.g. %__make which expands to /usr/bin/make, completely
ignoring the fact that make will immediately fork other binaries,
also including make!, using $PATH.

For the systemd package, this warning is emitted because systemd uses
a path including /usr/local to look for executables. systemd looks for
*units* in /usr/local/lib/systemd/system, so it only seems natural to
look for executables mentioned in those units also in
/usr/local/{sbin,bin}.

Overall, I think this warning is severely misguided. In general, for
_most_ packaged software it is appropriate and expected to use $PATH,
to allow administrators to enhance and replace parts of the system
with local binaries. For specific packages that don't do that, a full
audit would need to be done that they always use a full path or
$SANITIZE path, and just a cursory check for embedded strings is
meaningless.

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: CPE Git Forge Decision

[Chris Murphy]

On Wed, Apr 1, 2020 at 1:47 AM Panu Matilainen  wrote:
>
> On 3/31/20 8:44 PM, Adam Williamson wrote:
>
> > I understand there are practical resource considerations and so on
> > here, but I still think this merits more high level and serious
> > consideration. At the very least, if we have somehow reached a point
> > where Red Hat is no longer willing to provide sufficient resources to
> > run Fedora on the lines the Fedora community wants it to be run, we
> > need to recognize that this is a significant problem that needs to be
> > properly aired and discussed and resolved. In this context I'll note
> > that the apparent significant headcount reduction of RH people working
> > on Fedora infrastructure over the last few years is in itself a
> > worrying trend, particularly if you consider it while reading Clement's
> > email.
>
> This.
>
> As a user, I wont be shedding a single tear for GitLab over Pagure, BUT.
>
> There's something very wrong with the picture here, and this forge
> business seems more like an abscess that finally burst rather than the
> disease itself. I really do not envy being in CPE's pants in this situation.
>
> If the problem is lack of funding for Fedora infastructure, shouldn't we
> talking about that (finding additional sponsors or something) instead of
> which limb to saw off to ensure enough blood for the remaining organs?

I agree, and wonder about this too. But such a conversation
immediately runs into the delicate and awkward realm of corporate
politics: would Red Hat even allow other sponsors, and what are the
parameters by which this could even happen - it's not clear to me at
all.

Also, there are different kinds of resources: funding, people,
hardware (virtual/physical). While the project always has resource
shortages to varying degrees, I'm not certain of any metric to
establish a low watermark; know whether it's being approached before
there's a problem; or a formal mechanism of refreshing teams to avoid
burn out and hitting a resource low watermark.

Another example of this is:

#275 Websites team needs revitalizing
https://pagure.io/Fedora-Council/tickets/issue/275

from which I've just realized two things: (a) CPE is Fedora
Infrastructure team; (b) due to the lack of an active websites team,
this responsibility is, for now, on CPE.


--
Chris Murphy
___
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: Why is "local" insecure PATH element ?

[Lukas Czerner]

On Wed, Apr 01, 2020 at 04:10:02PM -0400, Stephen Gallagher wrote:
> On Wed, Apr 1, 2020 at 3:58 PM Lukas Czerner  wrote:
> >
> > On Wed, Apr 01, 2020 at 11:26:04AM -0700, Samuel Sieb wrote:
> > > On 4/1/20 4:27 AM, Lukas Czerner wrote:
> > > > I've noticed some failures in automated tests in bodhi, specifically
> > > > this one:
> > > >
> > > >  {
> > > > "arch" : "x86_64",
> > > > "code" : "SuspiciousPath",
> > > > "context" : {
> > > >   "excerpt" : [
> > > >  
> > > > "PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
> > > >   ],
> > > >   "path" : "/usr/sbin/e2scrub"
> > > > },
> > > > "diag" : "Potentially insecure PATH element /local",
> > > > "subpackage" : "e2scrub"
> > > >  },
> > > >
> > > > I am not sure why it's considered insecure while on all of the Fedora
> > > > and RHEL systems I have available "/usr/local/sbin:/usr/local/bin" is a
> > > > default part of the PATH.
> > >
> > > You don't want a system script to be looking for executables in /usr/local
> > > before the regular bin directories.  And it's probably better that it
> > > doesn't look in /usr/local at all.
> > > It's fine for the admin to put extra things in /usr/local, but those paths
> > > don't override the system ones.
> >
> > Thanks, that's understandable, but then why the PATH on my system is
> >
> > /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
> >
> > or
> >
> > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
> >
> > all the systems I try include /usr/local in the PATH.
> >
> 
> We don't want anything installed via RPM to be using /usr/local
> directly. The /usr/local path is intended for locally-installed
> content by the administrator, while /usr is meant for content coming
> from the distributor.
> 
> For example, I maintain the `npm` package. It installs its binary as
> /usr/bin/npm.  However, if I use npm (it's a Node.js package manager)
> to install a Node-based binary with `npm -g install someapp`, it will
> install it in /usr/local rather than /usr. This is done in part to
> avoid future conflicts where RPM might try to overwrite
> locally-installed content or where a tool like `npm` is overwriting
> RPM-managed content (which it was doing until fairly recently...)

Thanks I appreciate the explanation, but I am aware of this. What I am
trying to understand is how setting a PATH with "/local" element from a
script is insecure. When I run the scrip on my system the PATH already
include the "/local" element by default so it's not really changing
anything. Right ?

Is it that the test is using the fact that we set the PATH with "/local"
element as an indication that it's going to put something there ? It's
not the case here and in fact I think that the line should be removed
from the script, but that's besides the point. I am trying to undestand
why the test is failing and what is it protecting from.

Anyone has any idea where to find the person who is responsible for
those automated tests ?

-Lukas

> ___
> 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 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 01, 2020 at 03:55:19PM -0400, Stephen Gallagher wrote:
> On Wed, Apr 1, 2020 at 3:24 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Wed, Apr 01, 2020 at 11:40:49AM -0400, Stephen Gallagher wrote:
> > > On Wed, Apr 1, 2020 at 6:46 AM Zbigniew Jędrzejewski-Szmek
> > >  wrote:
> > > >
> > > > On Wed, Apr 01, 2020 at 12:30:13PM +0200, Miro Hrončok wrote:
> > > > > On 01. 04. 20 10:53, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > >On Tue, Mar 31, 2020 at 11:31:38AM -0400, Stephen Gallagher wrote:
> > > > > >>I sent out the V2 version of the Change on Friday and then promptly
> > > > > >>managed to injure myself and be away from email until today. I've 
> > > > > >>read
> > > > > >>through the email threads again this morning and I decided that,
> > > > > >>rather than try to address them one by one, I'd try again with a V3
> > > > > >>that hopefully answers some of the repeated questions and concerns 
> > > > > >>on
> > > > > >>that list.
> > > > > >
> > > > > >>To enable ELN (once the repository is composed):
> > > > > >>
> > > > > >>$ dnf install fedora-repos-eln
> > > > > >>$ dnf distro-sync
> > > > > >
> > > > > >I don't see this part explained. Those additional packages will haves
> > > > > >NEVRAs always lower than rawhide packages (".eln" < ".fc33".). So 
> > > > > >this
> > > > > >distro-sync will be a noop?
> > > > >
> > > > > A wild guess: If that repo has lower "cost", will distro-sync prefer
> > > > > packages with lower EVR because they come form that repo?
> > > >
> > > > I don't think so: "cost — ... It is useful to make the library prefer
> > > > on-disk repositories to remote ones."
> > > >
> > > > But there's a "priority" option: "If there is more than one candidate
> > > > package for a particular operation, the one from a repo with the
> > > > lowest priority value is picked, possibly despite being less
> > > > convenient otherwise (e.g. by being a lower version)."
> > > >
> > > > This should do the trick. The mechanism should be described in the
> > > > Change page too.
> > > >
> > > > (Note: I had a sense of deja-vu, because 'priority' was already
> > > > discussed in the context of this Change, but it was koji priority for
> > > > scheduling tasks, not package installation.)
> > >
> > >
> > > Right, the intent here is to have the fedora-repos-eln subpackage
> > > provide a repo at priority level 98 (default being 99, lower numbers
> > > "win"). I left it out because generally Change Proposals aren't
> > > required to document every minor implementation detail.
> >
> > It's not a minor implementation detail. The subject of priority came
> > up before in the thread where people were wondering about version
> > ordering. What priority level will be used is indeed something that
> > doesn't need to appear in the change page, but the general approach
> > should IMO appear there.
> >
> > By providing an overview of implementation choices you make it
> > possible for people to think about various corner cases and possibly
> > find issues that that otherwise could only discover once the
> > implementation is done and it's much harder to change stuff.
> 
> 
> Well, Change Proposals aren't design documents. I would prefer to
> change the document to read more like "This will need to be
> implemented in such a way that contents of the ELN repository would be
> preferred by the software management tools over the standard Fedora
> packages, even when the latter are of a higher version." I prefer not
> to put implementation details in places like this; I'd rather describe
> the expected behavior and trust that those implementing it will find
> an appropriate mechanism.

I disagree, both to "aren't design documents" and to the usefulness of
providing detail.

Change pages often describe what will happen in detail. Just look at
any of the pages from F32 list, e.g. [1-5]. The ones that don't
describe implementation details are usually straightforward changes
like gcc/binutils/dnf/language stack version bumps where the packaging
changes are trivial.

In fact, for [4] below I had to provide the complete list of affected
packages in the fesco ticket, and I think it was totally appropriate.

[1] https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer
[2] https://fedoraproject.org/wiki/Changes/FontLangProvidesToLangpacks
[3] 
https://fedoraproject.org/wiki/Changes/Stop-Shipping-Individual-Component-Libraries-In-clang-lib-Package
[4] https://fedoraproject.org/wiki/Changes/Systemd_presets_for_user_units
[5] https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format

> Do you want me to list some of the other approaches we considered and
> discarded before we settled on `priority`? I don't think that belongs
> in a Change Proposal either, but since apparently we can't get Changes
> approved anymore without having the complete implementation
> beforehand, I guess we can add that too.

Yes, I think it'd be totally OK to describe alternative approaches
and their relative merits. For somethin

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

[Miro Hrončok]

On 01. 04. 20 21:55, Stephen Gallagher wrote:

Well, Change Proposals aren't design documents. I would prefer to
change the document to read more like "This will need to be
implemented in such a way that contents of the ELN repository would be
preferred by the software management tools over the standard Fedora
packages, even when the latter are of a higher version." I prefer not
to put implementation details in places like this; I'd rather describe
the expected behavior and trust that those implementing it will find
an appropriate mechanism.


I get your point, but only to a certain level. It is import to know what we are 
approving. See below.



Do you want me to list some of the other approaches we considered and
discarded before we settled on `priority`? I don't think that belongs
in a Change Proposal either, but since apparently we can't get Changes
approved anymore without having the complete implementation
beforehand, I guess we can add that too.


That is not true. However change proposals that have close-to-complete *design* 
beforehand are really easier to comprehend and understand. High level "ideas" 
change proposals are good for initial discussion, if the change owners will take 
the feedback and docuement the design in a more concrete way before FESCo 
actually votes about any of this.



* Instead of using `priority`, we*could*  opt to provide all of the
ELN content as a large Module. That has overhead problems that make it
not worthwhile.
* We could force all ELN builds to have epoch+100 when they rebuild
(this has problems with future updates).
* We could modify the RPM/libdnf stack to automatically install
different versions of the RPMs based on available hardware. (We don't
have the available resources for another Modularity-level effort.)


As a FESCo member I'd be much more confident to approve a specific design 
("we'll use repo cost/priorities to make ELN builds distro-sync over Rawhide 
builds with higher evrs") than a goal that might end up like some of the things 
listed here by you.



I strongly disagree that a change proposal should only describe the end goal.

What if somebody proposes a change that says "we will make Fedora Server 
installation smaller" and goes into great depths about the benefits etc. but 
won't actually list the things that will be removed to reduce the installation 
size. Would we just discuss the end goal and when everybody agrees that smaller 
Server is good, we would approve it?


--
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: Self Introduction: Kevin Buettner

[Stephen Gallagher]

On Wed, Apr 1, 2020 at 4:08 PM Sergio Durigan Junior
 wrote:
>
> On Wednesday, April 01 2020, Dan Čermák wrote:
>
> > Hi Kevin,
> >
> > welcome to the pack!
> >
> > Kevin Buettner  writes:
> >
> >> Hi,
> >>
> >> My name is Kevin Buettner.
> >>
> >> I've been involved in GDB development for over 20 years.  I'm an
> >> (upstream) GDB global maintainer.  I would like to become a
> >> co-maintainer of the GDB package for the Fedora project.
> >
> > You should talk to the maintainers of GDB then ;-) (all in the To: field
> > as well).
>
> Hey,
>
> Kevin will become a co-maintainer :-).  We're just waiting for someone
> to include him in the packager group.  I opened the request yesterday:
>
>   https://pagure.io/packager-sponsors/issue/414
>
> If someone can add him to the group, I'd appreciate.
>

Done.
___
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: Why is "local" insecure PATH element ?

[Stephen Gallagher]

On Wed, Apr 1, 2020 at 3:58 PM Lukas Czerner  wrote:
>
> On Wed, Apr 01, 2020 at 11:26:04AM -0700, Samuel Sieb wrote:
> > On 4/1/20 4:27 AM, Lukas Czerner wrote:
> > > I've noticed some failures in automated tests in bodhi, specifically
> > > this one:
> > >
> > >  {
> > > "arch" : "x86_64",
> > > "code" : "SuspiciousPath",
> > > "context" : {
> > >   "excerpt" : [
> > >  
> > > "PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
> > >   ],
> > >   "path" : "/usr/sbin/e2scrub"
> > > },
> > > "diag" : "Potentially insecure PATH element /local",
> > > "subpackage" : "e2scrub"
> > >  },
> > >
> > > I am not sure why it's considered insecure while on all of the Fedora
> > > and RHEL systems I have available "/usr/local/sbin:/usr/local/bin" is a
> > > default part of the PATH.
> >
> > You don't want a system script to be looking for executables in /usr/local
> > before the regular bin directories.  And it's probably better that it
> > doesn't look in /usr/local at all.
> > It's fine for the admin to put extra things in /usr/local, but those paths
> > don't override the system ones.
>
> Thanks, that's understandable, but then why the PATH on my system is
>
> /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
>
> or
>
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
>
> all the systems I try include /usr/local in the PATH.
>

We don't want anything installed via RPM to be using /usr/local
directly. The /usr/local path is intended for locally-installed
content by the administrator, while /usr is meant for content coming
from the distributor.

For example, I maintain the `npm` package. It installs its binary as
/usr/bin/npm.  However, if I use npm (it's a Node.js package manager)
to install a Node-based binary with `npm -g install someapp`, it will
install it in /usr/local rather than /usr. This is done in part to
avoid future conflicts where RPM might try to overwrite
locally-installed content or where a tool like `npm` is overwriting
RPM-managed content (which it was doing until fairly recently...)
___
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: Self Introduction: Kevin Buettner

[Sergio Durigan Junior]

On Wednesday, April 01 2020, Dan Čermák wrote:

> Hi Kevin,
>
> welcome to the pack!
>
> Kevin Buettner  writes:
>
>> Hi,
>>
>> My name is Kevin Buettner.
>>
>> I've been involved in GDB development for over 20 years.  I'm an
>> (upstream) GDB global maintainer.  I would like to become a
>> co-maintainer of the GDB package for the Fedora project.
>
> You should talk to the maintainers of GDB then ;-) (all in the To: field
> as well).

Hey,

Kevin will become a co-maintainer :-).  We're just waiting for someone
to include him in the packager group.  I opened the request yesterday:

  https://pagure.io/packager-sponsors/issue/414

If someone can add him to the group, I'd appreciate.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Why is "local" insecure PATH element ?

[Lukas Czerner]

On Wed, Apr 01, 2020 at 11:26:04AM -0700, Samuel Sieb wrote:
> On 4/1/20 4:27 AM, Lukas Czerner wrote:
> > I've noticed some failures in automated tests in bodhi, specifically
> > this one:
> > 
> >  {
> > "arch" : "x86_64",
> > "code" : "SuspiciousPath",
> > "context" : {
> >   "excerpt" : [
> >  "PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
> >   ],
> >   "path" : "/usr/sbin/e2scrub"
> > },
> > "diag" : "Potentially insecure PATH element /local",
> > "subpackage" : "e2scrub"
> >  },
> > 
> > I am not sure why it's considered insecure while on all of the Fedora
> > and RHEL systems I have available "/usr/local/sbin:/usr/local/bin" is a
> > default part of the PATH.
> 
> You don't want a system script to be looking for executables in /usr/local
> before the regular bin directories.  And it's probably better that it
> doesn't look in /usr/local at all.
> It's fine for the admin to put extra things in /usr/local, but those paths
> don't override the system ones.

Thanks, that's understandable, but then why the PATH on my system is

/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

or

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin

all the systems I try include /usr/local in the PATH.

-Lukas

> ___
> 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 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

[Stephen Gallagher]

On Wed, Apr 1, 2020 at 3:24 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Apr 01, 2020 at 11:40:49AM -0400, Stephen Gallagher wrote:
> > On Wed, Apr 1, 2020 at 6:46 AM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > On Wed, Apr 01, 2020 at 12:30:13PM +0200, Miro Hrončok wrote:
> > > > On 01. 04. 20 10:53, Zbigniew Jędrzejewski-Szmek wrote:
> > > > >On Tue, Mar 31, 2020 at 11:31:38AM -0400, Stephen Gallagher wrote:
> > > > >>I sent out the V2 version of the Change on Friday and then promptly
> > > > >>managed to injure myself and be away from email until today. I've read
> > > > >>through the email threads again this morning and I decided that,
> > > > >>rather than try to address them one by one, I'd try again with a V3
> > > > >>that hopefully answers some of the repeated questions and concerns on
> > > > >>that list.
> > > > >
> > > > >>To enable ELN (once the repository is composed):
> > > > >>
> > > > >>$ dnf install fedora-repos-eln
> > > > >>$ dnf distro-sync
> > > > >
> > > > >I don't see this part explained. Those additional packages will haves
> > > > >NEVRAs always lower than rawhide packages (".eln" < ".fc33".). So this
> > > > >distro-sync will be a noop?
> > > >
> > > > A wild guess: If that repo has lower "cost", will distro-sync prefer
> > > > packages with lower EVR because they come form that repo?
> > >
> > > I don't think so: "cost — ... It is useful to make the library prefer
> > > on-disk repositories to remote ones."
> > >
> > > But there's a "priority" option: "If there is more than one candidate
> > > package for a particular operation, the one from a repo with the
> > > lowest priority value is picked, possibly despite being less
> > > convenient otherwise (e.g. by being a lower version)."
> > >
> > > This should do the trick. The mechanism should be described in the
> > > Change page too.
> > >
> > > (Note: I had a sense of deja-vu, because 'priority' was already
> > > discussed in the context of this Change, but it was koji priority for
> > > scheduling tasks, not package installation.)
> >
> >
> > Right, the intent here is to have the fedora-repos-eln subpackage
> > provide a repo at priority level 98 (default being 99, lower numbers
> > "win"). I left it out because generally Change Proposals aren't
> > required to document every minor implementation detail.
>
> It's not a minor implementation detail. The subject of priority came
> up before in the thread where people were wondering about version
> ordering. What priority level will be used is indeed something that
> doesn't need to appear in the change page, but the general approach
> should IMO appear there.
>
> By providing an overview of implementation choices you make it
> possible for people to think about various corner cases and possibly
> find issues that that otherwise could only discover once the
> implementation is done and it's much harder to change stuff.


Well, Change Proposals aren't design documents. I would prefer to
change the document to read more like "This will need to be
implemented in such a way that contents of the ELN repository would be
preferred by the software management tools over the standard Fedora
packages, even when the latter are of a higher version." I prefer not
to put implementation details in places like this; I'd rather describe
the expected behavior and trust that those implementing it will find
an appropriate mechanism.

Do you want me to list some of the other approaches we considered and
discarded before we settled on `priority`? I don't think that belongs
in a Change Proposal either, but since apparently we can't get Changes
approved anymore without having the complete implementation
beforehand, I guess we can add that too.

* Instead of using `priority`, we *could* opt to provide all of the
ELN content as a large Module. That has overhead problems that make it
not worthwhile.
* We could force all ELN builds to have epoch+100 when they rebuild
(this has problems with future updates).
* We could modify the RPM/libdnf stack to automatically install
different versions of the RPMs based on available hardware. (We don't
have the available resources for another Modularity-level effort.)
___
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: Self Introduction: Kevin Buettner

[Dan Čermák]

Hi Kevin,

welcome to the pack!

Kevin Buettner  writes:

> Hi,
>
> My name is Kevin Buettner.
>
> I've been involved in GDB development for over 20 years.  I'm an
> (upstream) GDB global maintainer.  I would like to become a
> co-maintainer of the GDB package for the Fedora project.

You should talk to the maintainers of GDB then ;-) (all in the To: field
as well).

>
> In order to come up to speed on what Fedora package maintenance
> is about, I've been reading the following page as well as many of
> the links on that page:
>
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
>
> Kevin


Cheers,

Dan


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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 01, 2020 at 11:40:49AM -0400, Stephen Gallagher wrote:
> On Wed, Apr 1, 2020 at 6:46 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Wed, Apr 01, 2020 at 12:30:13PM +0200, Miro Hrončok wrote:
> > > On 01. 04. 20 10:53, Zbigniew Jędrzejewski-Szmek wrote:
> > > >On Tue, Mar 31, 2020 at 11:31:38AM -0400, Stephen Gallagher wrote:
> > > >>I sent out the V2 version of the Change on Friday and then promptly
> > > >>managed to injure myself and be away from email until today. I've read
> > > >>through the email threads again this morning and I decided that,
> > > >>rather than try to address them one by one, I'd try again with a V3
> > > >>that hopefully answers some of the repeated questions and concerns on
> > > >>that list.
> > > >
> > > >>To enable ELN (once the repository is composed):
> > > >>
> > > >>$ dnf install fedora-repos-eln
> > > >>$ dnf distro-sync
> > > >
> > > >I don't see this part explained. Those additional packages will haves
> > > >NEVRAs always lower than rawhide packages (".eln" < ".fc33".). So this
> > > >distro-sync will be a noop?
> > >
> > > A wild guess: If that repo has lower "cost", will distro-sync prefer
> > > packages with lower EVR because they come form that repo?
> >
> > I don't think so: "cost — ... It is useful to make the library prefer
> > on-disk repositories to remote ones."
> >
> > But there's a "priority" option: "If there is more than one candidate
> > package for a particular operation, the one from a repo with the
> > lowest priority value is picked, possibly despite being less
> > convenient otherwise (e.g. by being a lower version)."
> >
> > This should do the trick. The mechanism should be described in the
> > Change page too.
> >
> > (Note: I had a sense of deja-vu, because 'priority' was already
> > discussed in the context of this Change, but it was koji priority for
> > scheduling tasks, not package installation.)
> 
> 
> Right, the intent here is to have the fedora-repos-eln subpackage
> provide a repo at priority level 98 (default being 99, lower numbers
> "win"). I left it out because generally Change Proposals aren't
> required to document every minor implementation detail.

It's not a minor implementation detail. The subject of priority came
up before in the thread where people were wondering about version
ordering. What priority level will be used is indeed something that
doesn't need to appear in the change page, but the general approach
should IMO appear there.

By providing an overview of implementation choices you make it
possible for people to think about various corner cases and possibly
find issues that that otherwise could only discover once the
implementation is done and it's much harder to change stuff.

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

Self Introduction: Kevin Buettner

[Kevin Buettner]

Hi,

My name is Kevin Buettner.

I've been involved in GDB development for over 20 years.  I'm an
(upstream) GDB global maintainer.  I would like to become a
co-maintainer of the GDB package for the Fedora project.

In order to come up to speed on what Fedora package maintenance
is about, I've been reading the following page as well as many of
the links on that page:

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

Kevin
___
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-20200401.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 11/171 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-Rawhide-20200330.n.1):

ID: 563350  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/563350
ID: 563383  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/563383
ID: 563384  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/563384
ID: 563410  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/563410
ID: 563415  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/563415
ID: 563452  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/563452
ID: 563471  Test: x86_64 universal install_pxeboot
URL: https://openqa.fedoraproject.org/tests/563471
ID: 563473  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/563473

Old failures (same test failed in Fedora-Rawhide-20200330.n.1):

ID: 563332  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/563332
ID: 563346  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/563346
ID: 563368  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/563368
ID: 563381  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/563381

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

New soft failures (same test not soft failed in Fedora-Rawhide-20200330.n.1):

ID: 563337  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/563337
ID: 563435  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/563435
ID: 563469  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/563469
ID: 563472  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/563472
ID: 563474  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/563474

Old soft failures (same test soft failed in Fedora-Rawhide-20200330.n.1):

ID: 563302  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/563302
ID: 563303  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/563303
ID: 563307  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/563307
ID: 563311  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/563311
ID: 563314  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/563314
ID: 563315  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/563315
ID: 563360  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/563360
ID: 563362  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/563362
ID: 563394  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/563394
ID: 563399  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/563399
ID: 563416  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/563416
ID: 563425  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/563425
ID: 563426  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/563426
ID: 563444  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/563444
ID: 563460  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/563460
ID: 563468  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/563468

Passed openQA tests: 130/171 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20200330.n.1):

ID: 563330  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/563330
ID: 563335  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/563335
ID: 563338  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/563338
ID: 563339  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/

Schedule for Thursday's FPC Meeting (2020-04-02 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2020-04-02 16:00 UTC in #fedora-meeting-1 on 
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2020-04-02 09:00 PDT  US/Pacific
2020-04-02 12:00 EDT  --> US/Eastern <--
2020-04-02 16:00 UTC  UTC   
2020-04-02 17:00 BST  Europe/London 
2020-04-02 18:00 CEST Europe/Berlin 
2020-04-02 18:00 CEST Europe/Paris  
2020-04-02 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2020-04-03 00:00 HKT  Asia/Hong_Kong
2020-04-03 00:00 +08  Asia/Singapore
2020-04-03 01:00 JST  Asia/Tokyo
2020-04-03 02:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

= Followups =

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

#topic #909 Suggest that linting/measuring-coverage is not for %check
.fpc 909
https://pagure.io/packaging-committee/issue/909

= Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines 
https://pagure.io/packaging-committee/pull-request/814

#topic #pr-938 Add Package Review Process page 
https://pagure.io/packaging-committee/pull-request/938

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * 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: CPE Git Forge Decision

[Adam Williamson]

On Wed, 2020-04-01 at 09:11 -0700, Adam Williamson wrote:
> Bodhi was written by Luke, back
> 
> in the day, for instance, but Ralph did a great job of taking it over
> 
> (and fixing it up).

Sorry, that was obviously a mental slip: I meant Randy, not Ralph.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

[Adam Williamson]

On Wed, 2020-04-01 at 12:09 -0400, Matthew Miller wrote:
> On Wed, Apr 01, 2020 at 02:15:05PM +0200, Pierre-Yves Chibon wrote:
> > Let's be aware that Fedora Infra's job hasn't been "Building a linux distro"
> > since it's inception, for a long time its goal was much closer to "building 
> > and
> > supporting the *community* that builds the linux distro".
> > If you use this mission statement, you can a much different look at badges,
> > elections or calendaring.
> 
> Yeah -- and this bigger picture is still the Fedora Project's overall goal.
> The change is in the mission of CPE vs. the previous Fedora Engineering team
> structure, not in what we want to do as a project.

If there's a gap there, though, have we systematically considered how
it should be filled? Including whether RH still wants to contribute to
filling it, outside of the CPE team's remit?

Right now the only story I remember hearing around these things is the
CPE team's "we are narrowing our focus and these things are no longer
within it, so they're going to be dropped or heavily back-burnered or 
given to The Community". There have been specific individual efforts to
pick up or at least drive-by work on various specific things, but I
haven't seen any organized effort (from Red Hat or "The Community") to
consider this in a broader way.

I was figuring this really was the intended state of affairs, but the
above makes it sound like there's some idea "Fedora" might still want
this stuff done, but I don't see any processes or groups or anything
that are being formed or proposed to make that happen?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Why is "local" insecure PATH element ?

[Samuel Sieb]

On 4/1/20 4:27 AM, Lukas Czerner wrote:

I've noticed some failures in automated tests in bodhi, specifically
this one:

 {
"arch" : "x86_64",
"code" : "SuspiciousPath",
"context" : {
  "excerpt" : [
 "PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
  ],
  "path" : "/usr/sbin/e2scrub"
},
"diag" : "Potentially insecure PATH element /local",
"subpackage" : "e2scrub"
 },

I am not sure why it's considered insecure while on all of the Fedora
and RHEL systems I have available "/usr/local/sbin:/usr/local/bin" is a
default part of the PATH.


You don't want a system script to be looking for executables in 
/usr/local before the regular bin directories.  And it's probably better 
that it doesn't look in /usr/local at all.
It's fine for the admin to put extra things in /usr/local, but those 
paths don't override the system ones.

___
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: Heads-up: RPM 4.16 alpha coming to rawhide

[Richard W.M. Jones]

This is _only_ going into Rawhide / F33?  It looks like the change to
the new OCaml dependency generator will require a complete rebuild of
all OCaml packages.

https://github.com/rpm-software-management/rpm/commit/a6fe37c39b39acbcbd014dd1e6d5653ff84254a1
https://github.com/rpm-software-management/rpm/issues/913

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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 33 System-Wide Change proposal: Mark libdb as deprecated

[Richard W.M. Jones]

On Mon, Mar 30, 2020 at 10:30:37AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Libdb_deprecated
> 
> == Summary ==
> This change should inform maintainers and developers about effort to
> remove libdb in future.
> 
> == Owner ==
> * Name: [[User:fjanus|Filip Januš]]
> * Email: fja...@redhat.com
> 
> 
> == Detailed Description ==
> We would like to remove libdb from Fedora in future, because
> BerkeleyDB 6.x has a more restrictive license than the previous
> versions (AGPLv3 vs. LGPLv2) and due many projects can't use it.
> Nowadays Fedora uses the old version (5.3.28) and we can't update to
> newer. Due to many projects have libdb dependency, we propose few
> steps to complete removal. First step would mark libdb as deprecated
> package in Fedora 33. Next steps in Fedora 35 would provide converting
> tool for existing databases and mark libdb as orphaned.

Is there a way to read old database files?

libguestfs uses libdb (actually utils like db_dump) in order to read
old RPM databases from old guests.  Since these old guests never go
away we'd like to continue to support them.  (And before anyone
mentions librpm, that just moves the problem around.)

BTW your list of dependencies didn't include libguestfs because the
dependency is indirect (via libdb-utils), so you probably missed other
packages as well.

Also I'm unclear why packaging BDB 6 is a problem.  What's wrong with
AGPLv3?  Still free software surely?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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: ocaml-zip update

[Richard W.M. Jones]

On Wed, Apr 01, 2020 at 10:49:40AM -0600, Jerry James wrote:
> On Wed, Apr 1, 2020 at 10:44 AM Jerry James  wrote:
> > If I build in mock, I still get the resolvable dependencies.  If I add
> > --enablerepo=local, I get the unresolvable dependencies, so whatever
> > changed has gone into Rawhide since the last compose.
> 
> It's /usr/lib/rpm/ocamldeps.sh, part of the rpm-build package.

Right, this change was made by Olaf (and I reviewed it), see:

  https://github.com/rpm-software-management/rpm/issues/913

We may well need to rebuild everything to handle this.

Olaf - did you have to rebuild all OCaml packages in SUSE after
you did this?  Anything else we need to be aware of?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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: CPE Git Forge Decision

[Kevin Fenzi]

On Wed, Apr 01, 2020 at 11:51:01AM +0200, clime wrote:
> On Wed, 1 Apr 2020 at 10:54, Vít Ondruch  wrote:
> > Do you mean https://github.com/fedora-infra/pkgdb2/ ? :)

No.

> This is just hilarious, so after going all pagure for dist-git and
> making it all work, we will now go back to pkgdb, additionally with
> proprietary git backend, lol.

But pagure doesn't "just work". There's pagure-dist-git that does all
kinds of things to make src.fedoraproject.org have different things than
pagure.io. 

Do you consider pagure-dist-git to be pkgdb 1.5?

You missed where I said we should adjust our workflow and try and
minimize this layer. I wasn't suggesting we just make another app in
front of the git forge. I was suggesting we move all our "special" stuff
into git or otherwise adjust our workflow to make such a layer
nonexistant or as small as we can. 

How could we do that?

Well, there was the suggestion from Jermey that we use tags to store
this 'distro metadata'. Or perhaps we have files in each git repo, or a
branch or a seperate repo. This would not only mean we have less to
maintain, but it would mean we could move things much easier, people
could mirror them to another gitforge much easier, etc. 

> I mean if there is some alien race (or a human competitor) watching
> what is happening in one of the leading linux distributions, they must
> laugh hard. Well, we soon won't be leading.

I think you are misunderstanding me, but sure, laugh away. If you can't
laugh, you have to cry. ;) 

kevin


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: CPE Git Forge Decision

[Frank Ch. Eigler]

> > [...] Nor would it have helped with the SLA requirements and
> > operational cost. [...]

> What reason is there to believe that a gitlab commercial SaaS
> might a smaller operational cost?

> I meant that in the sense of the time we invest in it to develop
> features, fix bugs, keep it on the air etc. 

Surely what we want to minimize is total cost, not just one
department's expenditure.  For that, you'd need to have the
gitlab costs to compare.


- FChE
___
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: CPE Git Forge Decision

[Adam Williamson]

On Tue, 2020-03-31 at 14:22 -0700, Adam Williamson wrote:
> On Tue, 2020-03-31 at 17:06 -0400, Paul Frields wrote:
> > > Sure. I tend to think of these as 'upstream projects' that we (Fedora)
> > > consume as a downstream. Project hosting has always been a kinda
> > > optional bolt-on, I think; going back to the days of fedorahosted.org I
> > > don't think we've ever hosted everything "Fedora-adjacent" in our own
> > > hosting service, it's always been a "use it if you want to" thing, and
> > > the rule for using a project in Fedora has always been "is it open
> > > source?", not "how is it hosted?".
> > 
> > Although the Council changed that hard line some time ago.
> 
> Someone told me that a few minutes ago; either I wasn't aware at the
> time or have forgotten, but my personal opinion is that this was a
> mistake.

For a bit more on this, it seems Council discussed it again today:

https://meetbot-raw.fedoraproject.org/teams/council/council.2020-04-01-14.00.log.html

as noted there, the precise text agreed was:

"The Fedora Project wants to advance free and open source software and
as a pragmatic matter we recognize that some infrastructure needs may
be best served by using closed source or non-free tools today.
Therefore the Council is willing to accept closed source or non-free
tools in Fedora’s infrastructure where free and open source tools are
not viable or not available."

To me that's fairly strongly qualified. "Not viable or not available".
Note, that does not say "not the absolute best-in-class", it says "not
viable". Has it been demonstrated that either Pagure or Gitlab CE are
"not viable" for the purposes Fedora needs?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: silly question: finding root.log/build.log of FTBS F32 package (slim)

[Samuel Sieb]

On 4/1/20 4:53 AM, Richard Shaw wrote:
On Tue, Mar 31, 2020 at 11:12 PM Samuel Sieb > wrote:


On 3/31/20 7:16 PM, Richard Shaw wrote:
 >
 > It doesn't look like the spec can even be parsed... Something
must be
 > off. There are conditionals in the spec for Fedora 15 so that
tells me
 > the spec file is in major need of an overhaul. Also cmake is being
 > called directly instead of using %cmake.

How did you find that?  I can't even find the build in koji, just
the task.


Well the lack of using %cmake jumped out at me because I maintain a lot 
of cmake based packages. The problem with the %systemd_postun I had to 
google because the error, quite irritatingly, did not provide a line 
number. I only did local mock build for Rawhide and f31, not in koji, 
but I can do so if you like but I believe it's safe to do the official 
"fedpkg build" at this point.


Ok, you ran your own build.  I thought that somehow you had found the 
logs from the linked task.

___
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: CPE Git Forge Decision

[Nicolas Mailhot via devel]

Le mercredi 01 avril 2020 à 12:15 -0400, Matthew Miller a écrit :
> 
> I understand the sentiment but would like to tweak it a bit. Rather
> than a
> tooling project, Fedora is an _integration_ project. We bring
> together all
> of this software in the world and create polished solutions for
> users, and
> we make it easy for community members with specific ideas, and our
> downstreams, to do the same. That necessarily requires tooling, but
> tooling
> isn't the heart of the project. It's okay for us to be the integrator
> of tooling rather than the owner and creator of it all.

That’s a nice sentiment, but practically, the reason why Debian and
Fedora are not interchangeable, or why @gnome is dead set on creating
alternative toolchains, to “free” itself from distributions, is tooling
and only tooling.

You can not integrate at the level of a distribution without deep
tooling control and strategy. You can not replace the tools without
effectively embarking on a different distribution with a different
contributor set.

I am quite sceptical on how much of this can be SAASed away to a third
party without deleterious long term effects. (I don’t say it is
impossible, but it is a huge gamble).

What I am sure, is that the CPE statement “Gitlab is cool because they
will think about the roadmap in our stead” is a complete
misunderstanding of what makes Fedora tick.

Regards,

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

Re: CPE Git Forge Decision

[Adam Williamson]

On Wed, 2020-04-01 at 15:08 +0100, Leigh Griffin wrote:
> On Wed, Apr 1, 2020 at 2:47 PM Frank Ch. Eigler  wrote:
> 
> > > [...] Nor would it have helped with the SLA requirements and
> > > operational cost. [...]
> > 
> > What reason is there to believe that a gitlab commercial SaaS might a
> > smaller operational cost?
> > 
> 
> I meant that in the sense of the time we invest in it to develop features,
> fix bugs, keep it on the air etc.

Has an actual cost evaluation been done that suggests the cost of
buying Gitlab SaaS will be less than the cost would be to hire
sufficient people to do that work, though? Or is this simply a case
where it's considered Good to spend money on outsourcing and Bad to
spend it on paying people, based on only an *assumption* that the
former is always cheaper?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

[Adam Williamson]

On Wed, 2020-04-01 at 08:33 -0400, Alex Scheel wrote:
> - Original Message -
> > From: "Panu Matilainen" 
> > To: devel@lists.fedoraproject.org
> > Sent: Wednesday, April 1, 2020 6:22:39 AM
> > Subject: Re: CPE Git Forge Decision
> > 
> > > I also appreciate that as a community developing our own solutions is
> > > something important and something that seems to matter a lot, but we
> > > have to realize that the development and maintenance effort cannot be
> > > carried out by the CPE team any more. Maybe this is a opportunity to
> > > create a SIG or a working group for people that are interested to carry
> > > on this effort.
> > 
> > But this is precisely at the heart of the problem: people feel they were
> > not given an opportunity to lend a hand, and that now its too late
> > because the messaging is that we go with GitLab, no matter what.
> 
> Pagure has huge developer experience bugs filed against it for many
> years. Where have all these contributors been? Are those of us who really
> dislike Pagure's workflows in the minority? Or are others more prone
> to put up with it because it is free, open source software?

To speak for myself, I've been sending patches to Pagure for some time:

https://pagure.io/pagure/commits/master?author=awill...@redhat.com
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

[Adam Williamson]

On Wed, 2020-04-01 at 06:11 -0500, Bruno Wolff III wrote:
> On Wed, Apr 01, 2020 at 12:39:21 +0200,
>   Florian Weimer  wrote:
> > * Bruno Wolff, III:
> > 
> > > RHEL is a special case, as CENTOS provides a free drop in replacement
> > > and switching from CENTOS to Fedora shouldn't be much work. Is there
> > > other proprietary software at the OS level or above, that is used for
> > > Fedora infrastructure?
> > 
> > The Bugzilla fork running on bugzilla.redhat.com?
> > 
> >  
> 
> That was an interesting read. It sounds like corners were cut under the 
> assumption that there would be no desire to share the code. Specifically 
> code and config were mixed together and the config can't be released.

There's been an ongoing project in RH for the last few years to get
RHBZ closer to upstream. It's *much* closer now than it was a few years
ago. I haven't looked at the internal fork for a year or so, but last
time I did it wasn't a long way away from upstream.

So yeah, this is a valid entry in the list, but again it's a very
'grandfathered' one, and one it would be practically very difficult to
do much about (trying to unpick Fedora from RHBZ has been talked about
more than once but is logistically a very difficult job).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Take over maintenance of Hugo package

[W. Michael Petullo]

I would like to co-maintain or take over the maintenance of our Hugo
package. The package presently does not build, and thus it is at risk
of being orphaned:

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

-- 
Mike

:wq
___
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: CPE Git Forge Decision

[Matthew Miller]

On Wed, Apr 01, 2020 at 12:52:00PM +0200, Nicolas Mailhot via devel wrote:
> At heart, Fedora is a tooling project. It’s a collective of people that
> chose to use a specific integration toolchain. Anything involved in
> creating Fedora packages cuts deep into the project core. (unlike, say,
> calendaring).
> 
> It’s easy to forget this when making tooling decisions,
> because it is so pervasive, most do not see it anymore. Tooling is
> anything but accessory to the project.

I understand the sentiment but would like to tweak it a bit. Rather than a
tooling project, Fedora is an _integration_ project. We bring together all
of this software in the world and create polished solutions for users, and
we make it easy for community members with specific ideas, and our
downstreams, to do the same. That necessarily requires tooling, but tooling
isn't the heart of the project. It's okay for us to be the integrator of
tooling rather than the owner and creator of it all.


-- 
Matthew Miller

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

Re: CPE Git Forge Decision

[Adam Williamson]

On Wed, 2020-04-01 at 11:49 +0200, Clement Verna wrote:
> On Wed, 1 Apr 2020 at 09:47, Panu Matilainen  wrote:
> 
> > On 3/31/20 8:44 PM, Adam Williamson wrote:
> > 
> > > I understand there are practical resource considerations and so on
> > > here, but I still think this merits more high level and serious
> > > consideration. At the very least, if we have somehow reached a point
> > > where Red Hat is no longer willing to provide sufficient resources to
> > > run Fedora on the lines the Fedora community wants it to be run, we
> > > need to recognize that this is a significant problem that needs to be
> > > properly aired and discussed and resolved. In this context I'll note
> > > that the apparent significant headcount reduction of RH people working
> > > on Fedora infrastructure over the last few years is in itself a
> > > worrying trend, particularly if you consider it while reading Clement's
> > > email.
> > 
> > This.
> > 
> 
> I don't think this is correct, at least not in CPE, the team has grown over
> the past year and every person leaving the team has been replaced (even by
> 2 persons in some cases).

Okay, I didn't mean to get into detail, but I don't see how this is
possible. Unless you're considering 'CPE' as a whole (which includes
the infra admin team, release engineering, and docs) versus 'people
doing development'.

Around two-three years ago, IIRC, we had all these people working on
Fedora app/infra development:

puiterwijk (who counts as about ten people, admittedly, replacing
Patrick with anything besides an entire team was always going to be a
challenge)
Randy (bowlofeggs)
pingou
jcline
Ralph
jflory
abompard

Right now, I see these people who appear to be on the CPE team and
clearly working on Fedora infra/app development:

abompard?
lrossetti/odra (although I had not heard of or seen him till I started
doing research for this post, he seems to be working on fasjson which I
don't really run into)
pingou
scoady
cverna

I put a question mark by abompard as he clearly works for RH and works
a lot on infra, but (looking at internal systems) does not seem to be
quite in the same management chain as the others, not sure why that is.
I'm also not entirely sure about Adam Saleh, but he does not have any
infra activity I can find since the end of January and lists himself as
working for Exponea on Github and his personal blog.

If I'm missing anyone, please do correct me. Mattia Verga seems to do a
lot of work on Bodhi, but AFAICS he is not part of RH CPE. We could
count Ryan Lerch (UX) and/or Kevin Fenzi (who's officially admin, but
as we all know, does everything) in both list or neither.

Maybe the people I remember were not all there at exactly the same
time, I'm not 100% sure as I'm not on that team. But it does not feel
to me like we (RH) have the same level of personpower working on Fedora
app/infra development now as we did in 2018, put it that way.

The list at
https://fedoraproject.org/wiki/Community_Platform_Engineering seems to
be rather out of date; to my knowledge, Randy, Sayan, and Sinny are no
longer on the team, correct? Others in the list seem to work more or
less entirely on CentOS.

>  The problem in my opinion is that a lot of the
> people that have setup and written the original services and applications
> are gone, taking with them most of the knowledge about How, What and Why
> something was done this way. That leaves people in the team now with a big
> amount of legacy applications to take care of and not much clue of what is
> going on.

I can believe this, though I'd also note that few of the apps are
original to the "last gen" team either. Bodhi was written by Luke, back
in the day, for instance, but Ralph did a great job of taking it over
(and fixing it up). fedmsg was written by Ralph, then handed off
successfully (AFAICS, anyway) to jcline. So we seem to have done these
kinds of hand off before with success. What changed there?

> There is also an historical taste to write in house applications for things
> that don't really seems critical to the Fedora Project, for example do we
> really need a custom calendar application ? or election application ? It
> seems that every time we have a problem the solution is let's write
> something to solve that problem, instead of trying to find a compromise and
> reuse existing solutions.

So on the whole I agree with this. I talked to Jim about this whole
situation at OSS 2018 and he was already thinking along the lines of
cutting some of the stuff we really don't need to be writing. I
entirely agree that it's a reasonable approach to ditch stuff like this
that is *relatively* external to the process of actually building a
distribution. I'd be kinda sad if it was replaced with proprietary SAAS
stuff, but I don't think it'd be as big of a problem as if we did that
with our dist-git.

I don't think we need to go into it in detail, but I *do* also
understand why we did it in the first place, and I think there's still
merit in t

[EPEL-devel] Re: fop for epel 8

[Tim Orling]

 

On Wed, Apr 1, 2020 at 6:21 AM Troy Dawson  wrote:

> Packages in the EPEL-8 repository are volunteered by Fedora packagers
> via requests by interested users.
> If a package you are looking for is not there, please look at
> https://bugzilla.redhat.com and see if a request has been opened for
> your package to be built in EPEL-8.
> If it hasn't please open a new ticket.
> Some packages may not be able to built in EPEL-8 due to missing deps
> which need to be added.
> ---
> That is the official way to get packages into EPEL 8.
> Looks like the owner has already started work on it, but it's still
> good to get a bugzilla if there isn't one.  I tend to prioritize what
> packages I do based on if they have a bugzilla or not.
>
> To be clear, I am a Fedora packager and have supported multiple packages
in epel-6. So my first inclination was not to file a bug for someone else
to do the work. But agreed that the process should be followed.

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


> On Tue, Mar 31, 2020 at 9:41 PM Tim Orling  wrote:
> >
> > Naively cloning f30 branch and performing a local build:
> >
> > ant is available as module
> >
> > No match for apache-commons, avalon-framework, batik, fontbox,
> javapackages-local, junit, qdox, servlet, xmlgraphics-commons, xmlunit
> >
> > I guess there's some work to do...
> > ___
> > epel-devel mailing list -- epel-de...@lists.fedoraproject.org
> > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org
> ___
> epel-devel mailing list -- epel-de...@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org
>
___
epel-devel mailing list -- epel-de...@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org

Re: CPE Git Forge Decision

[Matthew Miller]

On Wed, Apr 01, 2020 at 02:15:05PM +0200, Pierre-Yves Chibon wrote:
> Let's be aware that Fedora Infra's job hasn't been "Building a linux distro"
> since it's inception, for a long time its goal was much closer to "building 
> and
> supporting the *community* that builds the linux distro".
> If you use this mission statement, you can a much different look at badges,
> elections or calendaring.

Yeah -- and this bigger picture is still the Fedora Project's overall goal.
The change is in the mission of CPE vs. the previous Fedora Engineering team
structure, not in what we want to do as a project.

-- 
Matthew Miller

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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

[Stephen Gallagher]

On Wed, Apr 1, 2020 at 10:02 AM David Cantrell  wrote:
>
> On Wed, Apr 01, 2020 at 10:19:08AM +0200, Vít Ondruch wrote:
> >So although this update clarifies some part, we have not moved anywhere:
> >
> >
> >~~~
> >
> >=== Can we do this in a branch instead of in master? ===
> >
> >This adds no value to the current approach where Red Hat maintainers
> >would manually merge their changes into the internal build
> >infrastructure. There's no way to automate the sync from the `master`
> >branch to the `eln` branch that wouldn't break and require maintainer
> >involvement. Attempting to branch only individual packages would
> >introduce significant complexity in the build process as well, leading
> >to far more opportunity for bugs. Lastly, even the most diligent of
> >maintainers can forget to sync every change to a new branch, thus
> >leaving us in a situation where the `eln` branch has fallen behind and
> >is no longer providing an accurate view of whether the package is still
> >building or functioning in that environment.
> >
> >~~~
> >
> >
> >I wonder where this comes from. I am participating in this thread,
> >representing Ruby maintainers in RHEL and Fedora, in other places of the
> >thread, I see Miro Hrončok, Tomáš Orsava and Pert Viktorin representing
> >Python RHEL and Fedora maitainers, as well as Petr Písař, the RHEL and
> >Fedora representative of Perl. All in all, it represents ~1/2 packages
> >in Fedora/RHEL. I hope that I can say that these people shares a view
> >that branch, fork, PR is the way to go.
> >
> >Yet we are not able to convince you. So I wonder who this proposal
> >actually represents? Who is the target audience? Who are the Red Hat
> >maintainers you mentioned in the proposal?
> >
>
> I think the FAQ entry above could be phrased better, but my understanding is
> that we should really want rawhide to be where upstream RHEL work happens.
> Creating another branch for this work effectively creates two rawhides and I
> think ELN would suffer as a result.
>

Yes, this is exactly the point I'm trying to make. I'll see what I can
do to make that clearer in the Proposal.

> Another thing to consider is that we should want ELN builds happening as
> rapidly as rawhide builds.  ELN is not something to set up and maintain as it
> were RHEL.

Thank you! Yes, exactly. If all we wanted was to create a new branch
to maintain, we would probably just not bother trying to work in
Fedora at all (at both Fedora's and Red Hat's loss).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

[Stephen Gallagher]

On Wed, Apr 1, 2020 at 6:46 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Apr 01, 2020 at 12:30:13PM +0200, Miro Hrončok wrote:
> > On 01. 04. 20 10:53, Zbigniew Jędrzejewski-Szmek wrote:
> > >On Tue, Mar 31, 2020 at 11:31:38AM -0400, Stephen Gallagher wrote:
> > >>I sent out the V2 version of the Change on Friday and then promptly
> > >>managed to injure myself and be away from email until today. I've read
> > >>through the email threads again this morning and I decided that,
> > >>rather than try to address them one by one, I'd try again with a V3
> > >>that hopefully answers some of the repeated questions and concerns on
> > >>that list.
> > >
> > >>To enable ELN (once the repository is composed):
> > >>
> > >>$ dnf install fedora-repos-eln
> > >>$ dnf distro-sync
> > >
> > >I don't see this part explained. Those additional packages will haves
> > >NEVRAs always lower than rawhide packages (".eln" < ".fc33".). So this
> > >distro-sync will be a noop?
> >
> > A wild guess: If that repo has lower "cost", will distro-sync prefer
> > packages with lower EVR because they come form that repo?
>
> I don't think so: "cost — ... It is useful to make the library prefer
> on-disk repositories to remote ones."
>
> But there's a "priority" option: "If there is more than one candidate
> package for a particular operation, the one from a repo with the
> lowest priority value is picked, possibly despite being less
> convenient otherwise (e.g. by being a lower version)."
>
> This should do the trick. The mechanism should be described in the
> Change page too.
>
> (Note: I had a sense of deja-vu, because 'priority' was already
> discussed in the context of this Change, but it was koji priority for
> scheduling tasks, not package installation.)


Right, the intent here is to have the fedora-repos-eln subpackage
provide a repo at priority level 98 (default being 99, lower numbers
"win"). I left it out because generally Change Proposals aren't
required to document every minor implementation detail.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

[Vít Ondruch]

Dne 01. 04. 20 v 16:01 David Cantrell napsal(a):
> On Wed, Apr 01, 2020 at 10:19:08AM +0200, Vít Ondruch wrote:
>> So although this update clarifies some part, we have not moved anywhere:
>>
>>
>> ~~~
>>
>> === Can we do this in a branch instead of in master? ===
>>
>> This adds no value to the current approach where Red Hat maintainers
>> would manually merge their changes into the internal build
>> infrastructure. There's no way to automate the sync from the `master`
>> branch to the `eln` branch that wouldn't break and require maintainer
>> involvement. Attempting to branch only individual packages would
>> introduce significant complexity in the build process as well, leading
>> to far more opportunity for bugs. Lastly, even the most diligent of
>> maintainers can forget to sync every change to a new branch, thus
>> leaving us in a situation where the `eln` branch has fallen behind and
>> is no longer providing an accurate view of whether the package is still
>> building or functioning in that environment.
>>
>> ~~~
>>
>>
>> I wonder where this comes from. I am participating in this thread,
>> representing Ruby maintainers in RHEL and Fedora, in other places of the
>> thread, I see Miro Hrončok, Tomáš Orsava and Pert Viktorin representing
>> Python RHEL and Fedora maitainers, as well as Petr Písař, the RHEL and
>> Fedora representative of Perl. All in all, it represents ~1/2 packages
>> in Fedora/RHEL. I hope that I can say that these people shares a view
>> that branch, fork, PR is the way to go.
>>
>> Yet we are not able to convince you. So I wonder who this proposal
>> actually represents? Who is the target audience? Who are the Red Hat
>> maintainers you mentioned in the proposal?
>>
>
> I think the FAQ entry above could be phrased better, but my
> understanding is
> that we should really want rawhide to be where upstream RHEL work
> happens.
> Creating another branch for this work effectively creates two rawhides
> and I
> think ELN would suffer as a result.


Of course what can go into Rawhide should go into Rawhide, but that are
not ELN/RHEL conditionals.


Vít


>
>
> Another thing to consider is that we should want ELN builds happening as
> rapidly as rawhide builds.  ELN is not something to set up and
> maintain as it
> were RHEL.
>
> Thanks,
>
>>
>>
>> Dne 31. 03. 20 v 17:31 Stephen Gallagher napsal(a):
>>> I sent out the V2 version of the Change on Friday and then promptly
>>> managed to injure myself and be away from email until today. I've read
>>> through the email threads again this morning and I decided that,
>>> rather than try to address them one by one, I'd try again with a V3
>>> that hopefully answers some of the repeated questions and concerns on
>>> that list.
>>>
>>> Please see the newly-updated
>>> https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>>> for more details[1].
>>>
>>>
>>> [1]
>>> https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose&type=revision&diff=569904&oldid=569809
>>> ___
>>> 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
>
___
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: CPE Git Forge Decision

[Felix Schwarz]

Am 01.04.20 um 08:42 schrieb Clement Verna:
> I think this feeling comes from the mixing of git forge and dist-git use case
> that you have pointed out.

That seems to be the core of all the talk about "feature gaps" - obviously
pagure is not nearly as advanced as gitlab/github when you want "some space
for generic software development" (and probably will never be).

However using a generic git forge means we need a separate "self-service
application" for administration of Fedora packages. We had that in the past
(packagedb).

I don't want to presume too much but I just hope you researched why packagedb
was decommissioned and why people thought integrating the functionality into
pagure was a good idea?

Right now this really feels like a kind of ping-pong (from packagedb to pagure
to packagedb2?). I'm not against reversing decisions when the environment
changes or just because after careful consideration something seems like a
better choice. Still I'm worried that the CPE team might have missed some of
the lessons learned in the past...

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

Re: CPE Git Forge Decision

[Vít Ondruch]

Dne 01. 04. 20 v 15:34 Neal Gompa napsal(a):
> On Wed, Apr 1, 2020 at 9:26 AM Vít Ondruch  wrote:
>>
>> Dne 01. 04. 20 v 14:33 Alex Scheel napsal(a):
>>> - Original Message -
 From: "Panu Matilainen" 
 To: devel@lists.fedoraproject.org
 Sent: Wednesday, April 1, 2020 6:22:39 AM
 Subject: Re: CPE Git Forge Decision

> I also appreciate that as a community developing our own solutions is
> something important and something that seems to matter a lot, but we
> have to realize that the development and maintenance effort cannot be
> carried out by the CPE team any more. Maybe this is a opportunity to
> create a SIG or a working group for people that are interested to carry
> on this effort.
 But this is precisely at the heart of the problem: people feel they were
 not given an opportunity to lend a hand, and that now its too late
 because the messaging is that we go with GitLab, no matter what.
>>> Pagure has huge developer experience bugs filed against it for many
>>> years. Where have all these contributors been? Are those of us who really
>>> dislike Pagure's workflows in the minority?
>>
>> Since you are asking, for dist-git and for ticket tracking in Fedora,
>> Pagure is much better than what we ever had and with one exception (I am
>> missing easy access to history of a file), there is not missing anything
>> substantial.
>>
> We're getting this on the next Pagure upgrade:
> https://stg.pagure.io/rpm-packages/pagure/history/pagure.spec
>

Cool, so then I won't miss any substantial feature for dist-git ;) Thank
you!


Vít
___
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 FTBFS packages to be orphaned in 1 week

[Ian McInerney]

>
>
> x11vnc   hubbitus
>

It looks like this one just needs a new build kicked off for Rawhide and
the Rawhide spec merged into f32, since it was a GCC10 failure and it
appears the spec has been fixed for rawhide since then.

-Ian
___
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: CPE Git Forge Decision

[Leigh Griffin]

On Wed, Apr 1, 2020 at 2:47 PM Frank Ch. Eigler  wrote:

>
> > [...] Nor would it have helped with the SLA requirements and
> > operational cost. [...]
>
> What reason is there to believe that a gitlab commercial SaaS might a
> smaller operational cost?
>

I meant that in the sense of the time we invest in it to develop features,
fix bugs, keep it on the air etc.

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


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


___
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: Heads-up: RPM 4.16 alpha coming to rawhide

[Miro Hrončok]

On 01. 04. 20 9:11, Panu Matilainen wrote:
Besides meta-packages, another potential use-case for meta (whether Requires or 
weak dependencies) is those just-in-case dependencies across sub-packages to 
ensure nobody runs weird combinations even though sonames might permit it. Often 
they are in the same direction as the soname dependency so it doesn't create any 
additional ordering issues but sometimes they're in the opposite direction, 
creating a wholly unnecessary dependency loop. Rpm itself is an example of this 
(but we can't really use "meta" anytime soon as rpm needs to be bootstrappable 
from older versions)


Something like this?

https://fedoraproject.org/wiki/Changes/Automatic_strict_inter-package_dependencies

--
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 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

[David Cantrell]

On Wed, Apr 01, 2020 at 10:19:08AM +0200, Vít Ondruch wrote:

So although this update clarifies some part, we have not moved anywhere:


~~~

=== Can we do this in a branch instead of in master? ===

This adds no value to the current approach where Red Hat maintainers
would manually merge their changes into the internal build
infrastructure. There's no way to automate the sync from the `master`
branch to the `eln` branch that wouldn't break and require maintainer
involvement. Attempting to branch only individual packages would
introduce significant complexity in the build process as well, leading
to far more opportunity for bugs. Lastly, even the most diligent of
maintainers can forget to sync every change to a new branch, thus
leaving us in a situation where the `eln` branch has fallen behind and
is no longer providing an accurate view of whether the package is still
building or functioning in that environment.

~~~


I wonder where this comes from. I am participating in this thread,
representing Ruby maintainers in RHEL and Fedora, in other places of the
thread, I see Miro Hrončok, Tomáš Orsava and Pert Viktorin representing
Python RHEL and Fedora maitainers, as well as Petr Písař, the RHEL and
Fedora representative of Perl. All in all, it represents ~1/2 packages
in Fedora/RHEL. I hope that I can say that these people shares a view
that branch, fork, PR is the way to go.

Yet we are not able to convince you. So I wonder who this proposal
actually represents? Who is the target audience? Who are the Red Hat
maintainers you mentioned in the proposal?



I think the FAQ entry above could be phrased better, but my understanding is
that we should really want rawhide to be where upstream RHEL work happens.
Creating another branch for this work effectively creates two rawhides and I
think ELN would suffer as a result.

Another thing to consider is that we should want ELN builds happening as
rapidly as rawhide builds.  ELN is not something to set up and maintain as it
were RHEL.

Thanks,




Dne 31. 03. 20 v 17:31 Stephen Gallagher napsal(a):

I sent out the V2 version of the Change on Friday and then promptly
managed to injure myself and be away from email until today. I've read
through the email threads again this morning and I decided that,
rather than try to address them one by one, I'd try again with a V3
that hopefully answers some of the repeated questions and concerns on
that list.

Please see the newly-updated
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
for more details[1].


[1] 
https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose&type=revision&diff=569904&oldid=569809
___
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


--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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: CPE Git Forge Decision

[Frank Ch. Eigler]

> [...] Nor would it have helped with the SLA requirements and
> operational cost. [...]

What reason is there to believe that a gitlab commercial SaaS might a
smaller operational cost?

- FChE
___
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: CPE Git Forge Decision

[Neal Gompa]

On Wed, Apr 1, 2020 at 9:26 AM Vít Ondruch  wrote:
>
>
> Dne 01. 04. 20 v 14:33 Alex Scheel napsal(a):
> > - Original Message -
> >> From: "Panu Matilainen" 
> >> To: devel@lists.fedoraproject.org
> >> Sent: Wednesday, April 1, 2020 6:22:39 AM
> >> Subject: Re: CPE Git Forge Decision
> >>
> >>> I also appreciate that as a community developing our own solutions is
> >>> something important and something that seems to matter a lot, but we
> >>> have to realize that the development and maintenance effort cannot be
> >>> carried out by the CPE team any more. Maybe this is a opportunity to
> >>> create a SIG or a working group for people that are interested to carry
> >>> on this effort.
> >> But this is precisely at the heart of the problem: people feel they were
> >> not given an opportunity to lend a hand, and that now its too late
> >> because the messaging is that we go with GitLab, no matter what.
> > Pagure has huge developer experience bugs filed against it for many
> > years. Where have all these contributors been? Are those of us who really
> > dislike Pagure's workflows in the minority?
>
>
> Since you are asking, for dist-git and for ticket tracking in Fedora,
> Pagure is much better than what we ever had and with one exception (I am
> missing easy access to history of a file), there is not missing anything
> substantial.
>

We're getting this on the next Pagure upgrade:
https://stg.pagure.io/rpm-packages/pagure/history/pagure.spec



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads-up: RPM 4.16 alpha coming to rawhide

[Panu Matilainen]

On 4/1/20 4:24 PM, Stephen Gallagher wrote:

On Wed, Apr 1, 2020 at 3:11 AM Panu Matilainen  wrote:


On 3/31/20 3:34 PM, Stephen Gallagher wrote:

On Tue, Mar 31, 2020 at 8:10 AM Panu Matilainen  wrote:


It's that time of year again... as our RPM change proposals passed with
flying colors in yesterdays meeting, I'll hope to land RPM 4.16 alpha in
rawhide later today or tomorrow by latest.



Since Panu left it out of his announcement, I'd also like to mention
that RPM 4.16 adds the following new feature:

"Add support for meta dependencies (eg Requires(meta): somepkg) that
do not affect install/erase ordering (RhBug:1648721)"

These dependencies are intended for use with metapackages and help
with avoiding dependency loops. Essentially, a `Requires(meta):`
dependency is telling RPM: at the end of any transaction where this
package is installed, this dependency must also be installed, but I
don't need the dependency ordered earlier.

This is going to come in handy for the Fedora Release packages (like
fedora-release-server) which will be able to define a minimal "API" to
be recognized as that Edition (or Spin). This didn't work before this
feature was added, because fedora-release must be ordered early in the
transaction to set up things like /etc/os-release, so we couldn't set
dependencies.


Oh, thanks for the reminder about this Stephen.

Besides meta-packages, another potential use-case for meta (whether
Requires or weak dependencies) is those just-in-case dependencies across
sub-packages to ensure nobody runs weird combinations even though
sonames might permit it. Often they are in the same direction as the
soname dependency so it doesn't create any additional ordering issues
but sometimes they're in the opposite direction, creating a wholly
unnecessary dependency loop. Rpm itself is an example of this (but we
can't really use "meta" anytime soon as rpm needs to be bootstrappable
from older versions)


Do you mean things like:

Requires: libfoo >= 3.4.2-3
could become
Requires(meta): libfoo >= 3.4.2-3

What about things like ensuring that subpackages are running the same
version as the main package so they get updated together?


This latter case is what I meant by the above, apparently not very 
clearly :)


Care needs to be taken though when adding "meta" to things like this as 
in many cases the order *does* matter.


- Panu -
___
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: CPE Git Forge Decision

[Vít Ondruch]

Dne 01. 04. 20 v 14:33 Alex Scheel napsal(a):
> - Original Message -
>> From: "Panu Matilainen" 
>> To: devel@lists.fedoraproject.org
>> Sent: Wednesday, April 1, 2020 6:22:39 AM
>> Subject: Re: CPE Git Forge Decision
>>
>>> I also appreciate that as a community developing our own solutions is
>>> something important and something that seems to matter a lot, but we
>>> have to realize that the development and maintenance effort cannot be
>>> carried out by the CPE team any more. Maybe this is a opportunity to
>>> create a SIG or a working group for people that are interested to carry
>>> on this effort.
>> But this is precisely at the heart of the problem: people feel they were
>> not given an opportunity to lend a hand, and that now its too late
>> because the messaging is that we go with GitLab, no matter what.
> Pagure has huge developer experience bugs filed against it for many
> years. Where have all these contributors been? Are those of us who really
> dislike Pagure's workflows in the minority?


Since you are asking, for dist-git and for ticket tracking in Fedora,
Pagure is much better than what we ever had and with one exception (I am
missing easy access to history of a file), there is not missing anything
substantial.

OTOH, GitLab UI is overwhelming, much harder to navigate. And moreover,
we don't have it and it won't be free neither easy to have it.

I read your list on some other place, I don't say it is wrong, but it
seems you don't appreciate the step forward from CGit and frankly they
are more or less just paper cuts.


Vít


>  Or are others more prone
> to put up with it because it is free, open source software?
>
>
> IMO, it seems like an ideological argument, not a sound technical
> one.
>
> - Alex
> ___
> 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: Heads-up: RPM 4.16 alpha coming to rawhide

[Stephen Gallagher]

On Wed, Apr 1, 2020 at 3:11 AM Panu Matilainen  wrote:
>
> On 3/31/20 3:34 PM, Stephen Gallagher wrote:
> > On Tue, Mar 31, 2020 at 8:10 AM Panu Matilainen  wrote:
> >>
> >> It's that time of year again... as our RPM change proposals passed with
> >> flying colors in yesterdays meeting, I'll hope to land RPM 4.16 alpha in
> >> rawhide later today or tomorrow by latest.
> >>
> >
> > Since Panu left it out of his announcement, I'd also like to mention
> > that RPM 4.16 adds the following new feature:
> >
> > "Add support for meta dependencies (eg Requires(meta): somepkg) that
> > do not affect install/erase ordering (RhBug:1648721)"
> >
> > These dependencies are intended for use with metapackages and help
> > with avoiding dependency loops. Essentially, a `Requires(meta):`
> > dependency is telling RPM: at the end of any transaction where this
> > package is installed, this dependency must also be installed, but I
> > don't need the dependency ordered earlier.
> >
> > This is going to come in handy for the Fedora Release packages (like
> > fedora-release-server) which will be able to define a minimal "API" to
> > be recognized as that Edition (or Spin). This didn't work before this
> > feature was added, because fedora-release must be ordered early in the
> > transaction to set up things like /etc/os-release, so we couldn't set
> > dependencies.
>
> Oh, thanks for the reminder about this Stephen.
>
> Besides meta-packages, another potential use-case for meta (whether
> Requires or weak dependencies) is those just-in-case dependencies across
> sub-packages to ensure nobody runs weird combinations even though
> sonames might permit it. Often they are in the same direction as the
> soname dependency so it doesn't create any additional ordering issues
> but sometimes they're in the opposite direction, creating a wholly
> unnecessary dependency loop. Rpm itself is an example of this (but we
> can't really use "meta" anytime soon as rpm needs to be bootstrappable
> from older versions)

Do you mean things like:

Requires: libfoo >= 3.4.2-3
could become
Requires(meta): libfoo >= 3.4.2-3

What about things like ensuring that subpackages are running the same
version as the main package so they get updated together?
___
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: CPE Git Forge Decision

[Vít Ondruch]

Dne 01. 04. 20 v 12:37 Miro Hrončok napsal(a):
> On 01. 04. 20 10:53, Vít Ondruch wrote:
>>
>> Dne 01. 04. 20 v 10:37 Michal Konecny napsal(a):
>>>
>>>
>>> On 31/03/2020 20:53, Kevin Fenzi wrote:
 On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
 ...snip...
> Because of switching costs, this is likely to prevent us from
> going back to
> Pagure if it does develop a vibrant independent community. That
> would be
> unfortunate.
 So, currently we are using pagure on src.fedoraproject.org, but
 it's not
 just pagure, it's a integration layer over the top of pagure too.

 I'd like to see if we can, as part of this: a) adjust our packaging
 workflow (as many threads on this list have talked about) and b) after
 that, try and reduce that integration layer as much as we can and c)
 hopefully make it so we could move the backend git repos / forge later
 if we wanted to without recreating a big integration layer.
>>> To be clear, you mean something like app above the dist-git where
>>> you could do most of the things that are needed for dist-git with
>>> git forge only being a package source with various branches?
>>>
>>> Something like web UI that allows you to do retirement, change
>>> notification settings, has links to various other systems, with on
>>> of them the git that is hosting the code for package, without
>>> actually thinking what git forge is used for the hosting?
>>
>>
>> Do you mean https://github.com/fedora-infra/pkgdb2/ ? :)
>
> That's actually what rpmfusion is doing. They have pkgdb + github repos.


I know, I mentioned PkdDB just half jokingly, because this is like
walking in circles ...


Vít


>
> (Not sure if still, but it was the case around a year ago.)
>
>
___
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: CPE Git Forge Decision

[Solomon Peachy]

On Wed, Apr 01, 2020 at 03:04:57PM +0200, Clement Verna wrote:
> What does NIH stands for ?

https://en.wikipedia.org/wiki/Not_invented_here

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
High Springs, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


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: CPE Git Forge Decision

[Emmanuel Seyman]

* Clement Verna [01/04/2020 15:04] :
>
> What does NIH stands for ?

Not invented here (see https://en.wikipedia.org/wiki/Not_invented_here
for the gory details)

Emmanuel
___
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: CPE Git Forge Decision

[Vít Ondruch]

Dne 01. 04. 20 v 14:41 Michal Konecny napsal(a):
>
>
> On 01/04/2020 10:53, Vít Ondruch wrote:
>>
>>
>> Dne 01. 04. 20 v 10:37 Michal Konecny napsal(a):
>>>
>>>
>>> On 31/03/2020 20:53, Kevin Fenzi wrote:
 On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
 ...snip...
> Because of switching costs, this is likely to prevent us from going back 
> to
> Pagure if it does develop a vibrant independent community. That would be
> unfortunate.
 So, currently we are using pagure on src.fedoraproject.org, but it's not
 just pagure, it's a integration layer over the top of pagure too. 

 I'd like to see if we can, as part of this: a) adjust our packaging
 workflow (as many threads on this list have talked about) and b) after
 that, try and reduce that integration layer as much as we can and c)
 hopefully make it so we could move the backend git repos / forge later
 if we wanted to without recreating a big integration layer.
>>> To be clear, you mean something like app above the dist-git where
>>> you could do most of the things that are needed for dist-git with
>>> git forge only being a package source with various branches?
>>>
>>> Something like web UI that allows you to do retirement, change
>>> notification settings, has links to various other systems, with on
>>> of them the git that is hosting the code for package, without
>>> actually thinking what git forge is used for the hosting?
>>
>>
>> Do you mean https://github.com/fedora-infra/pkgdb2/ ? :)
>>
>>
>> Vít
>>
>>
> I meant something more user friendly, this is just an API


Don't be mistaken, this is not just API but full fledged web app with UI.


> , which is not easy to use for everyone.


This is of course always questionable :)


Vít


>
> Michal
>>
>>>
>>> If yes, than I'm into this and it doesn't matter for me where the
>>> packages are hosted anymore.
>>>
>>> Michal
 As part of that we could also provide whats needed for the integration
 and the pagure community could add anything they don't already have on
 their roadmap. 

 kevin 

 ___
 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
>>>
>>> -- 
>>> Role: Fedora CPE Team - Software Engineer
>>> IRC: mkonecny
>>> FAS: zlopez
>>>
>>> ___
>>> 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
>
> -- 
> Role: Fedora CPE Team - Software Engineer
> IRC: mkonecny
> FAS: zlopez
>
> ___
> 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: CPE Git Forge Decision

[Clement Verna]

On Wed, 1 Apr 2020 at 14:40, Stephen John Smoogen  wrote:

>
>
> On Wed, 1 Apr 2020 at 08:16, Pierre-Yves Chibon 
> wrote:
>
>> On Wed, Apr 01, 2020 at 11:49:41AM +0200, Clement Verna wrote:
>> >There is also an historical taste to write in house applications for
>> >things that don't really seems critical to the Fedora Project, for
>> example
>> >do we really need a custom calendar application ? or election
>> application
>> >? It seems that every time we have a problem the solution is let's
>> write
>> >something to solve that problem, instead of trying to find a
>> compromise
>> >and reuse existing solutions.
>>
>> Could please stop this?
>>
>>
> This is me also asking this.
>
>
>
>> The continuous theme of "we're building things because we like it" is
>> unfair to
>> all the people who have been involved in the infrastructure at some point
>> in the
>> past.
>> It is assuming that there was no reasons, that they did not do their
>> research,
>> that they didn't think it through.
>>
>> The requirements for applications 3 years ago were vastly different from
>> what
>> they are today.
>> If you don't know the historical reasons for an app, there are a number of
>> people around who can answer them, but please let's stop assuming things
>> which
>> are at the end of the day insulting and demotivating for the people who
>> were
>> involved then and are still now.
>>
>> This goes for fedocal, for pagure, for anitya. I've seen this question
>> come up
>> often enough (here and elsewhere): "Why aren't we using libraries.io
>> instead of
>> anytia?"
>> Well, the simple reason is: because libraries.io *did* *not* *exist*
>> when anitya
>> was created. So maybe we are not the bad ones that didn't do their
>> research.
>>
>>
> I am also sick and tired of this. For many years, a central drive for
> Fedora Infra was about building the Free and Open Source tools to allow a
> community to work together without using closed source tools. This was a
> constant requirement of the community to us at the time with wanting
> something to 'compete' against Canonical's forge and Canonicals' other
> tools. Things have changed but instead of saying "Good job, thanks for all
> that work but we have decided to change.", our efforts are brought up
> constantly as a bunch of NIH who wasted time and effort. And it doesn't
> matter how many times people are reminded that we had reasons and research
> for doing this from 2005 to 2015.. it gets thrown in our faces that we
> reinvented the wheel when there were clearly better things to spend our
> time on.
>
>
Ok fair and thanks for pointing and raising that point. It is also good to
share that historical context to people like me that where not around
during that time. Again apologies, this was not at all my intention to
point fingers at people.

What does NIH stands for ?


>
>
> --
> 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
>
___
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-IoT-32-20200401.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/8 (x86_64)

New failures (same test not failed in Fedora-IoT-32-20200328.0):

ID: 563097  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/563097

Passed openQA tests: 7/8 (x86_64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
1 services(s) added since previous compose: zezere_ignition.service
Previous test data: https://openqa.fedoraproject.org/tests/559720#downloads
Current test data: https://openqa.fedoraproject.org/tests/563091#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
1 services(s) added since previous compose: zezere_ignition.service
System load changed from 0.06 to 0.17
Previous test data: https://openqa.fedoraproject.org/tests/559721#downloads
Current test data: https://openqa.fedoraproject.org/tests/563092#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

Re: CPE Git Forge Decision

[Clement Verna]

On Wed, 1 Apr 2020 at 14:16, Pierre-Yves Chibon  wrote:

> On Wed, Apr 01, 2020 at 11:49:41AM +0200, Clement Verna wrote:
> >There is also an historical taste to write in house applications for
> >things that don't really seems critical to the Fedora Project, for
> example
> >do we really need a custom calendar application ? or election
> application
> >? It seems that every time we have a problem the solution is let's
> write
> >something to solve that problem, instead of trying to find a
> compromise
> >and reuse existing solutions.
>
> Could please stop this?
>

> The continuous theme of "we're building things because we like it" is
> unfair to
> all the people who have been involved in the infrastructure at some point
> in the
> past.
> It is assuming that there was no reasons, that they did not do their
> research,
> that they didn't think it through.
>
> The requirements for applications 3 years ago were vastly different from
> what
> they are today.
> If you don't know the historical reasons for an app, there are a number of
> people around who can answer them, but please let's stop assuming things
> which
> are at the end of the day insulting and demotivating for the people who
> were
> involved then and are still now.
>
> This goes for fedocal, for pagure, for anitya. I've seen this question
> come up
> often enough (here and elsewhere): "Why aren't we using libraries.io
> instead of
> anytia?"
> Well, the simple reason is: because libraries.io *did* *not* *exist* when
> anitya
> was created. So maybe we are not the bad ones that didn't do their
> research.
>
>
> I am not saying that we can't re-evaluate these decision and see if they
> still
> make sense, but please, please, can we stop assuming the worst?
>
>
I apologize if that came down that way but this is exactly what I was
trying to say at the end of my email (see below since it was cut here) . I
am 100% sure that decision taken in the past were the best decision at that
time and I am honestly not in position to judge or to say anything about
it.

"
Finally, I would like to make clear that I am not blaming anyone, and that
decisions made in the past, I am sure were taken with the best intentions.
But I think it is also important to recognize that it is legitimate to
question these decisions today as something that made sense 10 years ago or
5 years ago might not make sense in today's context.
"

>
> >Now when the CPE team goes and ask for more people because we struggle
> >with current situation, I can only guess that these non critical
> >applications are mentioned. If I was putting my own money to sponsor a
> >team to help building a Linux distribution I would be asking why do we
> >have to develop a calendar application or why do we need a custom git
> >forge.
>
> Here as well, what you believe CPE is meant to be is immensely different
> than
> what the Fedora Infrastructure (Fedora Engineering) team was just a few
> years
> ago.
> So asking these questions and taking this angle may make sense with the new
> vision but you would have a much different picture if you were looking at
> them
> from the old vision, or the one before that, or the next one.
>
> Let's be aware that Fedora Infra's job hasn't been "Building a linux
> distro"
> since it's inception, for a long time its goal was much closer to
> "building and
> supporting the *community* that builds the linux distro".
> If you use this mission statement, you can a much different look at badges,
> elections or calendaring.
>

Yeah again agree with that, and I think this is what I was trying to say by
mentioning that we should look at these with today's context in mind. Again
sorry if I failed to express that point clearly.


>
>
>
> Piere
> ___
> 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: CPE Git Forge Decision

[Neal Gompa]

On Wed, Apr 1, 2020 at 8:34 AM Alex Scheel  wrote:
>
> - Original Message -
> > From: "Panu Matilainen" 
> > To: devel@lists.fedoraproject.org
> > Sent: Wednesday, April 1, 2020 6:22:39 AM
> > Subject: Re: CPE Git Forge Decision
> >
>
> > > I also appreciate that as a community developing our own solutions is
> > > something important and something that seems to matter a lot, but we
> > > have to realize that the development and maintenance effort cannot be
> > > carried out by the CPE team any more. Maybe this is a opportunity to
> > > create a SIG or a working group for people that are interested to carry
> > > on this effort.
> >
> > But this is precisely at the heart of the problem: people feel they were
> > not given an opportunity to lend a hand, and that now its too late
> > because the messaging is that we go with GitLab, no matter what.
>
> Pagure has huge developer experience bugs filed against it for many
> years. Where have all these contributors been? Are those of us who really
> dislike Pagure's workflows in the minority? Or are others more prone
> to put up with it because it is free, open source software?
>
>
> IMO, it seems like an ideological argument, not a sound technical
> one.

Technical issues can always be resolved, ideological ones rarely so. I
would say it's a combination of disinterest in the issues you've
pointed out and general willingness to put up with bugs because it
aligns better with their philosophy.

Generally speaking, Pagure has served most of the workflows well for
package maintainers and has been a nice lightweight solution we can
easily extend for our needs. As a general forge, it has been somewhat
lacking because the principal interest (until *very* recently) has
been around using it as a dist-git system.

With the adoption of Pagure by parties who intend to use it more as a
general forge, I expect contributions to move towards improving this
aspect of the experience. It's not *bad* at being a general forge,
it's just not *as good* as proprietary alternatives yet. But ideology
+ technical capability + scratching itches is how most FOSS gets
better. If you don't have that, well... why bother?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

[Michal Konecny]

On 01/04/2020 10:53, Vít Ondruch wrote:



Dne 01. 04. 20 v 10:37 Michal Konecny napsal(a):



On 31/03/2020 20:53, Kevin Fenzi wrote:

On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
...snip...

Because of switching costs, this is likely to prevent us from going back to
Pagure if it does develop a vibrant independent community. That would be
unfortunate.

So, currently we are using pagure on src.fedoraproject.org, but it's not
just pagure, it's a integration layer over the top of pagure too.

I'd like to see if we can, as part of this: a) adjust our packaging
workflow (as many threads on this list have talked about) and b) after
that, try and reduce that integration layer as much as we can and c)
hopefully make it so we could move the backend git repos / forge later
if we wanted to without recreating a big integration layer.
To be clear, you mean something like app above the dist-git where you 
could do most of the things that are needed for dist-git with git 
forge only being a package source with various branches?


Something like web UI that allows you to do retirement, change 
notification settings, has links to various other systems, with on of 
them the git that is hosting the code for package, without actually 
thinking what git forge is used for the hosting?



Do you mean https://github.com/fedora-infra/pkgdb2/ ? :)


Vít


I meant something more user friendly, this is just an API, which is not 
easy to use for everyone.


Michal




If yes, than I'm into this and it doesn't matter for me where the 
packages are hosted anymore.


Michal

As part of that we could also provide whats needed for the integration
and the pagure community could add anything they don't already have on
their roadmap.

kevin

___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez

___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez

___
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: CPE Git Forge Decision

[Stephen John Smoogen]

On Wed, 1 Apr 2020 at 08:16, Pierre-Yves Chibon  wrote:

> On Wed, Apr 01, 2020 at 11:49:41AM +0200, Clement Verna wrote:
> >There is also an historical taste to write in house applications for
> >things that don't really seems critical to the Fedora Project, for
> example
> >do we really need a custom calendar application ? or election
> application
> >? It seems that every time we have a problem the solution is let's
> write
> >something to solve that problem, instead of trying to find a
> compromise
> >and reuse existing solutions.
>
> Could please stop this?
>
>
This is me also asking this.



> The continuous theme of "we're building things because we like it" is
> unfair to
> all the people who have been involved in the infrastructure at some point
> in the
> past.
> It is assuming that there was no reasons, that they did not do their
> research,
> that they didn't think it through.
>
> The requirements for applications 3 years ago were vastly different from
> what
> they are today.
> If you don't know the historical reasons for an app, there are a number of
> people around who can answer them, but please let's stop assuming things
> which
> are at the end of the day insulting and demotivating for the people who
> were
> involved then and are still now.
>
> This goes for fedocal, for pagure, for anitya. I've seen this question
> come up
> often enough (here and elsewhere): "Why aren't we using libraries.io
> instead of
> anytia?"
> Well, the simple reason is: because libraries.io *did* *not* *exist* when
> anitya
> was created. So maybe we are not the bad ones that didn't do their
> research.
>
>
I am also sick and tired of this. For many years, a central drive for
Fedora Infra was about building the Free and Open Source tools to allow a
community to work together without using closed source tools. This was a
constant requirement of the community to us at the time with wanting
something to 'compete' against Canonical's forge and Canonicals' other
tools. Things have changed but instead of saying "Good job, thanks for all
that work but we have decided to change.", our efforts are brought up
constantly as a bunch of NIH who wasted time and effort. And it doesn't
matter how many times people are reminded that we had reasons and research
for doing this from 2005 to 2015.. it gets thrown in our faces that we
reinvented the wheel when there were clearly better things to spend our
time on.



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

Re: CPE Git Forge Decision

[Alex Scheel]

- Original Message -
> From: "Panu Matilainen" 
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, April 1, 2020 6:22:39 AM
> Subject: Re: CPE Git Forge Decision
> 

> > I also appreciate that as a community developing our own solutions is
> > something important and something that seems to matter a lot, but we
> > have to realize that the development and maintenance effort cannot be
> > carried out by the CPE team any more. Maybe this is a opportunity to
> > create a SIG or a working group for people that are interested to carry
> > on this effort.
> 
> But this is precisely at the heart of the problem: people feel they were
> not given an opportunity to lend a hand, and that now its too late
> because the messaging is that we go with GitLab, no matter what.

Pagure has huge developer experience bugs filed against it for many
years. Where have all these contributors been? Are those of us who really
dislike Pagure's workflows in the minority? Or are others more prone
to put up with it because it is free, open source software?


IMO, it seems like an ideological argument, not a sound technical
one.

- Alex
___
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-Cloud-31-20200401.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
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

Re: CPE Git Forge Decision

[Pierre-Yves Chibon]

On Wed, Apr 01, 2020 at 11:49:41AM +0200, Clement Verna wrote:
>There is also an historical taste to write in house applications for
>things that don't really seems critical to the Fedora Project, for example
>do we really need a custom calendar application ? or election application
>? It seems that every time we have a problem the solution is let's write
>something to solve that problem, instead of trying to find a compromise
>and reuse existing solutions.

Could please stop this?

The continuous theme of "we're building things because we like it" is unfair to
all the people who have been involved in the infrastructure at some point in the
past.
It is assuming that there was no reasons, that they did not do their research,
that they didn't think it through.

The requirements for applications 3 years ago were vastly different from what
they are today.
If you don't know the historical reasons for an app, there are a number of
people around who can answer them, but please let's stop assuming things which
are at the end of the day insulting and demotivating for the people who were
involved then and are still now.

This goes for fedocal, for pagure, for anitya. I've seen this question come up
often enough (here and elsewhere): "Why aren't we using libraries.io instead of
anytia?"
Well, the simple reason is: because libraries.io *did* *not* *exist* when anitya
was created. So maybe we are not the bad ones that didn't do their research.


I am not saying that we can't re-evaluate these decision and see if they still
make sense, but please, please, can we stop assuming the worst?


>Now when the CPE team goes and ask for more people because we struggle
>with current situation, I can only guess that these non critical
>applications are mentioned. If I was putting my own money to sponsor a
>team to help building a Linux distribution I would be asking why do we
>have to develop a calendar application or why do we need a custom git
>forge. 

Here as well, what you believe CPE is meant to be is immensely different than
what the Fedora Infrastructure (Fedora Engineering) team was just a few years
ago.
So asking these questions and taking this angle may make sense with the new
vision but you would have a much different picture if you were looking at them
from the old vision, or the one before that, or the next one.

Let's be aware that Fedora Infra's job hasn't been "Building a linux distro"
since it's inception, for a long time its goal was much closer to "building and
supporting the *community* that builds the linux distro".
If you use this mission statement, you can a much different look at badges,
elections or calendaring.



Piere
___
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: silly question: finding root.log/build.log of FTBS F32 package (slim)

[Richard Shaw]

On Tue, Mar 31, 2020 at 11:12 PM Samuel Sieb  wrote:

> On 3/31/20 7:16 PM, Richard Shaw wrote:
> >
> > It doesn't look like the spec can even be parsed... Something must be
> > off. There are conditionals in the spec for Fedora 15 so that tells me
> > the spec file is in major need of an overhaul. Also cmake is being
> > called directly instead of using %cmake.
>
> How did you find that?  I can't even find the build in koji, just the task.
>

Well the lack of using %cmake jumped out at me because I maintain a lot of
cmake based packages. The problem with the %systemd_postun I had to google
because the error, quite irritatingly, did not provide a line number. I
only did local mock build for Rawhide and f31, not in koji, but I can do so
if you like but I believe it's safe to do the official "fedpkg build" at
this point.

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: CPE Git Forge Decision

[Neal Gompa]

On Wed, Apr 1, 2020 at 7:47 AM Jeff Fearn  wrote:
>
> On 1/4/20 21:11, Bruno Wolff III wrote:
> > On Wed, Apr 01, 2020 at 12:39:21 +0200,
> >  Florian Weimer  wrote:
> >> * Bruno Wolff, III:
> >>
> >>> RHEL is a special case, as CENTOS provides a free drop in replacement
> >>> and switching from CENTOS to Fedora shouldn't be much work. Is there
> >>> other proprietary software at the OS level or above, that is used for
> >>> Fedora infrastructure?
> >>
> >> The Bugzilla fork running on bugzilla.redhat.com?
> >>
> >>  
> >
> > That was an interesting read. It sounds like corners were cut under the
> > assumption that there would be no desire to share the code. Specifically
> > code and config were mixed together and the config can't be released.
>
> A lot of time and effort was spent getting code audits done and fixing
> the issues raised.
>
> It's seriously depressing it still isn't public.
>

It'd be great if it was. There's some interest in SUSE and other
places of running an instance of the Red Hat Bugzilla code since it's
better suited for Linux distributions and has some really nice
features for supporting that.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

[Jeff Fearn]

On 1/4/20 21:11, Bruno Wolff III wrote:
> On Wed, Apr 01, 2020 at 12:39:21 +0200,
>  Florian Weimer  wrote:
>> * Bruno Wolff, III:
>>
>>> RHEL is a special case, as CENTOS provides a free drop in replacement
>>> and switching from CENTOS to Fedora shouldn't be much work. Is there
>>> other proprietary software at the OS level or above, that is used for
>>> Fedora infrastructure?
>>
>> The Bugzilla fork running on bugzilla.redhat.com?
>>
>>  
> 
> That was an interesting read. It sounds like corners were cut under the
> assumption that there would be no desire to share the code. Specifically
> code and config were mixed together and the config can't be released.

A lot of time and effort was spent getting code audits done and fixing
the issues raised.

It's seriously depressing it still isn't public.

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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

[Pavel Valena]

- Original Message -
> From: "Vít Ondruch" 
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, April 1, 2020 10:19:08 AM
> Subject: Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose 
> V3
> 
> So although this update clarifies some part, we have not moved anywhere:
> 
> 
> ~~~
> 
> === Can we do this in a branch instead of in master? ===
> 
> This adds no value to the current approach where Red Hat maintainers
> would manually merge their changes into the internal build
> infrastructure. There's no way to automate the sync from the `master`
> branch to the `eln` branch that wouldn't break and require maintainer
> involvement. Attempting to branch only individual packages would
> introduce significant complexity in the build process as well, leading
> to far more opportunity for bugs. Lastly, even the most diligent of
> maintainers can forget to sync every change to a new branch, thus
> leaving us in a situation where the `eln` branch has fallen behind and
> is no longer providing an accurate view of whether the package is still
> building or functioning in that environment.

I'm actually doing this in my COPR all rubygems[1], as a part of my (mostly 
automated) workflow. It does add some manual overhead, but I think it's doable 
(maintaining the additional branch), but only if one can force-push into it.

Regards,
Pavel

[1] https://copr.fedorainfracloud.org/coprs/pvalena/rubygems/

> 
> ~~~
> 
> 
> I wonder where this comes from. I am participating in this thread,
> representing Ruby maintainers in RHEL and Fedora, in other places of the
> thread, I see Miro Hrončok, Tomáš Orsava and Pert Viktorin representing
> Python RHEL and Fedora maitainers, as well as Petr Písař, the RHEL and
> Fedora representative of Perl. All in all, it represents ~1/2 packages
> in Fedora/RHEL. I hope that I can say that these people shares a view
> that branch, fork, PR is the way to go.
> 
> Yet we are not able to convince you. So I wonder who this proposal
> actually represents? Who is the target audience? Who are the Red Hat
> maintainers you mentioned in the proposal?
> 
> 
> Vít
> 
> 
> 
> Dne 31. 03. 20 v 17:31 Stephen Gallagher napsal(a):
> > I sent out the V2 version of the Change on Friday and then promptly
> > managed to injure myself and be away from email until today. I've read
> > through the email threads again this morning and I decided that,
> > rather than try to address them one by one, I'd try again with a V3
> > that hopefully answers some of the repeated questions and concerns on
> > that list.
> >
> > Please see the newly-updated
> > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> > for more details[1].
> >
> >
> > [1]
> > https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose&type=revision&diff=569904&oldid=569809
___
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: Heads-up: RPM 4.16 alpha coming to rawhide

[Panu Matilainen]

On 3/31/20 8:24 PM, Gary Buhrmaster wrote:

On Tue, Mar 31, 2020 at 6:43 AM Panu Matilainen  wrote:


Based on rpm-specs-latest.tar.xz from this morning, there are thirtysome
packages relying on this behavior, which will need fixing to be
buildable with 4.16.


Is there a list of those thirty something packages
somewhere so that those particular packagers
can potentially get a heads up?


Here you go (was easier to extract from the output than I initially 
thought):


airnef.spec:83: bad %if condition:  python3 == python3
arbor.spec:34: bad %if condition:  fb5d4ea736282dce14c3284bc5db748b082db957
cgit.spec:26: bad %if condition:  0 >= 7 && ! ( x86_64 == ppc64le || 
x86_64 == x86_64 )

copr-rpmbuild.spec:47: bad %if condition:  python3 == "python2"
CQRlib.spec:33: bad %if condition:  lib64 == lib64
CTL.spec:90: bad %if condition:  lib64 == "lib64"
CVector.spec:39: bad %if condition:  lib64 == lib64
dayplanner.spec:82: bad %if condition:  include_holidayparser
desktop-backgrounds.spec:21: bad %if condition:  png != png
doxygen.spec:53: bad %if condition:  ON == "ON"
gdl.spec:193: bad %if condition:  lib64 != "lib"
ghdl.spec:494: bad %if condition:  lib64 != lib
git.spec:207: bad %if condition:  031 || 0 == 6 || ( 0 >= 7 && ( x86_64 
== ppc64le || x86_64 == x86_64 ) )

gsignond.spec:115: bad %if condition:  session != p2p
gwenview.spec:35: bad %if condition:  !(0 == 8 && ( x86_64 == "aarch64" 
|| x86_64 == "s390x" ))

hdf.spec:207: bad %if condition:  lib64 == lib64
kdegraphics-thumbnailers.spec:4: bad %if condition:  !(0 == 8 && ( 
x86_64 == "aarch64" || x86_64 == "s390x" ))
kf5-akonadi-contacts.spec:49: bad %if condition:  !(0 == 8 && ( x86_64 
== "aarch64" || x86_64 == "s390x" ))

lmdb.spec:83: bad %if condition:  0 == 6 && x86_64 == "ppc64"
magic.spec:81: bad %if condition:  x64 == x64
mariadb.spec:42: bad %if condition:  x86_64 == x86_64 && 031
MUSIC.spec:251: bad %if condition:  lib64 == "lib64"
NetworkManager.spec:24: bad %if condition:  "x" != x
newlisp.spec:38: bad %if condition:  lib64 == lib64
nwchem.spec:409: bad %if condition:  LINUX64 == LINUX
OpenEXR_Viewers.spec:82: bad %if condition:  lib64 == lib64
python-pivy.spec:66: bad %if condition:  lib64 == "lib64"
python-ryu.spec:98: bad %if condition:  python3 == python3
qt3.spec:404: bad %if condition:  lib64 == lib64
rubygem-scruffy.spec:7: bad %if condition:  (prerelease)
sagator.spec:33: bad %if condition:  redhat == "suse"
scribus.spec:111: bad %if condition:  lib64 == lib64
SkyX.spec:67: bad %if condition:  lib64 == "lib64"
zabbix.spec:61: bad %if condition:  zabbix != zabbix

- Panu -
___
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: CPE Git Forge Decision

[Bruno Wolff III]

On Wed, Apr 01, 2020 at 12:39:21 +0200,
 Florian Weimer  wrote:

* Bruno Wolff, III:


RHEL is a special case, as CENTOS provides a free drop in replacement
and switching from CENTOS to Fedora shouldn't be much work. Is there
other proprietary software at the OS level or above, that is used for
Fedora infrastructure?


The Bugzilla fork running on bugzilla.redhat.com?

 


That was an interesting read. It sounds like corners were cut under the 
assumption that there would be no desire to share the code. Specifically 
code and config were mixed together and the config can't be released.

___
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

Why is "local" insecure PATH element ?

[Lukas Czerner]

Hi,

I've noticed some failures in automated tests in bodhi, specifically
this one:

{
   "arch" : "x86_64",
   "code" : "SuspiciousPath",
   "context" : {
  "excerpt" : [
 "PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
  ],
  "path" : "/usr/sbin/e2scrub"
   },
   "diag" : "Potentially insecure PATH element /local",
   "subpackage" : "e2scrub"
},


I am not sure why it's considered insecure while on all of the Fedora
and RHEL systems I have available "/usr/local/sbin:/usr/local/bin" is a
default part of the PATH.

What am I missing ?

-Lukas
___
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: CPE Git Forge Decision

[Neal Gompa]

On Wed, Apr 1, 2020 at 6:52 AM Nicolas Mailhot via devel
 wrote:
>
> Le mercredi 01 avril 2020 à 11:30 +0100, Leigh Griffin a écrit :
> >
> > To distill it down:
> >
> > - Gitlab has more features that are needed right now for our
> > stakeholder group
> > - Gitlab has an entire company dedicated to roadmap features, we do
> > not.
>
> Unfortunately, Gitlab’s roadmap is also conflicting with Fedora
> objectives. The bread and butter of Gitlab is intermediating between
> devs and end users, culling free software intermediaries like
> distributions, and positionning itself in their stead. That is unlikely
> to result in any commitment to making distribution workflows work.
>
> That would not be a problem if the disintermediation worked, but like
> many actors Gitlab sees the $$$ and power in being the
> desintermediator, and does not care if the result is deffective, as
> long as $$$ and power flows its way.
>

It's also important to note that at the core of GitLab's incentive
model is that they want to remove incentives to use FOSS solutions in
favor of their unified proprietary solution. They are constantly
integrating features and capabilities into the proprietary parts to
make it "juicier" for enterprises who don't really have a compunction
about whether they are using Free Software solutions or not, or even
may not be willing to support them if it was Free Software because of
outmoded thinking.

The consequence of this is that it starves interest and development in
FOSS solutions, and contributes to making the FOSS ecosystem weaker
over time.

It wouldn't surprise me if not many people at Red Hat sat down and
thought seriously about that particular consequence, because it's not
exactly an obvious one.

> At heart, Fedora is a tooling project. It’s a collective of people that
> chose to use a specific integration toolchain. Anything involved in
> creating Fedora packages cuts deep into the project core. (unlike, say,
> calendaring).
>
> It’s easy to forget this when making tooling decisions,
> because it is so pervasive, most do not see it anymore. Tooling is
> anything but accessory to the project.
>

Exactly. This is a huge part of why people are so upset over this,
because if you take away our tools, you take away the reason to be
passionate about Fedora. And thus, you remove why people use and
contribute to Fedora in the first place.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

[Nicolas Mailhot via devel]

Le mercredi 01 avril 2020 à 11:30 +0100, Leigh Griffin a écrit :
> 
> To distill it down:
> 
> - Gitlab has more features that are needed right now for our
> stakeholder group
> - Gitlab has an entire company dedicated to roadmap features, we do
> not.

Unfortunately, Gitlab’s roadmap is also conflicting with Fedora
objectives. The bread and butter of Gitlab is intermediating between
devs and end users, culling free software intermediaries like
distributions, and positionning itself in their stead. That is unlikely
to result in any commitment to making distribution workflows work.

That would not be a problem if the disintermediation worked, but like
many actors Gitlab sees the $$$ and power in being the
desintermediator, and does not care if the result is deffective, as
long as $$$ and power flows its way.

At heart, Fedora is a tooling project. It’s a collective of people that
chose to use a specific integration toolchain. Anything involved in
creating Fedora packages cuts deep into the project core. (unlike, say,
calendaring).

It’s easy to forget this when making tooling decisions,
because it is so pervasive, most do not see it anymore. Tooling is
anything but accessory to the project.

Regards,

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

Re: CPE Git Forge Decision

[Leigh Griffin]

On Wed, Apr 1, 2020 at 11:33 AM Fabio Valentini 
wrote:

> On Wed, Apr 1, 2020 at 12:24 PM Leigh Griffin  wrote:
> >
> >
> >
> > On Tue, Mar 31, 2020 at 7:44 PM Chris Murphy 
> wrote:
> >>
> >> On Tue, Mar 31, 2020 at 11:45 AM Adam Williamson
> >>  wrote:
> >> >
> >> > On Tue, 2020-03-31 at 13:08 -0400, Matthew Miller wrote:
> >> > > On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote:
> >> > > > Some failure of process or communication must have occurred
> >> > > > somewhere along the lines, because open source should have been
> the
> >> > > > first and most important requirement. A proprietary software
> >> > > > solution is incompatible with the ethos and purpose of the Fedora
> >> > > > project. I ask CPE to revise its requirements list to include open
> >> > > > source as the first and most important requirement from the Fedora
> >> > > > community. If that's incompatible with CentOS's need for merge
> >> > > > request approvals or whatever else, then we need to accept that
> >> > > > sharing the same forge is simply not going to work.
> >> > >
> >> > > Obviously open source is one of our key foundations. And it is part
> of who
> >> > > we are even before those foundations were drafted. Nonetheless, I
> want to
> >> > > gently discuss this a little bit. We make an entirely open source
> and free
> >> > > software operating system. We support and promote and advocate for
> open
> >> > > source and free content. But we can't do everything, and at some
> point, this
> >> > > becomes "this is why we can't have nice things". I see that you've
> made
> >> > > contributions to other open source projects on GitHub and (hosted)
> GitLab
> >> > > this month. Lots of Fedora contributors have and will continue to
> do so.
> >> > > Many use that as their main hosting. It's not ideal, but it's not
> the end of
> >> > > the world. I don't see Fedora making use of non-open hosted
> services as the
> >> > > end of the world either, if that is what is best for us.
> >> > >
> >> > > We did communicate as the very top line of our gathered
> requirements that
> >> > > open source is essential to our community and central to our
> feedback. I'm
> >> > > not trying to be soft on that. Let's just not do purity-test level
> >> > > assessments and instead focus on our goals.
> >> >
> >> > I'm sorry, but I have to agree with Kevin and Michael here to a
> >> > significant extent. Running our own project on open source code has
> >> > always been a very big bright line for Fedora.
> >> >
> >> > I'm not necessarily saying it's a hill we should die on, but at the
> >> > very least, choosing a proprietary hosted solution for something as
> >> > fundamental as our dist-git needs to be treated as a Very Big Deal and
> >> > needs to be a decision that is handled a *lot* better than this one
> has
> >> > been handled.
> >> >
> >> > You said in another email that the tooling choice ultimately has to be
> >> > largely made by the team that is responsible for the work and it
> >> > wouldn't really work for Council to order them to do something they
> >> > can't practically do, and I see the truth in that, but at the same
> time
> >> > I think there has to be a balance there. Does this "the team decides
> >> > what works for them" principle extend as far as the team being able to
> >> > choose unilaterally to go against principles Fedora has been working
> >> > very hard to maintain for about as long as it has existed, and that
> are
> >> > listed right up there front and centre as our Foundations? That, to
> me,
> >> > seems like a decision that Council ought at the very least to be
> deeply
> >> > involved in - much more than seems to have been the case here (which
> >> > seems to have been that we wrote up some requirements and sent them
> off
> >> > to "the team", which smooshed them into some kind of summary and then
> >> > made a decision - a decision which seems to have had a rather confused
> >> > context, as various people don't seem to be on the same page about
> >> > whether a choice was supposed to be made about "dist-git", or
> >> > "pagure.io", or "Pagure", or CentOS's or Red Hat's use of Pagure, or
> >> > any or all of these things somehow smooshed together).
> >> >
> >> > I think if I turned up tomorrow and said that QA had decided we're
> >> > going to use a proprietary hosted service for managing release
> >> > validation testing there would be significant pushback against that,
> >> > and I think that pushback would be valid, and I'm not sure it would be
> >> > appropriate for us to say "tough, we made that decision so that's
> >> > what's happening". I don't think it's necessarily appropriate for that
> >> > to happen here either.
> >> >
> >> > I understand there are practical resource considerations and so on
> >> > here, but I still think this merits more high level and serious
> >> > consideration. At the very least, if we have somehow reached a point
> >> > where Red Hat is no longer willing to provid

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 01, 2020 at 12:30:13PM +0200, Miro Hrončok wrote:
> On 01. 04. 20 10:53, Zbigniew Jędrzejewski-Szmek wrote:
> >On Tue, Mar 31, 2020 at 11:31:38AM -0400, Stephen Gallagher wrote:
> >>I sent out the V2 version of the Change on Friday and then promptly
> >>managed to injure myself and be away from email until today. I've read
> >>through the email threads again this morning and I decided that,
> >>rather than try to address them one by one, I'd try again with a V3
> >>that hopefully answers some of the repeated questions and concerns on
> >>that list.
> >
> >>To enable ELN (once the repository is composed):
> >>
> >>$ dnf install fedora-repos-eln
> >>$ dnf distro-sync
> >
> >I don't see this part explained. Those additional packages will haves
> >NEVRAs always lower than rawhide packages (".eln" < ".fc33".). So this
> >distro-sync will be a noop?
> 
> A wild guess: If that repo has lower "cost", will distro-sync prefer
> packages with lower EVR because they come form that repo?

I don't think so: "cost — ... It is useful to make the library prefer
on-disk repositories to remote ones."

But there's a "priority" option: "If there is more than one candidate
package for a particular operation, the one from a repo with the
lowest priority value is picked, possibly despite being less
convenient otherwise (e.g. by being a lower version)."

This should do the trick. The mechanism should be described in the
Change page too.

(Note: I had a sense of deja-vu, because 'priority' was already
discussed in the context of this Change, but it was koji priority for
scheduling tasks, not package installation.)

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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

[Neal Gompa]

On Wed, Apr 1, 2020 at 6:31 AM Miro Hrončok  wrote:
>
> On 01. 04. 20 10:53, Zbigniew Jędrzejewski-Szmek wrote:
> > On Tue, Mar 31, 2020 at 11:31:38AM -0400, Stephen Gallagher wrote:
> >> I sent out the V2 version of the Change on Friday and then promptly
> >> managed to injure myself and be away from email until today. I've read
> >> through the email threads again this morning and I decided that,
> >> rather than try to address them one by one, I'd try again with a V3
> >> that hopefully answers some of the repeated questions and concerns on
> >> that list.
> >
> >> To enable ELN (once the repository is composed):
> >>
> >> $ dnf install fedora-repos-eln
> >> $ dnf distro-sync
> >
> > I don't see this part explained. Those additional packages will haves
> > NEVRAs always lower than rawhide packages (".eln" < ".fc33".). So this
> > distro-sync will be a noop?
>
> A wild guess: If that repo has lower "cost", will distro-sync prefer packages
> with lower EVR because they come form that repo?
>

I think if the repo has a higher priority or lower cost, it might
work? I'm not sure...


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

[Florian Weimer]

* Bruno Wolff, III:

> RHEL is a special case, as CENTOS provides a free drop in replacement
> and switching from CENTOS to Fedora shouldn't be much work. Is there
> other proprietary software at the OS level or above, that is used for
> Fedora infrastructure?

The Bugzilla fork running on bugzilla.redhat.com?

  

Thanks,
Florian
___
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: CPE Git Forge Decision

[Miro Hrončok]

On 01. 04. 20 10:53, Vít Ondruch wrote:


Dne 01. 04. 20 v 10:37 Michal Konecny napsal(a):



On 31/03/2020 20:53, Kevin Fenzi wrote:

On Tue, Mar 31, 2020 at 12:40:55PM -0500, Bruno Wolff III wrote:
...snip...

Because of switching costs, this is likely to prevent us from going back to
Pagure if it does develop a vibrant independent community. That would be
unfortunate.

So, currently we are using pagure on src.fedoraproject.org, but it's not
just pagure, it's a integration layer over the top of pagure too.

I'd like to see if we can, as part of this: a) adjust our packaging
workflow (as many threads on this list have talked about) and b) after
that, try and reduce that integration layer as much as we can and c)
hopefully make it so we could move the backend git repos / forge later
if we wanted to without recreating a big integration layer.
To be clear, you mean something like app above the dist-git where you could do 
most of the things that are needed for dist-git with git forge only being a 
package source with various branches?


Something like web UI that allows you to do retirement, change notification 
settings, has links to various other systems, with on of them the git that is 
hosting the code for package, without actually thinking what git forge is used 
for the hosting?



Do you mean https://github.com/fedora-infra/pkgdb2/ ? :)


That's actually what rpmfusion is doing. They have pkgdb + github repos.

(Not sure if still, but it was the case around a year ago.)


--
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: CPE Git Forge Decision

[Fabio Valentini]

On Wed, Apr 1, 2020 at 12:24 PM Leigh Griffin  wrote:
>
>
>
> On Tue, Mar 31, 2020 at 7:44 PM Chris Murphy  wrote:
>>
>> On Tue, Mar 31, 2020 at 11:45 AM Adam Williamson
>>  wrote:
>> >
>> > On Tue, 2020-03-31 at 13:08 -0400, Matthew Miller wrote:
>> > > On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote:
>> > > > Some failure of process or communication must have occurred
>> > > > somewhere along the lines, because open source should have been the
>> > > > first and most important requirement. A proprietary software
>> > > > solution is incompatible with the ethos and purpose of the Fedora
>> > > > project. I ask CPE to revise its requirements list to include open
>> > > > source as the first and most important requirement from the Fedora
>> > > > community. If that's incompatible with CentOS's need for merge
>> > > > request approvals or whatever else, then we need to accept that
>> > > > sharing the same forge is simply not going to work.
>> > >
>> > > Obviously open source is one of our key foundations. And it is part of 
>> > > who
>> > > we are even before those foundations were drafted. Nonetheless, I want to
>> > > gently discuss this a little bit. We make an entirely open source and 
>> > > free
>> > > software operating system. We support and promote and advocate for open
>> > > source and free content. But we can't do everything, and at some point, 
>> > > this
>> > > becomes "this is why we can't have nice things". I see that you've made
>> > > contributions to other open source projects on GitHub and (hosted) GitLab
>> > > this month. Lots of Fedora contributors have and will continue to do so.
>> > > Many use that as their main hosting. It's not ideal, but it's not the 
>> > > end of
>> > > the world. I don't see Fedora making use of non-open hosted services as 
>> > > the
>> > > end of the world either, if that is what is best for us.
>> > >
>> > > We did communicate as the very top line of our gathered requirements that
>> > > open source is essential to our community and central to our feedback. 
>> > > I'm
>> > > not trying to be soft on that. Let's just not do purity-test level
>> > > assessments and instead focus on our goals.
>> >
>> > I'm sorry, but I have to agree with Kevin and Michael here to a
>> > significant extent. Running our own project on open source code has
>> > always been a very big bright line for Fedora.
>> >
>> > I'm not necessarily saying it's a hill we should die on, but at the
>> > very least, choosing a proprietary hosted solution for something as
>> > fundamental as our dist-git needs to be treated as a Very Big Deal and
>> > needs to be a decision that is handled a *lot* better than this one has
>> > been handled.
>> >
>> > You said in another email that the tooling choice ultimately has to be
>> > largely made by the team that is responsible for the work and it
>> > wouldn't really work for Council to order them to do something they
>> > can't practically do, and I see the truth in that, but at the same time
>> > I think there has to be a balance there. Does this "the team decides
>> > what works for them" principle extend as far as the team being able to
>> > choose unilaterally to go against principles Fedora has been working
>> > very hard to maintain for about as long as it has existed, and that are
>> > listed right up there front and centre as our Foundations? That, to me,
>> > seems like a decision that Council ought at the very least to be deeply
>> > involved in - much more than seems to have been the case here (which
>> > seems to have been that we wrote up some requirements and sent them off
>> > to "the team", which smooshed them into some kind of summary and then
>> > made a decision - a decision which seems to have had a rather confused
>> > context, as various people don't seem to be on the same page about
>> > whether a choice was supposed to be made about "dist-git", or
>> > "pagure.io", or "Pagure", or CentOS's or Red Hat's use of Pagure, or
>> > any or all of these things somehow smooshed together).
>> >
>> > I think if I turned up tomorrow and said that QA had decided we're
>> > going to use a proprietary hosted service for managing release
>> > validation testing there would be significant pushback against that,
>> > and I think that pushback would be valid, and I'm not sure it would be
>> > appropriate for us to say "tough, we made that decision so that's
>> > what's happening". I don't think it's necessarily appropriate for that
>> > to happen here either.
>> >
>> > I understand there are practical resource considerations and so on
>> > here, but I still think this merits more high level and serious
>> > consideration. At the very least, if we have somehow reached a point
>> > where Red Hat is no longer willing to provide sufficient resources to
>> > run Fedora on the lines the Fedora community wants it to be run, we
>> > need to recognize that this is a significant problem that needs to be
>> > properly aired and discussed

Re: CPE Git Forge Decision

[Leigh Griffin]

On Tue, Mar 31, 2020 at 8:02 PM Chris Murphy 
wrote:

> On Tue, Mar 31, 2020 at 2:37 AM Leigh Griffin  wrote:
> >
> >
> >
> > On Mon, Mar 30, 2020 at 10:38 PM Chris Murphy 
> wrote:
> >>
> >> On Mon, Mar 30, 2020 at 5:56 AM Leigh Griffin 
> wrote:
> >> >
> >> > We haven't ironed out the full details but what was incredibly clear
> to us was that Gitlab was the decision to make. The next step in getting
> there is what we are engaging in now to get thoughts and suggestions and
> expect several threads in that capacity from a technical perspective in the
> coming weeks and months.
> >>
> >>
> >> It is not incredibly clear to the respondents on devel@. I don't care
> >> to imagine what stronger disagreement on this particular point looks
> >> like.
> >
> >
> > I respect that there is disagreement but Gitlab is the choice we are
> making.
>
>
> Why this choice?


To distill it down:

- Gitlab has more features that are needed right now for our stakeholder
group
- Gitlab has an entire company dedicated to roadmap features, we do not.
- Gitlab has better resiliency and uptime, we offer an SLE on an app that
is not meeting our mission statement but is consuming a lot of our time
- Gitlab scales better, Pagure has scale issues
- CPE do not own an application that will consume 100% of our available
team capacity from here on in to bridge the gap, to keep the system stood
up, to move towards an SLA model and to keep apace with new innovations


> That's what's not clear. And it's not fair to call
> this mere disagreement, because the decision can't even be properly
> absorbed. It is prima facie not an open or transparent process, yet is
> being claimed to have been. That contradiction is not trust enhancing.
>
>
>
> >>
> >> On Mon, Mar 30, 2020 at 4:27 AM Iñaki Ucar 
> wrote:
> >> >
> >> > I was referring to, and I was expecting, an open conversation about
> >> > the User Story list, an open analysis of the requirements list. In
> >> > other words:
> >> >
> >> > 1. Open conversation to gather requirements. Done.
> >> > 2. Publication of User Story list.
> >> > 3. Open conversation to discuss (2).
> >> > 4. Publication of the final decision.
> >> >
> >> > I was expecting (3), and it's missing.
> >>
> >>
> >> I concur, and don't think the missing piece has been adequately
> >> addressed. There's a reason why there's bewilderment at the decision,
> >> it's not ignorable.
> >
> >
> > How would you like us to address it more clearly? Fedora has had the
> publication of its User Story list, a threads worth of discussion on it
> occured and it was submitted. As have other stakeholder groups. I think the
> crux here is that we didn't publish the entire stakeholder User Stories for
> dissemination to each individual stakeholder group. With each group valuing
> something different, as is obvious from the discussion around individual
> requirements that has occured in several threads here, we didn't feel the
> value would have been there. That's on me for not looping the comms back in
> and I apologise for that.
> >
> >>
> >> Were there deliberations by CPE Team in between (2) and (4)?
> >
> > Yes, several hundred person hours worth of analysis, meetings and
> dissecting the requirements.
>
> It would be addressed more clearly by seeing the summary,
> distillation, metric, method, by which those hundreds of hours were
> turned into the decision.
>

I have promised  several times that the feature gaps will land as a backlog
addition for Pagure and I can happily share out a matrix from a User Story
/ Feature perspective and additional comments. Stay tuned for that.

>
> These entire threads are a verbose way of saying "show your work."
>
> >
> >>
> >> Is there
> >> a record of those deliberations?
> >
> >
> > No, they were mostly video calls / in person meetings and the result is
> the User Story list and decision document for sharing.
>
> I think a summary of the first hour of these several hundred hours,
> and the last hour, would be useful. There's no way to reconstruct
> this?


I mean if you want the summary of the first hour it was a strategy plan for
grouping the requirements and interviewing stakeholders / communicating
with our team on technical details. The last hour was the summary mail that
was sent out to communicate the decision.


> Deliberative bodies should be keeping notes, summary of major
> decisions, pros, cons, liabilities, prioritization of conflicting
> requirements, what things are in and out of scope, etc. There must be
> something to show.
>

We have multiple documents with requirements, notes, matrixes, meeting
minutes which I'm happy to distill down and share out as indicated above.

>
>
> --
> Chris Murphy
> ___
> 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://fedorap

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

[Miro Hrončok]

On 01. 04. 20 10:53, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Mar 31, 2020 at 11:31:38AM -0400, Stephen Gallagher wrote:

I sent out the V2 version of the Change on Friday and then promptly
managed to injure myself and be away from email until today. I've read
through the email threads again this morning and I decided that,
rather than try to address them one by one, I'd try again with a V3
that hopefully answers some of the repeated questions and concerns on
that list.



To enable ELN (once the repository is composed):

$ dnf install fedora-repos-eln
$ dnf distro-sync


I don't see this part explained. Those additional packages will haves
NEVRAs always lower than rawhide packages (".eln" < ".fc33".). So this
distro-sync will be a noop?


A wild guess: If that repo has lower "cost", will distro-sync prefer packages 
with lower EVR because they come form that repo?


--
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: CPE Git Forge Decision

[Leigh Griffin]

On Tue, Mar 31, 2020 at 7:44 PM Chris Murphy 
wrote:

> On Tue, Mar 31, 2020 at 11:45 AM Adam Williamson
>  wrote:
> >
> > On Tue, 2020-03-31 at 13:08 -0400, Matthew Miller wrote:
> > > On Tue, Mar 31, 2020 at 10:48:55AM -0500, Michael Catanzaro wrote:
> > > > Some failure of process or communication must have occurred
> > > > somewhere along the lines, because open source should have been the
> > > > first and most important requirement. A proprietary software
> > > > solution is incompatible with the ethos and purpose of the Fedora
> > > > project. I ask CPE to revise its requirements list to include open
> > > > source as the first and most important requirement from the Fedora
> > > > community. If that's incompatible with CentOS's need for merge
> > > > request approvals or whatever else, then we need to accept that
> > > > sharing the same forge is simply not going to work.
> > >
> > > Obviously open source is one of our key foundations. And it is part of
> who
> > > we are even before those foundations were drafted. Nonetheless, I want
> to
> > > gently discuss this a little bit. We make an entirely open source and
> free
> > > software operating system. We support and promote and advocate for open
> > > source and free content. But we can't do everything, and at some
> point, this
> > > becomes "this is why we can't have nice things". I see that you've made
> > > contributions to other open source projects on GitHub and (hosted)
> GitLab
> > > this month. Lots of Fedora contributors have and will continue to do
> so.
> > > Many use that as their main hosting. It's not ideal, but it's not the
> end of
> > > the world. I don't see Fedora making use of non-open hosted services
> as the
> > > end of the world either, if that is what is best for us.
> > >
> > > We did communicate as the very top line of our gathered requirements
> that
> > > open source is essential to our community and central to our feedback.
> I'm
> > > not trying to be soft on that. Let's just not do purity-test level
> > > assessments and instead focus on our goals.
> >
> > I'm sorry, but I have to agree with Kevin and Michael here to a
> > significant extent. Running our own project on open source code has
> > always been a very big bright line for Fedora.
> >
> > I'm not necessarily saying it's a hill we should die on, but at the
> > very least, choosing a proprietary hosted solution for something as
> > fundamental as our dist-git needs to be treated as a Very Big Deal and
> > needs to be a decision that is handled a *lot* better than this one has
> > been handled.
> >
> > You said in another email that the tooling choice ultimately has to be
> > largely made by the team that is responsible for the work and it
> > wouldn't really work for Council to order them to do something they
> > can't practically do, and I see the truth in that, but at the same time
> > I think there has to be a balance there. Does this "the team decides
> > what works for them" principle extend as far as the team being able to
> > choose unilaterally to go against principles Fedora has been working
> > very hard to maintain for about as long as it has existed, and that are
> > listed right up there front and centre as our Foundations? That, to me,
> > seems like a decision that Council ought at the very least to be deeply
> > involved in - much more than seems to have been the case here (which
> > seems to have been that we wrote up some requirements and sent them off
> > to "the team", which smooshed them into some kind of summary and then
> > made a decision - a decision which seems to have had a rather confused
> > context, as various people don't seem to be on the same page about
> > whether a choice was supposed to be made about "dist-git", or
> > "pagure.io", or "Pagure", or CentOS's or Red Hat's use of Pagure, or
> > any or all of these things somehow smooshed together).
> >
> > I think if I turned up tomorrow and said that QA had decided we're
> > going to use a proprietary hosted service for managing release
> > validation testing there would be significant pushback against that,
> > and I think that pushback would be valid, and I'm not sure it would be
> > appropriate for us to say "tough, we made that decision so that's
> > what's happening". I don't think it's necessarily appropriate for that
> > to happen here either.
> >
> > I understand there are practical resource considerations and so on
> > here, but I still think this merits more high level and serious
> > consideration. At the very least, if we have somehow reached a point
> > where Red Hat is no longer willing to provide sufficient resources to
> > run Fedora on the lines the Fedora community wants it to be run, we
> > need to recognize that this is a significant problem that needs to be
> > properly aired and discussed and resolved. In this context I'll note
> > that the apparent significant headcount reduction of RH people working
> > on Fedora infrastructure over the last few years

Re: CPE Git Forge Decision

[Panu Matilainen]

On 4/1/20 12:49 PM, Clement Verna wrote:



On Wed, 1 Apr 2020 at 09:47, Panu Matilainen > wrote:


On 3/31/20 8:44 PM, Adam Williamson wrote:

 > I understand there are practical resource considerations and so on
 > here, but I still think this merits more high level and serious
 > consideration. At the very least, if we have somehow reached a point
 > where Red Hat is no longer willing to provide sufficient resources to
 > run Fedora on the lines the Fedora community wants it to be run, we
 > need to recognize that this is a significant problem that needs to be
 > properly aired and discussed and resolved. In this context I'll note
 > that the apparent significant headcount reduction of RH people
working
 > on Fedora infrastructure over the last few years is in itself a
 > worrying trend, particularly if you consider it while reading
Clement's
 > email.

This.


I don't think this is correct, at least not in CPE, the team has grown 
over the past year and every person leaving the team has been replaced 
(even by 2 persons in some cases). The problem in my opinion is that a 
lot of the people that have setup and written the original services and 
applications are gone, taking with them most of the knowledge about How, 
What and Why something was done this way. That leaves people in the team 
now with a big amount of legacy applications to take care of and not 
much clue of what is going on.
There is also an historical taste to write in house applications for 
things that don't really seems critical to the Fedora Project, for 
example do we really need a custom calendar application ? or election 
application ? It seems that every time we have a problem the solution is 
let's write something to solve that problem, instead of trying to find a 
compromise and reuse existing solutions.


Now when the CPE team goes and ask for more people because we struggle 
with current situation, I can only guess that these non critical 
applications are mentioned. If I was putting my own money to sponsor a 
team to help building a Linux distribution I would be asking why do we 
have to develop a calendar application or why do we need a custom git 
forge. I personally find really great that the different use cases and 
requirements for the use of Pagure were gathered and I am convinced that 
people working on this did their very best to find a use case to justify 
the investment needed in Pagure but it seems that we don't have such a 
thing.


Heh, I didn't even know about these calendar and election applications.
Of course, if you're running thin (on resources, whether human or 
otherwise) you start with cutting the excess of course. That is obvious.




I also appreciate that as a community developing our own solutions is 
something important and something that seems to matter a lot, but we 
have to realize that the development and maintenance effort cannot be 
carried out by the CPE team any more. Maybe this is a opportunity to 
create a SIG or a working group for people that are interested to carry 
on this effort.


But this is precisely at the heart of the problem: people feel they were 
not given an opportunity to lend a hand, and that now its too late 
because the messaging is that we go with GitLab, no matter what.




Finally, I would like to make clear that I am not blaming anyone, and 
that decisions made in the past, I am sure were taken with the best 
intentions. But I think it is also important to recognize that it is 
legitimate to question these decisions today as something that made 
sense 10 years ago or 5 years ago might not make sense in today's context.


Yes, world changes and past decisions need to be reviewed every now and 
then. However I believe with any changes it's paramount to understand 
and keep in mind the reasons behind the original decisions when 
re-evaluating.


I don't claim to have read anywhere near everything that's written on 
this topic, but at least in the blog entry I fail to see any mention of 
the original reasons to go with Pagure. I frankly didn't understand it 
back then (but didn't care too much), it's just that I find the lack of 
reference a bit alarming.


- Panu -
___
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: CPE Git Forge Decision

[Leigh Griffin]

On Tue, Mar 31, 2020 at 6:32 PM Adam Williamson 
wrote:

> On Tue, 2020-03-31 at 17:47 +0200, jkone...@redhat.com wrote:
> > -- snip --
> > > As for Pagure itself, I think this is where we fundamentally
> > > disagree.
> > > I think it behooves us to own and provide an experience tailored for
> > > our community from beginning to end. That's why we have Koji, Bodhi,
> > > Dist-Git, and many other tools in that part of the lifecycle. The
> > > packager experience is literally the lifeblood of the project, and
> > > our
> > > contributors are the core of what makes Fedora successful. Pagure
> > > gives us an opportunity to do right by them that I *really* don't
> > > think we can do with any alternatives.
> > >
> > > That does *not* mean that CPE team should be the sole owner of the
> > > Pagure *codebase*. On that point, I agree. And that's why I've spent
> > > a
> > > lot of time and energy since late 2018 working on building up that
> > > community. It's finally starting to bear fruit too: there's at least
> > > one entity interested in building a product around it and
> > > contributing
> > > to help support that product, there's the FSF preparing to launch a
> > > new forge using Pagure, there's the Trisquel GNU+Linux distribution
> > > working on a Pagure deployment to host their code and packaging, and
> > > there's a few other things I've got up my sleeve to help broaden the
> > > community with not just users, but also contributors.
> >
> > It's great to hear this. Thanks a lot Neal for trying to find
> > consumers. I'm not sure if this information was available to Fedora
> > infrastructure during the decision. It means that we may have another
> > contributors.
>
> I specifically mentioned at least the FSF angle on this mailing list,
> over a month ago:
>
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EJAKU3MO4T5ZEWEBUWIRSGBWTFQU44QK/
>
> so at least that part certainly *should* have been, if we assume it's
> reasonable to expect those making this decision to be paying attention
> to this list.
>

We were aware and we do follow this list.

> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


___
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