Self Introduction: Dan Shoemaker
Hi, my name is Dan Shoemaker. I have been using Fedora since Fedora Core 6 for both personal and professional use. About five years ago I started developing bash scripts in order to start automating tasks I was doing while maintaining Linux servers for various clients. Last year I started taking Todd McLeod's Udemy class Learning Go and I found much to my delight that Fedora has a very active Go SIG. As a result I would love to become a package maintainer for the Go packages on Fedora. Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file
Le mercredi 26 février 2020 à 23:07 -0500, Neal Gompa a écrit :
>
> You don't use Release for upstream versioning, even for snapshots.
> For
> your examples:
>
> * 0-0.1.beta.2 -> 0~beta.2-1
> * 0-0.1.20120225gitd6c789a -> 0~git20120225.d6c789a-
Sorry but no
You are attempting to redefine the meaning of Version (*upstream*
version) to accomodate your release simplification plans
As I wrote the list months ago the upstream Version (Version,
%{version}) is zero 0 nil not 0~git20120225.d6c789a-1
The git20120225.d6c789a is a Fedora downstream construct
You can not break the data model with automation the way you break it
for humans. Automation does not care about your feelings. Automation
input is O as upstream Version. It can add downstream constructs to
Release, it can not rewrite Version (bad bad idea to attempt rewriting
a core rpm Tag in macros anyway)
--
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: Ideas and proposal for removing changelog and release fields from spec file
Hi list, Stephen John Smoogen writes: > On Mon, 24 Feb 2020 at 11:50, Pierre-Yves Chibon > wrote: > >> Good Morning Everyone, >> >> This topic has already been discussed a few times over the past month, but >> Adam >> Saleh, Nils Philippsen and myself have had the opportunity to invest some >> time >> on it with the hope of making the packager's life simpler as well as >> making it >> easier to build automation around our package maintenance. >> > > > Going through the various discussions, I think we are running into a > classic sausage factory problem.. everyone wants to have their favourite > meat, but the only way to make it work is mix them all together, grind it > up and come up with something else. I have to agree with Stephen here. As someone who has been heavily involved in building packages on OBS, where the Release field is generated automatically by the build server: I don't see a problem in automatically generating the release field, I would actually very much welcome it. But then none of my packages fall into the "Beaufort D'Ete" category, so I might be missing something here. For the changelog: yes please, generate it from the commit log! They are more or less the same for all my packages and I'm getting tired of copy pasting the same text into %changelog and git commit. 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
Fedora-Cloud-30-20200227.0 compose check report
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
CMake automatic dependencies generation changes
For a while now we have generated rpm cmake provides automatically for packages that install cmake "packages". The was done in a case-sensitive manner using the name of the cmake files installed. However, cmake looks for packages in a case-insensitive manner so distributions that have also enabled automatic generation of rpm requires ran into issues where the provides were one case and the requires another. I have just built cmake-3.17.0-0.2.fc33 with a change from OpenMandriva that now produces both the old provides as well as a lower case version to allow for a gradual transition. It also switches the generators to use python 3. It may also be time to think about enabling automatic requires generation as well. However, I don't have the time to drive this process. - Orion -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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
[389-devel] 389 DS nightly 2020-02-27 - 97% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/02/27/report-389-ds-base-1.4.3.3-20200227gitea4fa54.fc31.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: Ideas and proposal for removing changelog and release fields from spec file
On Wed, Feb 26, 2020 at 8:05 PM Robert-André Mauchin wrote:
>
> On Monday, 24 February 2020 17:48:36 CET Pierre-Yves Chibon wrote:
> > However, for the release field, we are struggling a little bit more, two
> > options are more appealing to us:
> >
> > A) The release field is automatically generated using two elements:
> > - the number of commits at this version
> > - the number of builds at this commit
> > - the dist-tag being added after them
> > The release field would thus look like:
> > ``.%{dist}``
> >
> > So we could have: (A, B, C and D being different commits)
> > A -- version: 0.9 -- release: ?
> >
> > |
> >
> > B -- version: 1.0 -- release: 1.0
> >
> > |
> >
> > C -- version: 1.0 -- release: 2.0
> >
> > |
> >
> > D -- version: 1.1 -- release: 1.0
> >
> > A rebuild of the commit D, would lead to a release 1.1 (assuming the first
> > one succeeded)/
> >
> > Pros:
> > - Easy to replicate locally
> > - Every changelog entry can be mapped to a `version-release` (No changes to
> > the packaging guidelines)
> > - Allows triggering two builds from the same commit without any manual
> > change (simplifies mass-rebuilds)
> > - Easy to link a certain build with a specific commit
> > - Easy to “guess” the next release value before triggering the build
> >
> > Cons:
> > - Old packages which are no longer receiving upstream releases may need
> > special care (for example if they are at the release -48 but only had
> > 45 commits leading to this)
> > - Relies on information from the build system for the build number (but
> > can be closely simulated locally since the info is only used for
> > rebuilds)
> > - Upgrade path may be problematic if Fn is upgraded to version X with
> > one commit while Fn-1 is upgrade to version X with 2 commits (or more)
> >
> > B) The release field is automatically generated taking existing builds in
> > all current Fedora releases (ie: rawhide, Fn, Fn-1...) into account. This
> > means for builds of the same epoch:version, find a new release that (if at
> > all possible) ensures upgradability from older Fedora versions to newer
> > ones, adhering to the structure of a release tag documented in the
> > Versioning Guidelines[1]. Going from the (RPM-wise) "latest build" that the
> > new one should surpass, this can mean bumping in the front (`pkgrel`) or
> > the back (`minorbump`).
> >
> > This allows packages from "very stable" upstreams who haven't released in
> > years to still benefit from automatically generated releases.
> >
> > The following examples would use a macro for the release field as outlined
> > in a separate document[2].
> >
> > Example #1 ("normal" release progression):
> > Rawhide has: 2.0-1.fc32
> > F31 has: 1.0-1.fc31
> > F30 has: 1.0-1.fc30
> >
> > Next release in F31: 1.0-2.fc32
> >
> >
> > Example #2 ("hotfix" in an older release, selected by an alternative macro
> > (or option) in the spec file):
> > Rawhide has: 2.0-1.fc32
> > F31 has: 1.0-1.fc31
> > F30 has: 1.0-1.fc30
> >
> > Next release in F30: 1.0-1.fc30.1
> >
> > Example #3 (pre-release, selected by an alternative macro (or option) in
> > the spec file):
> > Rawhide has: 2.0-1.fc32
> > F31 has: 1.0-1.fc31
> > F30 has: 1.0-1.fc30
> >
> > Next release in Rawhide: 3.0-0.1.20200224git1234abcd
> >
> >
> > Pros:
> > - Allows triggering two builds from the same commit without manual
> > intervention
> > - Emulates what many maintainers do manually today for most use cases
> > - Can cater for pre-releases (e.g.: by offering different macros or macro
> > options for the different use cases)
> >
> > Cons:
> > - Needs the build system for information about builds in this and other
> > Fedora versions
> > - Not easy to reproduce locally because we don’t have machine-consumable
> > knowledge about other builds in e.g. the dist-git repo
> > - Does not allow to generate changelog entries with `version-release`
> > information for all commits (and this will require a change in our
> > packaging guidelines)
> >
> >
> > So these are the results of our current investigations, we are very much
> > eager to get your feedback on them and even more eager if you have ideas
> > on how to approach/solve some of the challenges mentioned here.
> >
> >
> > Looking forward for the discussion,
> >
> > Pierre
> > For Adam, Nils and myself
> >
> >
> >
>
> How would that work with "complex" releases? For example release containing
> prerelease info like 0.1.beta.2 or 0.1.20120225gitd6c789a? Many Go package
> have no version, so depend heavily on the Release tag to signal what is the
> snapshot date and git commit packaged.
>
You don't use Release for upstream versioning, even for snapshots. For
your examples:
* 0-0.1.beta.2 -> 0~beta.2-1
* 0-0.1.20120225gitd6c789a -> 0~git20120225.d6c789a-1
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
Re: Ideas and proposal for removing changelog and release fields from spec file
On Monday, 24 February 2020 17:48:36 CET Pierre-Yves Chibon wrote:
> However, for the release field, we are struggling a little bit more, two
> options are more appealing to us:
>
> A) The release field is automatically generated using two elements:
> - the number of commits at this version
> - the number of builds at this commit
> - the dist-tag being added after them
> The release field would thus look like:
> ``.%{dist}``
>
> So we could have: (A, B, C and D being different commits)
> A -- version: 0.9 -- release: ?
>
> |
>
> B -- version: 1.0 -- release: 1.0
>
> |
>
> C -- version: 1.0 -- release: 2.0
>
> |
>
> D -- version: 1.1 -- release: 1.0
>
> A rebuild of the commit D, would lead to a release 1.1 (assuming the first
> one succeeded)/
>
> Pros:
> - Easy to replicate locally
> - Every changelog entry can be mapped to a `version-release` (No changes to
> the packaging guidelines)
> - Allows triggering two builds from the same commit without any manual
> change (simplifies mass-rebuilds)
> - Easy to link a certain build with a specific commit
> - Easy to “guess” the next release value before triggering the build
>
> Cons:
> - Old packages which are no longer receiving upstream releases may need
> special care (for example if they are at the release -48 but only had
> 45 commits leading to this)
> - Relies on information from the build system for the build number (but
> can be closely simulated locally since the info is only used for
> rebuilds)
> - Upgrade path may be problematic if Fn is upgraded to version X with
> one commit while Fn-1 is upgrade to version X with 2 commits (or more)
>
> B) The release field is automatically generated taking existing builds in
> all current Fedora releases (ie: rawhide, Fn, Fn-1...) into account. This
> means for builds of the same epoch:version, find a new release that (if at
> all possible) ensures upgradability from older Fedora versions to newer
> ones, adhering to the structure of a release tag documented in the
> Versioning Guidelines[1]. Going from the (RPM-wise) "latest build" that the
> new one should surpass, this can mean bumping in the front (`pkgrel`) or
> the back (`minorbump`).
>
> This allows packages from "very stable" upstreams who haven't released in
> years to still benefit from automatically generated releases.
>
> The following examples would use a macro for the release field as outlined
> in a separate document[2].
>
> Example #1 ("normal" release progression):
> Rawhide has: 2.0-1.fc32
> F31 has: 1.0-1.fc31
> F30 has: 1.0-1.fc30
>
> Next release in F31: 1.0-2.fc32
>
>
> Example #2 ("hotfix" in an older release, selected by an alternative macro
> (or option) in the spec file):
> Rawhide has: 2.0-1.fc32
> F31 has: 1.0-1.fc31
> F30 has: 1.0-1.fc30
>
> Next release in F30: 1.0-1.fc30.1
>
> Example #3 (pre-release, selected by an alternative macro (or option) in
> the spec file):
> Rawhide has: 2.0-1.fc32
> F31 has: 1.0-1.fc31
> F30 has: 1.0-1.fc30
>
> Next release in Rawhide: 3.0-0.1.20200224git1234abcd
>
>
> Pros:
> - Allows triggering two builds from the same commit without manual
> intervention
> - Emulates what many maintainers do manually today for most use cases
> - Can cater for pre-releases (e.g.: by offering different macros or macro
> options for the different use cases)
>
> Cons:
> - Needs the build system for information about builds in this and other
> Fedora versions
> - Not easy to reproduce locally because we don’t have machine-consumable
> knowledge about other builds in e.g. the dist-git repo
> - Does not allow to generate changelog entries with `version-release`
> information for all commits (and this will require a change in our
> packaging guidelines)
>
>
> So these are the results of our current investigations, we are very much
> eager to get your feedback on them and even more eager if you have ideas
> on how to approach/solve some of the challenges mentioned here.
>
>
> Looking forward for the discussion,
>
> Pierre
> For Adam, Nils and myself
>
>
>
How would that work with "complex" releases? For example release containing
prerelease info like 0.1.beta.2 or 0.1.20120225gitd6c789a? Many Go package
have no version, so depend heavily on the Release tag to signal what is the
snapshot date and git commit packaged.
Best regards,
Robert-André
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-dd6b868b6d pam_radius-1.4.0-4.el6 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-91512b5eee proftpd-1.3.3g-14.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing php-phpseclib-2.0.24-1.el6 Details about builds: php-phpseclib-2.0.24-1.el6 (FEDORA-EPEL-2020-7434b3c398) PHP Secure Communications Library Update Information: **Version 2.0.24** - 2020-02-22 - X509: fix PHP 5.3 compatability issue - SSH2: arcfour128 / arcfour256 were being included twice - SSH2: make window resizing behave more consistently with PuTTY (#1421) - SSH2: sodium_compat doesn't support memzero (#1432) - SSH2: logging enhancements - SFTP: don't buffer up download requests (PuTTY doesn't) (#1425) - RSA: make PSS verification work for key length that aren't a power of 2 (#1423) ChangeLog: * Mon Feb 24 2020 Remi Collet - 2.0.24-1 - update to 2.0.24 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 561 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 302 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 300 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fb7ac4aee2 hiredis-0.12.1-2.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-99abadf4df python-psutil-5.6.7-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b1046cc65d python-colander-1.7.0-1.el7 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5f252e8e10 kea-1.6.0-4.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ea579d7782 proftpd-1.3.5e-9.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing mirrormanager2-0.12-1.el7 php-phpseclib-2.0.24-1.el7 Details about builds: mirrormanager2-0.12-1.el7 (FEDORA-EPEL-2020-a89b9182d1) Mirror management application Update Information: Update to 0.12 ChangeLog: * Mon Feb 24 2020 Adrian Reber - 0.12-1 - Handle modular in EPEL - Disable report_mirror for public mirrors https://github.com/fedora-infra/mirrormanager2/pull/281 - Fix typo in propagation URL https://github.com/fedora-infra/mirrormanager2/pull/280 - Fix WTForms deprecation warnings https://github.com/fedora-infra/mirrormanager2/pull/279 - umdl: skip certain paths for version detection https://github.com/fedora-infra/mirrormanager2/pull/278 - Disallow users accessing other hosts and sites https://github.com/fedora-infra/mirrormanager2/pull/277 - Remove jquery which was brought in for fedmenu https://github.com/fedora-infra/mirrormanager2/pull/274 - Only query database once for mirrorlist export https://github.com/fedora-infra/mirrormanager2/pull/273 * Wed Jan 29 2020 Fedora Release Engineering - 0.11-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild php-phpseclib-2.0.24-1.el7 (FEDORA-EPEL-2020-5b0cef2f64) PHP Secure Communications Library Update Information: **Version 2.0.24** - 2020-02-22 - X509: fix PHP 5.3 compatability issue - SSH2: arcfour128 / arcfour256 were being included twice - SSH2: make window resizing behave more consistently with PuTTY (#1421) - SSH2: sodium_compat doesn't support memzero (#1432) - SSH2: logging enhancements - SFTP: don't buffer up download requests (PuTTY doesn't) (#1425) - RSA: make PSS verification work for key length that aren't a power of 2 (#1423) ChangeLog: * Mon Feb 24 2020 Remi Collet - 2.0.24-1 - update to 2.0.24 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: State of FMN (FedMSG Notifications) and Replacement
On Wed, 26 Feb 2020 at 15:58, Kevin Fenzi wrote: > On Wed, Feb 26, 2020 at 08:26:09AM +0100, Clement Verna wrote: > > Hi all, > > > > FMN (https://apps.fedoraproject.org/notifications) is currently one of > the > > main blocking point for dropping fedmsg in favour of fedora-messaging. > > FMN is quite important to the community and the composition of Fedora > > because it gives emails and notifications on commits, composes, builds > and > > updates via email and other tools. > > > > However, the code base is written in Python 2.7 and not maintained > anymore. > > Currently the service has to run on a Fedora 28 system to continue > running. > > This causes multiple problems and concerns, and needs to be addressed > > before the datacenter move in June. > > > > In order to start putting together a specification for a replacement, we > > should try to look at the minimum requirements for a notification system. > > For example the current system supports sending notifications to IRC, > > emails and SSE (Server Sent Event), Can we live without SSE ? Can we live > > without IRC ? Do we need it to monitor everything it does currently or > just > > a subset of items that the community has found useful. > > > > Let's use this thread to brainstorm ideas on what we need. > > First I can add a bit of history/background for everyone here: > > Long ago every app in fedora infrastructure (koji, bodhi, etc) > implemented it's own notification system (usually via email). So, in > order to change things a user would have to go to each system, find > prefs, find how it's ui was implemented and try and adjust things. > Additionally, this was a massive duplication of effort, with every app > implementing these same things over and over differently. > > As soon as fedmsg bus came along, we were able to turn off the old apps > notification systems (except for bodhi, which I think still emails > itself) and have a app that sits and listens for fedmsgs and notifies > users. This is a win for users in that there's one place to go to change > things and a win for developers because they don't need to implement a > notification system at all, just make sure they emit messages for > everything that is of interest in their app. > > Personally, I think both email and IRC are part of a minimal > replacement. I think SSE was for the planned android app, which we never > really deployed. > > The current FMN app is SUPER flexable, which is awsome, but also makes > it really confusing for people. I think a more simple interface that > lets you choose topics you want to get notified about would do. > > I think it's vital to have several 'predefined' profiles: > * packager - if you are in the packager group, get all your packages > commits, etc. > > * sysadmin - you want to know about nagios alerts, ansible playbook > runs, etc. > > * releng - you get signing, compose info, etc. > > * qa - updates pushes info? openqa results? rc composes? > > * Possibly some more defaults for other groups? > > I think the current FMN batching options are too much. Just say 'daily > digest' 'as they happen' or some small subset. > > I don't think we need to allow validating and using arbitrary email > addresses in the first cut, just use the fas account one. > > Probibly we should make a wiki page and collect everything and then > order importance and see what we NEED to have in a first replacement. > > If we have email, I would like to request that the tool tracks bounces and puts people who have a large bounce rate on hold. I have to at least once every couple of months go onto bastion and clean out a large queue of emails which are never going to be delivered but we try to do day after day. There are 3 problems with us trying to continue delivering mail to nonexistant accounts: a) When there is a storm of activity, legitimate deliveries can get behind b) we every now and then have postfix run out of room c) various spam tools check to see if you keep delivering things and then score you higher as a possible spammer. Our biggest clients of gmail do this regularly where they will start putting our other deliveries at a later time and once I clean out the 10k never going to deliver ones.. they start allowing deliveries. -- 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: Non-responsive maintainer: pocock
On 2/24/20 5:57 PM, Daniel Pocock wrote: On 24/02/2020 20:47, Dakota Williams wrote: Does anyone know how to contact maintainer pocock? https://bugzilla.redhat.com/show_bug.cgi?id=1806708 https://bugzilla.redhat.com/show_bug.cgi?id=1790674 Like most developers, I have a backlog of things to deal with and I try to coordinate fixes for packaging issues into the right part of the release cycle Would you like help? I'd be willing to be a co-maintainer to make the branch. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file
On Mon, Feb 24, 2020 at 06:13:21PM +0100, Miro Hrončok wrote: > On 24. 02. 20 17:48, Pierre-Yves Chibon wrote: > >However, for the release field, we are struggling a little bit more, two > >options > >are more appealing to us: > > Can we please have a "git is the only source of truth" version of > this? I.e. "Compute the release field from the number of commits > since the last version change" in the document. It seem to only have > one con (breaks if two builds are triggered from the same commit) > which is the status quo. This. And a "just use the git changelog" feature as well. In fact both should be the default. 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: State of FMN (FedMSG Notifications) and Replacement
On Wed, Feb 26, 2020 at 02:45:24PM +, Jeremy Cline wrote: > > FYI before I left the team I started hacking up a replacement[0]. My > design focused on how to get as rich a feature set as I could using > only AMQPs currently available filtering features. There's a couple > feature differences for end-users: > > * Users can filter on message importance based on > fedora_messaging_severity and any documented optional header[1]. > Users can also provide AMQP-formatted topics they'd like to receive > notifications for (again, with a severity filter). There's no running > arbitrary regex over messages to filter. That may be enough. I guess we will need to look at the use cases here and see if there's other ones that need some kind of regex... > > * Batch delivery is only available at fixed intervals, unlike the > current system which takes how many pending messages there are as > well. > > This puts all the responsibility of filtering the messages for each > user on RabbitMQ (which is very good at filtering messages and keeping > them until a user wants them). Each user gets a message queue in the > broker, and all the notification service needs to do is make sure the > bindings are set up to filter messages into the queue and dequeue + > deliver the message. The prototype is using Twisted for that. I like a lot about this plan. ;) 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: State of FMN (FedMSG Notifications) and Replacement
On Wed, Feb 26, 2020 at 08:26:09AM +0100, Clement Verna wrote: > Hi all, > > FMN (https://apps.fedoraproject.org/notifications) is currently one of the > main blocking point for dropping fedmsg in favour of fedora-messaging. > FMN is quite important to the community and the composition of Fedora > because it gives emails and notifications on commits, composes, builds and > updates via email and other tools. > > However, the code base is written in Python 2.7 and not maintained anymore. > Currently the service has to run on a Fedora 28 system to continue running. > This causes multiple problems and concerns, and needs to be addressed > before the datacenter move in June. > > In order to start putting together a specification for a replacement, we > should try to look at the minimum requirements for a notification system. > For example the current system supports sending notifications to IRC, > emails and SSE (Server Sent Event), Can we live without SSE ? Can we live > without IRC ? Do we need it to monitor everything it does currently or just > a subset of items that the community has found useful. > > Let's use this thread to brainstorm ideas on what we need. First I can add a bit of history/background for everyone here: Long ago every app in fedora infrastructure (koji, bodhi, etc) implemented it's own notification system (usually via email). So, in order to change things a user would have to go to each system, find prefs, find how it's ui was implemented and try and adjust things. Additionally, this was a massive duplication of effort, with every app implementing these same things over and over differently. As soon as fedmsg bus came along, we were able to turn off the old apps notification systems (except for bodhi, which I think still emails itself) and have a app that sits and listens for fedmsgs and notifies users. This is a win for users in that there's one place to go to change things and a win for developers because they don't need to implement a notification system at all, just make sure they emit messages for everything that is of interest in their app. Personally, I think both email and IRC are part of a minimal replacement. I think SSE was for the planned android app, which we never really deployed. The current FMN app is SUPER flexable, which is awsome, but also makes it really confusing for people. I think a more simple interface that lets you choose topics you want to get notified about would do. I think it's vital to have several 'predefined' profiles: * packager - if you are in the packager group, get all your packages commits, etc. * sysadmin - you want to know about nagios alerts, ansible playbook runs, etc. * releng - you get signing, compose info, etc. * qa - updates pushes info? openqa results? rc composes? * Possibly some more defaults for other groups? I think the current FMN batching options are too much. Just say 'daily digest' 'as they happen' or some small subset. I don't think we need to allow validating and using arbitrary email addresses in the first cut, just use the fas account one. Probibly we should make a wiki page and collect everything and then order importance and see what we NEED to have in a first replacement. 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: Automatic close of bugs for retired packages?
On 26. 02. 20 19:38, Ben Cotton wrote: Components can be marked inactive in Bugzilla, which I believe will prevent users from filing new bugs without losing any historical data. Correct. We have done this with the "python" component. -- 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: Automatic close of bugs for retired packages?
Components can be marked inactive in Bugzilla, which I believe will prevent users from filing new bugs without losing any historical data. Perhaps this should be part of the retirement process? -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: State of FMN (FedMSG Notifications) and Replacement
On Wed, 2020-02-26 at 13:04 -0500, Robbie Harwood wrote: > > Would be nice if there were an API that would let us listen to it > without needing to write an IRC bot or loop polling an HTTP endpoint. > It sounds like this is similar to what Jeremy was proposing, but I'm not > sufficiently versed in Messaging language to know. Maybe I'm missing something, but if you want to do that, I would think you would want to use the *messaging system itself*, not a notification system built on top of the messaging system which is intended specifically for producing notifications for *humans*? You can already work with fedora-messaging fine in production, there are docs and examples to follow: https://fedora-messaging.readthedocs.io/en/latest/index.html both openqa and bodhi deploy fedora-messaging consumer and publishers in infra; you can look at their infra roles and git repos to get a handle on how that works. e.g. the templates for the openQA consumers are at https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/openqa/dispatcher/templates , other relevant bits in https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/openqa/dispatcher/tasks/main.yml , https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/inventory/group_vars/openqa_common and https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/playbooks/groups/openqa.yml . For an example of the actual consumer code, see https://pagure.io/fedora-qa/fedora_openqa/blob/master/f/fedora_openqa/consumer.py . Deploying a consumer outside of infra mainly just involves writing the consumer code, writing a config file like the ones in https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/openqa/dispatcher/templates or the documentation or the sample at https://github.com/fedora-infra/fedora-messaging/blob/master/configs/fedora.toml and placing it in /etc/fedora-messaging , then enabling and starting the `fm-consumer@(whatever).service` service. At present, there is two-way bridging between fedmsg and fedora- messaging: messages published natively as fedmsgs are republished as fedora-messaging messages, and vice versa. So you can write a fedora- messaging-native consumer and still consume messages that are natively published as fedmsgs (or vice versa, but don't do that, we're trying to get people onto fedora-messaging :>) -- 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
[389-devel] please review: PR 50916 - Implement password policy attribute "pwdReset"
https://pagure.io/389-ds-base/pull-request/50916 -- 389 Directory Server Development Team ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: State of FMN (FedMSG Notifications) and Replacement
Clement Verna writes: > Fabio Valentini wrote: >> Clement Verna wrote: >> >>> Hi all, >>> >>> FMN (https://apps.fedoraproject.org/notifications) is currently one >>> of the main blocking point for dropping fedmsg in favour of >>> fedora-messaging. FMN is quite important to the community and the >>> composition of Fedora because it gives emails and notifications on >>> commits, composes, builds and updates via email and other tools. >>> >>> However, the code base is written in Python 2.7 and not maintained >>> anymore. Currently the service has to run on a Fedora 28 system to >>> continue running. This causes multiple problems and concerns, and >>> needs to be addressed before the datacenter move in June. >>> >>> In order to start putting together a specification for a >>> replacement, we should try to look at the minimum requirements for a >>> notification system. For example the current system supports >>> sending notifications to IRC, emails and SSE (Server Sent Event), >>> Can we live without SSE ? Can we live without IRC ? Do we need it to >>> monitor everything it does currently or just a subset of items that >>> the community has found useful. >> >> Is that the service that sends IRC notifications from fedora-notif? > > Yes > >> It's a bit like drinking from the firehose, but I find it incredibly >> useful to get notifications with URLs for whatever's happening to my >> packages. So it would be a shame if that were to disappear ... (or >> replaced by E-Mails, RIP my inbox) > > Yes I also find IRC notifications more useful than the emails, maybe > we can prioritize the IRC notifications then ? Although I am sure we > will have advocate for emails only :-) Would be nice if there were an API that would let us listen to it without needing to write an IRC bot or loop polling an HTTP endpoint. It sounds like this is similar to what Jeremy was proposing, but I'm not sufficiently versed in Messaging language to know. Thanks, --Robbie 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
[Bug 1806215] perl-experimental-0.021 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1806215 --- Comment #7 from Fedora Update System --- perl-experimental-0.021-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-bca9e6da6e -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1805790] perl-Alien-pkgconf-0.16 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1805790 --- Comment #5 from Fedora Update System --- perl-Alien-pkgconf-0.16-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d5736fb6fd -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Automatic close of bugs for retired packages?
I think we could just tell the user that a component is retired by changing the component name to name(retired) or maybe some other means . The gist is to tell the user that the component is retired and is probably not the one that is causing the bug and maybe point to other components which might be causing the issue . Removing the component may be another way to go about it .Maybe retire it at first and remove it after some time just in case someone wants to revive the package . Harsh On Wed, Feb 26, 2020 at 9:46 PM Pavel Raiskup wrote: > I today tried to mimic something that random Fedora user can do, and I > submitted bug against one of our long-time retired components. I haven't > been warned at all that the package is dead. > > As user, it is easy to pick a wrong component when filling a bug - but the > problem with orphaned/retired packages is that nobody listens there > usually. Only 'Orphan Owner '. > > Should such reports be kindly closed automatically by some bot, so user > can reopen against different component? Or should we drop the component > from bugzilla? > > Pavel > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
FedoraRespin-31-updates-20200224.0 compose check report
No missing expected images. Failed openQA tests: 3/35 (x86_64) ID: 528383 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/528383 ID: 528409 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/528409 ID: 528413 Test: x86_64 KDE-live-iso release_identification URL: https://openqa.fedoraproject.org/tests/528413 Soft failed openQA tests: 2/35 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 528393 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/528393 ID: 528395 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/528395 Passed openQA tests: 30/35 (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
Fedora rawhide compose report: 20200226.n.0 changes
OLD: Fedora-Rawhide-20200225.n.0 NEW: Fedora-Rawhide-20200226.n.0 = SUMMARY = Added images:2 Dropped images: 2 Added packages: 9 Dropped packages:3 Upgraded packages: 163 Downgraded packages: 0 Size of added packages: 1.23 GiB Size of dropped packages:9.29 MiB Size of upgraded packages: 4.54 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 319.62 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20200226.n.0.iso Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20200226.n.0.s390x.tar.xz = DROPPED IMAGES = Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20200225.n.0.iso Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20200225.n.0.iso = ADDED PACKAGES = Package: c-ares-1.15.0-5.module_f33+8193+1fee7004 Summary: A library that performs asynchronous DNS operations RPMs:c-ares c-ares-devel Size:1.77 MiB Package: ghc-8.8.3-87.module_f33+8187+7d981aed Summary: Glasgow Haskell Compiler RPMs:ghc ghc-Cabal ghc-Cabal-devel ghc-Cabal-doc ghc-Cabal-prof ghc-array ghc-array-devel ghc-array-doc ghc-array-prof ghc-base ghc-base-devel ghc-base-doc ghc-base-prof ghc-binary ghc-binary-devel ghc-binary-doc ghc-binary-prof ghc-bytestring ghc-bytestring-devel ghc-bytestring-doc ghc-bytestring-prof ghc-compiler ghc-containers ghc-containers-devel ghc-containers-doc ghc-containers-prof ghc-deepseq ghc-deepseq-devel ghc-deepseq-doc ghc-deepseq-prof ghc-devel ghc-directory ghc-directory-devel ghc-directory-doc ghc-directory-prof ghc-doc ghc-doc-index ghc-filepath ghc-filepath-devel ghc-filepath-doc ghc-filepath-prof ghc-ghc ghc-ghc-boot ghc-ghc-boot-devel ghc-ghc-boot-doc ghc-ghc-boot-prof ghc-ghc-boot-th ghc-ghc-boot-th-devel ghc-ghc-boot-th-doc ghc-ghc-boot-th-prof ghc-ghc-compact ghc-ghc-compact-devel ghc-ghc-compact-doc ghc-ghc-compact-prof ghc-ghc-devel ghc-ghc-doc ghc-ghc-heap ghc-ghc-heap-devel ghc-ghc-heap-doc ghc-ghc-heap-prof ghc-ghc-prof ghc-ghci ghc-ghci-devel ghc-ghci-doc ghc-ghci-prof ghc-haskeline ghc-haskeline-devel ghc-haskeline-doc ghc-haskeline-prof ghc-hpc ghc-hpc-devel ghc-hpc-doc ghc-hpc-prof ghc-libiserv ghc-libiserv-devel ghc-libiserv-doc ghc-libiserv-prof ghc-manual ghc-mtl ghc-mtl-devel ghc-mtl-doc ghc-mtl-prof ghc-parsec ghc-parsec-devel ghc-parsec-doc ghc-parsec-prof ghc-pretty ghc-pretty-devel ghc-pretty-doc ghc-pretty-prof ghc-process ghc-process-devel ghc-process-doc ghc-process-prof ghc-prof ghc-stm ghc-stm-devel ghc-stm-doc ghc-stm-prof ghc-template-haskell ghc-template-haskell-devel ghc-template-haskell-doc ghc-template-haskell-prof ghc-terminfo ghc-terminfo-devel ghc-terminfo-doc ghc-terminfo-prof ghc-text ghc-text-devel ghc-text-doc ghc-text-prof ghc-time ghc-time-devel ghc-time-doc ghc-time-prof ghc-transformers ghc-transformers-devel ghc-transformers-doc ghc-transformers-prof ghc-unix ghc-unix-devel ghc-unix-doc ghc-unix-prof ghc-xhtml ghc-xhtml-devel ghc-xhtml-doc ghc-xhtml-prof Size:1.22 GiB Package: libuv-1:1.34.2-1.module_f33+8193+1fee7004 Summary: Platform layer for node.js RPMs:libuv libuv-devel libuv-static Size:2.80 MiB Package: nghttp2-1.40.0-2.module_f33+8197+2ff977a3 Summary: Experimental HTTP/2 client, server and proxy RPMs:libnghttp2 libnghttp2-devel nghttp2 Size:7.41 MiB Package: sil-andika-new-basic-fonts-5.500-2.fc33 Summary: SIL Andika New Basic, a font family for literacy and beginning readers RPMs:sil-andika-new-basic-fonts Size:295.95 KiB Package: vernnobile-muli-fonts-2.001-2.20200225git580b05e.fc33 Summary: Muli, a minimalist sans serif font family RPMs:vernnobile-muli-fonts Size:306.80 KiB Package: vernnobile-nunito-fonts-3.504-2.20200225git6d8a4e1.fc33 Summary: Nunito, a sans serif font family with rounded terminals RPMs:vernnobile-nunito-fonts Size:933.19 KiB Package: vernnobile-oswald-fonts-4.101-3.20200225git5a5fff2.fc33 Summary: Oswald, a reworked gothic style font family RPMs:vernnobile-oswald-fonts Size:209.77 KiB Package: wagesreiter-patrick-hand-fonts-20200215-3.fc33 Summary: Patrick Hand, an handwriting font family RPMs:wagesreiter-patrick-hand-fonts Size:88.61 KiB = DROPPED PACKAGES = Package: antimony-0.9.3-17.fc32 Summary: Computer-aided design CAD tool RPMs:antimony Size:2.70 MiB Package: php-silex-1.3.6-8.fc32 Summary: PHP micro-framework based on the Symfony components RPMs:php-silex Size:85.98 KiB Package: tucnak2-2.31-20.fc31 Summary: VHF contest logging program RPMs:tucnak2 Size:6.50 MiB = UPGRADED PACKAGES = Package: CGAL-5.0.2-1.fc33 Old package: CGAL-5.0.1-2.fc32 Summary: Computational Geometry Algorithms Library RPMs: CGAL-demos-source CGAL-devel
Fedora-IoT-32-20200226.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 1/8 (x86_64) New failures (same test not failed in Fedora-IoT-32-20200224.0): ID: 528416 Test: x86_64 IoT-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/528416 Soft failed openQA tests: 2/8 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-IoT-32-20200224.0): ID: 528414 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/528414 ID: 528415 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/528415 Passed openQA tests: 5/8 (x86_64) New passes (same test not passed in Fedora-IoT-32-20200224.0): ID: 528417 Test: x86_64 IoT-dvd_ostree-iso base_reboot_unmount URL: https://openqa.fedoraproject.org/tests/528417 ID: 528418 Test: x86_64 IoT-dvd_ostree-iso base_selinux URL: https://openqa.fedoraproject.org/tests/528418 ID: 528419 Test: x86_64 IoT-dvd_ostree-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/528419 ID: 528420 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/528420 ID: 528421 Test: x86_64 IoT-dvd_ostree-iso base_system_logging URL: https://openqa.fedoraproject.org/tests/528421 -- 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
Fedora-32-20200226.n.0 compose check report
No missing expected images. Failed openQA tests: 26/171 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-32-20200225.n.0): ID: 527934 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/527934 ID: 527937 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/527937 ID: 527996 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/527996 ID: 528019 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background URL: https://openqa.fedoraproject.org/tests/528019 Old failures (same test failed in Fedora-32-20200225.n.0): ID: 527953 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/527953 ID: 527955 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/527955 ID: 527976 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/527976 ID: 527979 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/527979 ID: 527986 Test: x86_64 Workstation-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/527986 ID: 527994 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/527994 ID: 528003 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/528003 ID: 528010 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/528010 ID: 528033 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/528033 ID: 528036 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/528036 ID: 528038 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/528038 ID: 528039 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/528039 ID: 528048 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/528048 ID: 528049 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/528049 ID: 528056 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/528056 ID: 528061 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/528061 ID: 528064 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/528064 ID: 528077 Test: x86_64 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/528077 ID: 528089 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/528089 ID: 528096 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/528096 ID: 528097 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/528097 ID: 528102 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/528102 ID: 528103 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/528103 Soft failed openQA tests: 14/171 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-32-20200225.n.0): ID: 527931 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/527931 ID: 527932 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/527932 ID: 527936 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/527936 ID: 527939 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/527939 ID: 527940 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/527940 ID: 527960 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/527960 ID: 527989 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/527989 ID: 527991 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/527991 ID: 528023 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/528023 ID: 528032 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/528032 ID: 528050 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/528050 ID: 528085 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/528085 ID: 528088 Test: x86_64 universal
[EPEL-devel] Re: Fail2ban : SELinux is preventing /usr/bin/python2.7 from read access on the file disable
On Wed, 26 Feb 2020 at 11:13, Nicolas Kovacs wrote: > Le 26/02/2020 à 15:48, Stephen John Smoogen a écrit : > > I would open a bug on this so that the maintainer knows about it. They > may not > > be on this list or may filter it to the 'read once a year' bucket. > Second, I > > would check to see what the audit2allow policy came up with and if the > files it > > is alerting on have the appropriate labeling. I spent a day doing this > with > > Nagios and then realized the file problem was that nrpe wanted to do > something > > and hte file was labeled in a 'group' that neither nagios or nrpe had > selinux > > perms to do with. > > First a question: where's the correct place to file a bug for that? I > subscribed to that list because I thought this would be the right place > for > that kind of thing. > > Ugh. My problem for not saying that. A lot of 'bugs' can be config problems so starting a discussion on the list is a good place. After that it is go to https://bugzilla.redhat.com https://bugzilla.redhat.com/buglist.cgi?quicksearch=fail2ban_id=10871278 https://bugzilla.redhat.com/show_bug.cgi?id=1766415 may be related > Anyway. > > I reinstalled this server from scratch and took some notes. > > The second time I succeeded in making Fail2ban work with SELinux. Go > figure. > > I noticed two things, I don't know if they're relevant. > > 1. I had two different suggestions from sealert. > > # ausearch -c 'f2b/server' --raw | audit2allow -M my-f2bserver > # semodule -i my-f2bserver.pp > > and then the same thing but 'f2b/sshd'. > > 2. To create the SELinux I used the root account on the second attempt. On > the > first attempt I used sudo: > > $ sudo ausearch -c 'f2b/f.sshd' --raw | sudo audit2allow -M my-f2bfsshd > IMPORTANT *** > To make this policy package active, execute: > semodule -i my-f2bfsshd.pp > $ sudo semodule -i my-f2bfsshd.pp > > In theory there should be no difference, so correct me if I'm wrong. > > Cheers, > > Niki > > -- > Microlinux - Solutions informatiques durables > 7, place de l'église - 30730 Montpezat > Site : https://www.microlinux.fr > Mail : i...@microlinux.fr > Tél. : 04 66 63 10 32 > Mob. : 06 51 80 12 12 > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > -- Stephen J Smoogen. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Automatic close of bugs for retired packages?
I today tried to mimic something that random Fedora user can do, and I submitted bug against one of our long-time retired components. I haven't been warned at all that the package is dead. As user, it is easy to pick a wrong component when filling a bug - but the problem with orphaned/retired packages is that nobody listens there usually. Only 'Orphan Owner '. Should such reports be kindly closed automatically by some bot, so user can reopen against different component? Or should we drop the component from bugzilla? Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Fail2ban : SELinux is preventing /usr/bin/python2.7 from read access on the file disable
Le 26/02/2020 à 15:48, Stephen John Smoogen a écrit : I would open a bug on this so that the maintainer knows about it. They may not be on this list or may filter it to the 'read once a year' bucket. Second, I would check to see what the audit2allow policy came up with and if the files it is alerting on have the appropriate labeling. I spent a day doing this with Nagios and then realized the file problem was that nrpe wanted to do something and hte file was labeled in a 'group' that neither nagios or nrpe had selinux perms to do with. First a question: where's the correct place to file a bug for that? I subscribed to that list because I thought this would be the right place for that kind of thing. Anyway. I reinstalled this server from scratch and took some notes. The second time I succeeded in making Fail2ban work with SELinux. Go figure. I noticed two things, I don't know if they're relevant. 1. I had two different suggestions from sealert. # ausearch -c 'f2b/server' --raw | audit2allow -M my-f2bserver # semodule -i my-f2bserver.pp and then the same thing but 'f2b/sshd'. 2. To create the SELinux I used the root account on the second attempt. On the first attempt I used sudo: $ sudo ausearch -c 'f2b/f.sshd' --raw | sudo audit2allow -M my-f2bfsshd IMPORTANT *** To make this policy package active, execute: semodule -i my-f2bfsshd.pp $ sudo semodule -i my-f2bfsshd.pp In theory there should be no difference, so correct me if I'm wrong. Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Ideas and proposal for removing changelog and release fields from spec file
On Wed, 2020-02-26 at 11:29 +0100, Nicolas Mailhot via devel wrote: > Le 2020-02-26 11:14, Nils Philippsen a écrit : > > > Well, if we officially were to break with the upgrade path > > constraints, > > we'd have to document this. While we're at it, we should then > > document > > that Rawhide users should use "dnf distro-sync". > > That won’t work because (for example) rawhide is pulling forward > *right* > *now*, while F32 is not finished, so you have a *huge* time windows > during which there is nothing to distro-sync with, and you still need > to > keep compat between rawhide and future-stable numbering. Heh, I wasn't volunteering to push this. If you ask me, we should stick with having a clean upgrade path. Nils -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file
On Mon, 24 Feb 2020 at 11:50, Pierre-Yves Chibon wrote: > Good Morning Everyone, > > This topic has already been discussed a few times over the past month, but > Adam > Saleh, Nils Philippsen and myself have had the opportunity to invest some > time > on it with the hope of making the packager's life simpler as well as > making it > easier to build automation around our package maintenance. > Going through the various discussions, I think we are running into a classic sausage factory problem.. everyone wants to have their favourite meat, but the only way to make it work is mix them all together, grind it up and come up with something else. Would it make sense to classify packages into 3 different groupings (like cheese)? Processed cheese: packages which are automatically built with a processed tool that updates most of the items. Just gets a bit of work every now and then from a packager afterwords for major changes or side-cases found. Everything in the package is fully automated with build tools filling in all the needed data for it. Cheddar cheese: packages which need more work and care, but are still pretty 'standard'... some may be sharper and need some aging but might be ok with some automated parts (%changelog and %release and a couple of things). Beaufort D'Ete (etc etc): packages which need a lot of work on the side of the maintainer to make it work for multiple reasons. Each packager has their own way of dealing with these packages which makes each a regional cheese. Currently a lot of packagers have to spend their time making cheeze-wiz packages so that they can even get to working on their specialist cheese. But because they are focused on wanting to get that specialist package out they are worried that any change will make all packages cheeze-wiz. I am wondering if we just make that part of the system separate with people knowing that they can label a package into a specific mental bucket, they can focus their energies on their Comté vieux. -- 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: OCaml 4.10.0 build in Fedora 32 and 33
[This is mainly a note-to-self so I know what the problems are next time] On Mon, Feb 24, 2020 at 01:53:37PM -0700, Jerry James wrote: > I may have caused you a problem with the ocaml-ounit update I > requested. Now we have ocaml-ounit requiring ocaml-dune to build, and > ocaml-dune requiring ocaml-ounit to run its tests. I guess ocaml-dune > will need a bootstrap mode where it does not run its tests. There's another circular dependency caused by ocaml-ounit. I thought it was ocaml-ounit <-> ocaml-lwt, and I made the ocaml-ounit-lwt subpackage optional. However that still doesn't solve the issue. The main thing for me is I need to improve goals so it can clearly show circular dependencies, and also so that controlled cuts can be made in the dependency graph. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.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
[rpms/perl-Test-mysqld] PR #1: Use the correct name of the required package
mschorm commented on the pull-request: `Use the correct name of the required package` that you are following: `` Hello, I'm the mainatiner of 'mariadb' and 'community-mysql', which both provides this "mysql-compat*" names. I'm trying to clean up ancient artifact and get rid of them. Your package is the only one using them nowadays. I changed the mysql-compat*" names to the actual result resolved by DNF, which is (correctly) 'mariadb' `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Test-mysqld/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[rpms/perl-Test-mysqld] PR #1: Use the correct name of the required package
mschorm opened a new pull-request against the project: `perl-Test-mysqld` that you are following: `` Use the correct name of the required package `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Test-mysqld/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1807554] New: perl-MooX-Struct-0.020 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1807554 Bug ID: 1807554 Summary: perl-MooX-Struct-0.020 is available Product: Fedora Version: rawhide Status: NEW Component: perl-MooX-Struct Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.020 Current version/release in rawhide: 0.019-1.fc33 URL: http://search.cpan.org/dist/MooX-Struct/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/10995/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Ideas and proposal for removing changelog and release fields from spec file
Dne 26. 02. 20 v 12:16 clime napsal(a):
> Few more notes:
> - having just: Release: means every commit bumps
> release and hence every commit should likely generate a new record
> into changelog => changelog basically becomes dumped `git log` (in
> rpm-compatible format) - i.e. there is no capability to group multiple
> changes into one changelog record (grouping them implicitly by version
> changes will be tricky because changelogs will become mutable)
If you care, you'll be able to manually modify the changelog. But I
agree that some automatic grouping would be nice. May be there could
also be grouping hint, similarly to `RPM-Changelog: exclude`.
Vít
> - it doesn't help in jumping from specific package name to a specific
> commit in dist-git unless the macro also generates short git hash into
> the release but it also doesn't make things worse compared to now
> - for the solution with external changelog file with the commit
> fallback - it might be slightly confusing for someone who wants to
> look through the changes for a package in dist-git - at first, one
> should look at commits but from a certain commit switch to the file =>
> probably everyone will just stick to reading the commits
>
> I very much like simplicity of the approach but i think it is good to
> realize that the proposed solution is a direct translation of: "RPM
> Changelog and Release, you are not needed. Stand aside and don't make
> any problems!" If this is what packagers usually want, then it is a
> good solution. I think it also depends on what rpm consumers generally
> want.
>
> Then from the document:
> Get the release field from the annotation of the git tag
> (-) requires manual work on behalf of the maintainer
>
> That doesn't need to be the case with a client-side tooling
> that generates release automatically into a tag name.
>
> (-) Fragile: this means parsing using a regex the git annotation to
> extract the release information
>
> I would suggest putting release directly into a tag name, not into its
> annotation (i.e. subject or body). Basically tag names = NVRs.
>
> There is nothing fragile on parsing release from such name. In python,
> it is just standard rsplit('-', 1) and taking the last component.
>
> There are two issues here:
> 1) epochs: they will need to be put into the tag-name as /NVR
> because tag names cannot contain colons
> 2) tilde for prereleases: git tags cannot contain tilde character
> ('~'). But i personally believe we could find better ways to mark a
> prerelease. It used to be forbidden in Fedora...
>
> clime
>
> On Tue, 25 Feb 2020 at 22:20, James Cassell
> wrote:
>>
>> On Tue, Feb 25, 2020, at 2:53 PM, Matthew Miller wrote:
>>> On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
So these are the results of our current investigations, we are very much
eager
to get your feedback on them and even more eager if you have ideas on how
to
approach/solve some of the challenges mentioned here.
>>> This all sounds great. I'd also love for there to be a standard way of
>>> tagging specific git commit log messages as meant for user consumption, and
>>> use that to prepopulate the bodhi release notes field (with an eventual eye
>>> towards making this the single source of Fedora package change information).
>>>
>> Indeed, it is unfortunate that the Bodhi info for EOL releases is currently
>> lost.
>>
>> V/r,
>> James Cassell
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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: Orphaning a few Java packages
On Wed, Feb 26, 2020 at 5:10 PM Fabio Valentini wrote: > Hi all, > > I've just orphaned a few Java packages on behalf of the Stewardship > SIG since we no longer have any use for them. > > - aalto-xml > - compress-lzf > - icu4j > ^^ Mat, should we take it or keep a huge patch removing the need for it ? > - jboss-marshalling > - jetty-alpn-api > - lz4-java > - lzma-java > - os-maven-plugin > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Alexander Kurtakov Red Hat Eclipse Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ideas and proposal for removing changelog and release fields from spec file
Dne 25. 02. 20 v 15:03 Pierre-Yves Chibon napsal(a): > On Tue, Feb 25, 2020 at 12:59:39PM +0100, Vít Ondruch wrote: > > [About the release field] > >> I am not really sure about this. How do you envision this is going to be >> implemented? Is there going to be "release" file, similarly to >> changelog, which would help me to override this? I just wanted to stress out that I believe it would be good idea to use similar approach for changelog as well as for release. I.e. both should be opt-in, stored externally, overridable, and the automation should kick in only if they were not touched by the last commit. Vít >> Because, currently, it >> seems that both methods are going to need a lot of information from the >> build system. > The first method using number of commits and number of builds, pull limited > information from the build system (just: how many builds succeed before this > one > with this version and release?). > The second method does rely heavily on the build system. > >> They will need to parse .spec file etc. I don't see this >> to be able to handle even a bit more complex stuff like e.g. >> https://src.fedoraproject.org/rpms/ruby/blob/master/f/ruby.spec#_26 > We've been trying to find something that fit the majority of the packages but > we > are well aware that there are and will always be some special snowflakes that > will not be able to adhere to this. > I'd be happy if this works makes life/packaging easier for 50% of our packages > (I'd even probably be happy if it's 20%). > Once we have the simple case out and we can test it, see how it behaves, what > its limits are, we can start building on more complex cases, but I don't > really > believe on building the perfect solution in one go. > > > Pierre > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaning a few Java packages
Hi all, I've just orphaned a few Java packages on behalf of the Stewardship SIG since we no longer have any use for them. - aalto-xml - compress-lzf - icu4j - jboss-marshalling - jetty-alpn-api - lz4-java - lzma-java - os-maven-plugin Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: 20200226.n.0 changes
OLD: Fedora-32-20200225.n.0 NEW: Fedora-32-20200226.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 0 Dropped packages:0 Upgraded packages: 57 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 1.52 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -268.95 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-32-20200226.n.0.iso = DROPPED IMAGES = Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-32-20200225.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: CGAL-5.0.2-1.fc32 Old package: CGAL-5.0.1-2.fc32 Summary: Computational Geometry Algorithms Library RPMs: CGAL-demos-source CGAL-devel CGAL-qt5-devel Size: 114.12 MiB Size change: -788.09 KiB Changelog: * Tue Feb 25 2020 Laurent Rineau - 5.0.2-1 - New upstream release - Remove the Source10 (replaced by a heredoc) Package: R-R.methodsS3-1.8.0-1.fc32 Old package: R-R.methodsS3-1.7.1-7.fc32 Summary: S3 Methods Simplified RPMs: R-R.methodsS3 Size: 94.09 KiB Size change: 2.89 KiB Changelog: * Mon Feb 24 2020 Elliott Sales de Andrade - 1.8.0-1 - Update to latest version Package: R-Rmpfr-0.8.1-1.fc32 Old package: R-Rmpfr-0.7.2-6.fc32 Summary: R MPFR - Multiple Precision Floating-Point Reliable RPMs: R-Rmpfr Size: 5.69 MiB Size change: 134.82 KiB Changelog: * Mon Feb 24 2020 Elliott Sales de Andrade - 0.8.1-1 - Update to latest version Package: R-XML-3.99.0.3-1.fc32 Old package: R-XML-3.98.1.20-2.fc32 Summary: Tools for Parsing and Generating XML Within R and S-Plus RPMs: R-XML Size: 8.62 MiB Size change: -1.30 MiB Changelog: * Mon Feb 24 2020 Elliott Sales de Andrade - 3.99.0.3-1 - Update to latest version Package: R-bit-1.1.15.2-1.fc32 Old package: R-bit-1.1.14-5.fc32 Summary: Class for vectors of 1-bit booleans RPMs: R-bit Size: 1.22 MiB Size change: 7.66 KiB Changelog: * Mon Feb 24 2020 Elliott Sales de Andrade - 1.1.15.2-1 - Update to latest version Package: R-caTools-1.18.0-1.fc32 Old package: R-caTools-1.17.1.3-2.fc32 Summary: Tools: moving window statistics, GIF, Base64, ROC AUC, etc. RPMs: R-caTools Size: 1.14 MiB Size change: -6.72 KiB Changelog: * Mon Feb 24 2020 Elliott Sales de Andrade - 1.18.0-1 - Update to latest version Package: R-callr-3.4.2-1.fc32 Old package: R-callr-3.4.0-2.fc32 Summary: Call R from R RPMs: R-callr Size: 389.02 KiB Size change: 39.77 KiB Changelog: * Mon Feb 24 2020 Elliott Sales de Andrade - 3.4.2-1 - Update to latest version Package: R-chron-2.3.55-1.fc32 Old package: R-chron-2.3.54-1.fc32 Summary: Chronological Objects which can Handle Dates and Times RPMs: R-chron Size: 1.00 MiB Size change: 3.12 KiB Changelog: * Tue Jan 28 2020 Fedora Release Engineering - 2.3.54-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Mon Feb 24 2020 Elliott Sales de Andrade - 2.3.55-1 - Update to latest version Package: R-date-1.2.39-1.fc32 Old package: R-date-1.2.38-7.fc32 Summary: Functions for Handling Dates RPMs: R-date Size: 311.50 KiB Size change: 1.19 KiB Changelog: * Mon Feb 24 2020 Elliott Sales de Andrade - 1.2.39-1 - Update to latest version Package: R-deldir-0.1.25-1.fc32 Old package: R-deldir-0.1.23-3.fc32 Summary: Delaunay Triangulation and Dirichlet (Voronoi) Tessellation RPMs: R-deldir Size: 1.13 MiB Size change: -4.58 KiB Changelog: * Mon Feb 24 2020 Elliott Sales de Andrade - 0.1.25-1 - Update to latest version Package: R-dtplyr-1.0.1-1.fc32 Old package: R-dtplyr-0.0.3-4.fc32 Summary: Data Table Back-End for 'dplyr' RPMs: R-dtplyr Size: 107.52 KiB Size change: 38.14 KiB Changelog: * Mon Feb 24 2020 Elliott Sales de Andrade - 1.0.1-1 - Update to latest version Package: R-farver-2.0.3-1.fc32 Old package: R-farver-2.0.2-2.fc32 Summary: High Performance Colour Space Manipulation RPMs: R-farver Size: 6.70 MiB Size change: 32.07 KiB Changelog: * Mon Feb 24 2020 Elliott Sales de Andrade - 2.0.3-1 - Update to latest version Package: R-foreach-1.4.8-1.fc32 Old package: R-foreach-1.4.7-2.fc32 Summary: Provides Foreach Looping Construct RPMs: R-foreach Size: 137.31 KiB Size change: -271.53 KiB Changelog: * Mon Feb 24 2020 Elliott Sales de Andrade - 1.4.8-1 - Update to latest version Package: R-future-1.16.0-1.fc32 Old package: R-future-1.15.1-2.fc32 Summary: Unified Parallel and Distributed Processing
[EPEL-devel] Re: Fail2ban : SELinux is preventing /usr/bin/python2.7 from read access on the file disable
On Wed, 26 Feb 2020 at 07:06, Nicolas Kovacs wrote: > Hi, > > I have an Internet-facing server running CentOS 7. I just installed > Fail2ban > using the following packages: > >* fail2ban-server >* fail2ban-firewalld > > For the record, IPv6 is disabled on this server. > > Here's the SELinux error I get. > > > SELinux is preventing /usr/bin/python2.7 from read access on the file > disable. > > * Plugin catchall (100. confidence) suggests * > > If you believe that python2.7 should be allowed read access on the disable > file > by default. > Then you should report this as a bug. > You can generate a local policy module to allow this access. > Do > allow this access for now by executing: > # ausearch -c 'f2b/server' --raw | audit2allow -M my-f2bserver > # semodule -i my-f2bserver.pp > > > Weirdly enough, when I follow this suggestion, generate the module and > then > empty audit.log and restart my server, I still get the exact same error > again. > > Which makes Fail2ban unusable with SELinux in enforcing mode in the > current state > I would open a bug on this so that the maintainer knows about it. They may not be on this list or may filter it to the 'read once a year' bucket. Second, I would check to see what the audit2allow policy came up with and if the files it is alerting on have the appropriate labeling. I spent a day doing this with Nagios and then realized the file problem was that nrpe wanted to do something and hte file was labeled in a 'group' that neither nagios or nrpe had selinux perms to do with. > Cheers from the sunny South of France, > > Niki Kovacs > > -- > Microlinux - Solutions informatiques durables > 7, place de l'église - 30730 Montpezat > Site : https://www.microlinux.fr > Mail : i...@microlinux.fr > Tél. : 04 66 63 10 32 > Mob. : 06 51 80 12 12 > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > -- Stephen J Smoogen. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: State of FMN (FedMSG Notifications) and Replacement
On Wed, 2020-02-26 at 08:26 +0100, Clement Verna wrote: > Hi all, > > FMN (https://apps.fedoraproject.org/notifications) is currently one > of the main blocking point for dropping fedmsg in favour of fedora- > messaging. > FMN is quite important to the community and the composition of Fedora > because it gives emails and notifications on commits, composes, > builds and updates via email and other tools. > > However, the code base is written in Python 2.7 and not maintained > anymore. Currently the service has to run on a Fedora 28 system to > continue running. This causes multiple problems and concerns, and > needs to be addressed before the datacenter move in June. > > In order to start putting together a specification for a replacement, > we should try to look at the minimum requirements for a notification > system. For example the current system supports sending notifications > to IRC, emails and SSE (Server Sent Event), Can we live without SSE ? > Can we live without IRC ? Do we need it to monitor everything it does > currently or just a subset of items that the community has found > useful. > > Let's use this thread to brainstorm ideas on what we need. > FYI before I left the team I started hacking up a replacement[0]. My design focused on how to get as rich a feature set as I could using only AMQPs currently available filtering features. There's a couple feature differences for end-users: * Users can filter on message importance based on fedora_messaging_severity and any documented optional header[1]. Users can also provide AMQP-formatted topics they'd like to receive notifications for (again, with a severity filter). There's no running arbitrary regex over messages to filter. * Batch delivery is only available at fixed intervals, unlike the current system which takes how many pending messages there are as well. This puts all the responsibility of filtering the messages for each user on RabbitMQ (which is very good at filtering messages and keeping them until a user wants them). Each user gets a message queue in the broker, and all the notification service needs to do is make sure the bindings are set up to filter messages into the queue and dequeue + deliver the message. The prototype is using Twisted for that. There's a non-trivial amount of work to do on the prototype, and I never did anything for a web UI, but it's a skeleton of what I'd recommend as it minimizes the amount of work you have to do. If you wanted to be even more minimal, you could see about using RabbitMQ plugins to handle sending the emails and IRC notifications. I believe there's already one for email available, but you might have to write a little Elixer or Erlang for IRC notifications. If you wanted to get even more minimal, you might be able to expose the RabbitMQ web UI and just create users for each FAS account with permissions to create their queues (and no other queues) themselves, but that would be quite a bit less usable. [0] https://github.com/jeremycline/fedora-notifications [1] https://fedora-messaging.readthedocs.io/en/stable/wire-format.html#optional ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Fail2ban : SELinux is preventing /usr/bin/python2.7 from read access on the file disable
On 2/26/20 3:33 PM, Bussi Andrea wrote: On 2/26/20 2:52 PM, Nicolas Kovacs wrote: Le 26/02/2020 à 13:05, Nicolas Kovacs a écrit : Weirdly enough, when I follow this suggestion, generate the module and then empty audit.log and restart my server, I still get the exact same error again. Which makes Fail2ban unusable with SELinux in enforcing mode in the current state. Looks like this is clearly a bug. I made some more testing. Installed vanilla CentOS 7 on an Internet-facing sandbox server. Configured NetworkManager. Configured FirewallD. Installed fail2ban-server and fail2ban-firewalld. Put this in /etc/fail2ban/jail.d/sshd.local [sshd] enabled = true Started Fail2ban. I get the same SELinux error than the one described in the initial message to the list. And when I follow the advice displayed by SEalert, the same error occurs again. Which leaves me clueless. Any suggestions ? Interesting. I only notice a small difference with my setup; and that is that I explicitly set an action. My jail.local (with some unrelated lines removed): [sshd] enabled = true maxretry = 7 action = firewallcmd-new[name=SSH, port=ssh, protocol=tcp] I am not sure if that's what makes a difference here, but it's worth trying. Bussi Andrea My bad; I checked on my server, and I have the same AVC as you're seeing. But I can confirm it is not preventing fail2ban from doing its work; offenders still get banned. Best regards, Bussi Andrea Niki Kovacs ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Fail2ban : SELinux is preventing /usr/bin/python2.7 from read access on the file disable
On 2/26/20 2:52 PM, Nicolas Kovacs wrote: Le 26/02/2020 à 13:05, Nicolas Kovacs a écrit : Weirdly enough, when I follow this suggestion, generate the module and then empty audit.log and restart my server, I still get the exact same error again. Which makes Fail2ban unusable with SELinux in enforcing mode in the current state. Looks like this is clearly a bug. I made some more testing. Installed vanilla CentOS 7 on an Internet-facing sandbox server. Configured NetworkManager. Configured FirewallD. Installed fail2ban-server and fail2ban-firewalld. Put this in /etc/fail2ban/jail.d/sshd.local [sshd] enabled = true Started Fail2ban. I get the same SELinux error than the one described in the initial message to the list. And when I follow the advice displayed by SEalert, the same error occurs again. Which leaves me clueless. Any suggestions ? Interesting. I only notice a small difference with my setup; and that is that I explicitly set an action. My jail.local (with some unrelated lines removed): [sshd] enabled = true maxretry = 7 action= firewallcmd-new[name=SSH, port=ssh, protocol=tcp] I am not sure if that's what makes a difference here, but it's worth trying. Bussi Andrea Niki Kovacs ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Fedora-Rawhide-20200226.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 1 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 22/171 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20200225.n.0): ID: 527689 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/527689 ID: 527696 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/527696 ID: 527728 Test: x86_64 Everything-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/527728 ID: 527732 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/527732 ID: 527735 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/527735 Old failures (same test failed in Fedora-Rawhide-20200225.n.0): ID: 527709 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/527709 ID: 527711 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/527711 ID: 527766 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/527766 ID: 527789 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/527789 ID: 527792 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/527792 ID: 527794 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/527794 ID: 527795 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/527795 ID: 527804 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/527804 ID: 527805 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/527805 ID: 527812 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/527812 ID: 527817 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/527817 ID: 527820 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/527820 ID: 527833 Test: x86_64 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/527833 ID: 527845 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/527845 ID: 527852 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/527852 ID: 527853 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/527853 ID: 527858 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/527858 ID: 527859 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/527859 Soft failed openQA tests: 15/171 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20200225.n.0): ID: 527745 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/527745 ID: 527762 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/527762 Old soft failures (same test soft failed in Fedora-Rawhide-20200225.n.0): ID: 527687 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/527687 ID: 527688 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/527688 ID: 527690 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/527690 ID: 527692 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/527692 ID: 527695 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/527695 ID: 527716 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/527716 ID: 527747 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/527747 ID: 527779 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/527779 ID: 527788 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/527788 ID: 527806 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/527806 ID: 527841 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/527841 ID: 527844 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/527844 ID: 527851 Test: x86_64 universal
[EPEL-devel] Re: Fail2ban : SELinux is preventing /usr/bin/python2.7 from read access on the file disable
Le 26/02/2020 à 13:05, Nicolas Kovacs a écrit : Weirdly enough, when I follow this suggestion, generate the module and then empty audit.log and restart my server, I still get the exact same error again. Which makes Fail2ban unusable with SELinux in enforcing mode in the current state. Looks like this is clearly a bug. I made some more testing. Installed vanilla CentOS 7 on an Internet-facing sandbox server. Configured NetworkManager. Configured FirewallD. Installed fail2ban-server and fail2ban-firewalld. Put this in /etc/fail2ban/jail.d/sshd.local [sshd] enabled = true Started Fail2ban. I get the same SELinux error than the one described in the initial message to the list. And when I follow the advice displayed by SEalert, the same error occurs again. Which leaves me clueless. Any suggestions ? Niki Kovacs -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[Bug 1807479] New: Upgrade perl-MooX-late to 0.100
https://bugzilla.redhat.com/show_bug.cgi?id=1807479 Bug ID: 1807479 Summary: Upgrade perl-MooX-late to 0.100 Product: Fedora Version: rawhide Status: NEW Component: perl-MooX-late Assignee: rc040...@freenet.de Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Latest Fedora delivers 0.016 version. Upstream released 0.100. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora-IoT-33-20200226.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 2/8 (x86_64) Old failures (same test failed in Fedora-IoT-33-20200224.0): ID: 527917 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/527917 ID: 527918 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/527918 Skipped non-gating openQA tests: 6 of 8 -- 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
[EPEL-devel] Re: Fail2ban : SELinux is preventing /usr/bin/python2.7 from read access on the file disable
On 2/26/20 1:05 PM, Nicolas Kovacs wrote: Hi, I have an Internet-facing server running CentOS 7. I just installed Fail2ban using the following packages: * fail2ban-server * fail2ban-firewalld For the record, IPv6 is disabled on this server. Here's the SELinux error I get. SELinux is preventing /usr/bin/python2.7 from read access on the file disable. * Plugin catchall (100. confidence) suggests * If you believe that python2.7 should be allowed read access on the disable file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'f2b/server' --raw | audit2allow -M my-f2bserver # semodule -i my-f2bserver.pp Weirdly enough, when I follow this suggestion, generate the module and then empty audit.log and restart my server, I still get the exact same error again. Which makes Fail2ban unusable with SELinux in enforcing mode in the current state. I'm using fail2ban with SELinux in enforcing mode on CentOS 7; and I am not seeing that error. I can't find any reference to a 'disable' file inside my fail2ban configuration; is it a local configuration? If it is, probably you need to add some SELinux rules permitting fail2ban (which is running with the fail2ban_t context) to read that file. Best regards, Bussi Andrea Cheers from the sunny South of France, Niki Kovacs ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Fedora & Containers
On 2/25/20 12:05 PM, Michal Schorm wrote: > Hello, > > Will anybody be able to explain to me the current state of the > containers & containerization in Fedora, please? > > I have some questions, but the more I searched for whom & where to > ask, the more confused I became. > > -- > > 1) There ́s an IRC on freenode, '#fedora-containers' channel. > The TOPIC set contains the following message: > "The place for container runtimes and application containers. > Forums @ https://discussion.fedoraproject.org/c/containers, > visit the site @ https://containers.fedoraproject.org > (website operational at some point in August)." > However no link mentioned are accessible. > > 2) There is 'Fedora Container & Tools Documentation' [1] > It is only half-filled with information, some part missing entirely. > Even parts as 'Container Guidelines' [2]. > Btw the wiki gladly redirects there ^ [3]. > Btw there are some scratch notes about the guidelines from damn 2017 > [4], which google offers me rather than the actual guidelines (because > they don't exist) > > 3) So ... who is in charge of it? Whom to contact? How? Where? > Does Fedora count with Containers or does it already thrown it overboard? > > 4) The container I am maintainer of (in pagure in 'container' > namespace) is not branched automatically. The last branch is 'f30', > but now I want to update it and add the missing branches. I have no > idea how should I do it though, since (1) (2) are such a mess. > I can try 'git push', but anyway, it won't solve the issue, it's not > branched automatically. > > 5) The Dockerfile (are we still using this name? shouldn't it be > 'containerfile' now, with podman?) Containerfile will not work with Docker by default, so if you want to stick to Dockerfile, it is fine. > starts with line like: > " FROM registry.fedoraproject.org/f30/." > How can I substitute the Fedora release version with a variable, so I > can share the same content amongst branches for different Fedora > releases? You could specify this as ARG and then have the caller pass in the version of Fedora ARG=RELEASE=f31 ... FROM registry.fedoraproject.org/RELEASE/ ... podman build --build-arg RELEASE=f30 -f Dockerfile . > [1] https://docs.fedoraproject.org/en-US/containers/ > [2] https://docs.fedoraproject.org/en-US/containers/guidelines/guidelines/ > [3] https://fedoraproject.org/wiki/Container:Guidelines > [4] https://fedoraproject.org/wiki/Talk:Container:Guidelines > > -- > > Michal Schorm > Software Engineer > Core Services - Databases Team > Red Hat > > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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
[EPEL-devel] Fail2ban : SELinux is preventing /usr/bin/python2.7 from read access on the file disable
Hi, I have an Internet-facing server running CentOS 7. I just installed Fail2ban using the following packages: * fail2ban-server * fail2ban-firewalld For the record, IPv6 is disabled on this server. Here's the SELinux error I get. SELinux is preventing /usr/bin/python2.7 from read access on the file disable. * Plugin catchall (100. confidence) suggests * If you believe that python2.7 should be allowed read access on the disable file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'f2b/server' --raw | audit2allow -M my-f2bserver # semodule -i my-f2bserver.pp Weirdly enough, when I follow this suggestion, generate the module and then empty audit.log and restart my server, I still get the exact same error again. Which makes Fail2ban unusable with SELinux in enforcing mode in the current state. Cheers from the sunny South of France, Niki Kovacs -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: OCaml 4.10.0 build in Fedora 32 and 33
On Mon, Feb 24, 2020 at 01:53:37PM -0700, Jerry James wrote: > On Mon, Feb 24, 2020 at 1:57 AM Richard W.M. Jones wrote: > > * z3 - https://bugzilla.redhat.com/show_bug.cgi?id=1792740 > > Actually, z3 should build. I checked in a workaround. The bug is > still open to remind me to figure out and fix the real problem. > > > coq and friends failed last time, but I believe they should work now. > > Latest status is in this thread: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6I2CB4KNAZXH6TKX5WQZJ3ZQGBIOCNJK/ > > I'm still 3 package reviews away from being able to update the coq > stack. Real soon now > > I may have caused you a problem with the ocaml-ounit update I > requested. Now we have ocaml-ounit requiring ocaml-dune to build, and > ocaml-dune requiring ocaml-ounit to run its tests. I guess ocaml-dune > will need a bootstrap mode where it does not run its tests. > > That's not going to be the end, either. There is a new upstream > release of menhir, and it has switched to using dune to build. That > means that we will have menhir requiring dune to build, and dune > requiring menhir to run its tests. Yes I now see what you mean :-/ The current circular dep is something like: coq -> menhir -> dune -> ounit -> ... -> coq And it turns out dune has libraries, not just a binary, so what I previously said won't work. I temporarily removed the dependency of menhir on coq which will hopefully break that cycle. (Luckily there is no dune -> menhir dependency yet.) Not sure about the long term solution to this. I'd kind of like to avoid bootstrapping builds, but maybe there is no other option here. 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: Seeking co-maintainer for libffi package
On 26. 02. 20 12:19, Anthony Green wrote: Thank you for all of the offers. The team that maintains glibc (Carlos, Florian and DJ) has stepped up to help with libffi packaging. I think that this is the right group to handle libffi for now. Thanks! -- 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: Seeking co-maintainer for libffi package
Thank you for all of the offers. The team that maintains glibc (Carlos, Florian and DJ) has stepped up to help with libffi packaging. I think that this is the right group to handle libffi for now. Thanks again, AG On Tue, Feb 25, 2020 at 10:56 AM Anthony Green wrote: > > Hello -- I'm the current Fedora maintainer for libffi, as well as the > upstream author/maintainer. I'm looking for help with libffi > packaging. Specifically, we need to roll out a new ABI-breaking > release (required for ARM64 and Intel CET support), and I don't have > the volunteer time available to create the requisite compat packages, > monitor all of the rebuilds, etc. It would be best if this person > had some Fedora packaging experience under their belt, given some of > the complexities involved and the criticality of libffi to the whole > platform. > > Thanks! > > AG > > -- > Anthony Green > Senior Principal Solutions Architect, Financial Services -- Anthony Green Senior Principal Solutions Architect, Financial Services +1 647 477-3809 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file
Few more notes:
- having just: Release: means every commit bumps
release and hence every commit should likely generate a new record
into changelog => changelog basically becomes dumped `git log` (in
rpm-compatible format) - i.e. there is no capability to group multiple
changes into one changelog record (grouping them implicitly by version
changes will be tricky because changelogs will become mutable)
- it doesn't help in jumping from specific package name to a specific
commit in dist-git unless the macro also generates short git hash into
the release but it also doesn't make things worse compared to now
- for the solution with external changelog file with the commit
fallback - it might be slightly confusing for someone who wants to
look through the changes for a package in dist-git - at first, one
should look at commits but from a certain commit switch to the file =>
probably everyone will just stick to reading the commits
I very much like simplicity of the approach but i think it is good to
realize that the proposed solution is a direct translation of: "RPM
Changelog and Release, you are not needed. Stand aside and don't make
any problems!" If this is what packagers usually want, then it is a
good solution. I think it also depends on what rpm consumers generally
want.
Then from the document:
Get the release field from the annotation of the git tag
(-) requires manual work on behalf of the maintainer
That doesn't need to be the case with a client-side tooling
that generates release automatically into a tag name.
(-) Fragile: this means parsing using a regex the git annotation to
extract the release information
I would suggest putting release directly into a tag name, not into its
annotation (i.e. subject or body). Basically tag names = NVRs.
There is nothing fragile on parsing release from such name. In python,
it is just standard rsplit('-', 1) and taking the last component.
There are two issues here:
1) epochs: they will need to be put into the tag-name as /NVR
because tag names cannot contain colons
2) tilde for prereleases: git tags cannot contain tilde character
('~'). But i personally believe we could find better ways to mark a
prerelease. It used to be forbidden in Fedora...
clime
On Tue, 25 Feb 2020 at 22:20, James Cassell wrote:
>
>
> On Tue, Feb 25, 2020, at 2:53 PM, Matthew Miller wrote:
> > On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> > > So these are the results of our current investigations, we are very much
> > > eager
> > > to get your feedback on them and even more eager if you have ideas on how
> > > to
> > > approach/solve some of the challenges mentioned here.
> >
> > This all sounds great. I'd also love for there to be a standard way of
> > tagging specific git commit log messages as meant for user consumption, and
> > use that to prepopulate the bodhi release notes field (with an eventual eye
> > towards making this the single source of Fedora package change information).
> >
>
> Indeed, it is unfortunate that the Bodhi info for EOL releases is currently
> lost.
>
> V/r,
> James Cassell
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file
Le 2020-02-26 11:14, Nils Philippsen a écrit : Well, if we officially were to break with the upgrade path constraints, we'd have to document this. While we're at it, we should then document that Rawhide users should use "dnf distro-sync". That won’t work because (for example) rawhide is pulling forward *right* *now*, while F32 is not finished, so you have a *huge* time windows during which there is nothing to distro-sync with, and you still need to keep compat between rawhide and future-stable numbering. If you don’t keep compat you can not solve post-beta-freeze issues by pulling in future-stable the rawhide packages that solve those issues. And there will be some of those. Otherwise beta would be the same thing as definite release. Reagrds, -- 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
Fedora-Cloud-31-20200226.0 compose check report
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: Ideas and proposal for removing changelog and release fields from spec file
On Mon, 2020-02-24 at 18:13 +0100, Miro Hrončok wrote: > On 24. 02. 20 17:48, Pierre-Yves Chibon wrote: > > However, for the release field, we are struggling a little bit > > more, two options > > are more appealing to us: > > Can we please have a "git is the only source of truth" version of > this? I.e. > "Compute the release field from the number of commits since the last > version > change" in the document. It seem to only have one con (breaks if two > builds are > triggered from the same commit) which is the status quo. The <#commits>.<#builds> approach also doesn't address "snapshot" prereleases, i.e. which can't be dealt with having appending "~prereleasename" to the version, which is a second con (or a "pro" of the "try to emulate traditional manual release numbers" approach, if you will). Nils -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Include non-RPM content in buildroot
Hi Martin, I was quite busy lately so did not have time to reply. (Most of the time I'll speak for Rust ecosystem below) On Fri, Feb 21, 2020 at 4:06 PM Martin Sehnoutka wrote: > > Hi, > > before I write the proposal itself I just want to stress the fact that > it isn’t my intention to change the current packaging workflow and > definitely not the user experience. Also if you have C or Python > packages it would not affect your work at all (I’m not familiar with all > interpreted languages in Fedora, but I guess it is similar to Python and > therefore it is not affected by the problems I am going to describe). I disagree, Python has same registry (PyPI) as Rust does (crates.io) and. Of course, there are different problems in different ecosystems, but approach should be same to all. > > First of all, let me describe the problem I see in our Fedora ecosystem > with relation to Go and Rust language ecosystems. More specifically in > the relation between RPM buildroot and packages in these ecosystems. > Both of these languages follow the idea that packages should be small > and only have a limited set of features. Developers then use a lot of > these packages to write the final executable that is meant for end-users > [1]. Also both of these languages use static linking of the final > binaries meaning that Fedora users don’t install RPM packages of these > libraries as they are already baked inside of the binary [2]. Technically, we can do dynamic linking. The problem is that there is no stable ABI, so even rebuild of the same sources with different version of compiler can result into a different thing. I can't speak for Go, but in Rust the crate (aka library) can be used (compiled) with different features. So we would either need to produce libraries with all combinations of those features set or ship one big library with all of them included. That would mean, the dependency set will grow and most likely we won't save any space, or even worse, waste it. Until some amount of packages which are common on all systems, of course. By the way, Haskell has very similar problem, they just put hashes all over the place to ensure that all packages are rebuilt. > > The 1st problem is that if we want to build RPMs of the final > executables the way we do now, we need to package all these small > libraries into RPM even though they are just build dependencies and > users never install RPMs of these libraries. Many of these RPMs are > automatically generated from the upstream packages meaning that we don’t > do anything except for unpacking the upstream package (e.g. plain > tarball in case of crates.io) and then we package the same into RPM. > This process is unfortunately not fully automated and therefore requires > a certain amount of human effort. As others pointed out, we do audit licenses. But apart from that, we also do: 1) cargo build and cargo test to ensure that the crate actually works 2) Try to patch them to rely on latest version of crates 3) Add patches to use system versions of libraries (libcurl, oniguruma, libssh2, …) We did found many issues related to 32bit, endianess and even when bumping version of dependency, you can find that there is actual bug in the code of crate (https://github.com/budziq/rust-skeptic/pull/116#issuecomment-590009805) > > To sum up the previous paragraph, I don’t think it is necessary to > repackage upstream tarball into a downstream RPM. If it is automated, why do you think so? If you have different ecosystems, being able to check something across all ecosystems in the same way (aka using just rpm instead of pip, cargo, go, …). > > The 2nd problem is present only in the Rust ecosystem (as far as my > knowledge goes). Cargo, the official package manager for Rust, can > handle the scenario where an executable depends on a single library in > two different versions [3]. Dnf, on the other hand, will not install two > versions of the same RPM package. What we do now is, that we patch the > affected executables and libraries to only use the newest versions > everywhere. This is again an additional maintenance cost and we create > differences from upstream, because these patches are not necessarily > merged. See this as an example: > https://src.fedoraproject.org/rpms/rust-bstr/blob/master/f/rust-bstr.spec#_17 > https://github.com/BurntSushi/bstr/pull/23 As others, pointed out - we can (and we do) compat packages. What do you propose to do if there is, let's say vulnerability in the version some crate depends on and upstream is not responsibe? 95+% of our patches are merged into upstreams sooner or later (excluding dead upstreams). > > To sum up the 2nd problem: we are using dnf instead of the upstream > package manager to install dependencies. These two approaches can be > incompatible (and they are in case of Rust). That's not exactly true, we do mirror what Cargo does with RPM. And that works pretty well. > > The 3rd problem I see is that issues like this are
Re: Unannounced SONAME bump in cantor: libcantorlibs.so.23 → 24
Adam Williamson wrote: > If a library is not intended for use by other things, it should not be > installed to the well-known public shared library path. It should be > installed somewhere private to the application and the application > should handle including it in its own library path when appropriate. > > If it installs to /usr/lib64 then it's a public library, whether the > author intended that or not... Well, in practice, if there is no -devel package, the library cannot really be used publicly, so I am not convinced that moving it to a private path is really necessary in those cases. But in the case of Cantor, there is a -devel package and LabPlot uses it, and Rex Dieter has already fixed Cantor to prevent unannounced and uncoordinated soname bumps from happening again: https://src.fedoraproject.org/rpms/cantor/c/9939f4a0c2b3a098fa2a85a502e200ec25f85739?branch=master Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ideas and proposal for removing changelog and release fields from spec file
On Tue, 2020-02-25 at 17:45 +0100, Miro Hrončok wrote: > On 25. 02. 20 15:27, Fabio Valentini wrote: > > Side note: I've been meaning to propose dropping Epoch because of > > this > > "we don't care about upgrade path anymore", but I've not gotten > > around > > to do that yet We still need Epoch to have the ability to back-pedal on a (hypothetical) horribly broken version update in a stable release which wasn't caught during testing. > Unfortunately, that breaks rawhide users. Well, if we officially were to break with the upgrade path constraints, we'd have to document this. While we're at it, we should then document that Rawhide users should use "dnf distro-sync". Nils -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Include non-RPM content in buildroot
Le 2020-02-26 09:50, Martin Sehnoutka a écrit : Hi, Hi, Go package management: I know that Go has a package management now, but the question is if upstream communities are going to adopt it. Upstream communities won’t have any choice if they want their software to be trusted by third parties, because all the upstream "free" security checking provided by Google in its own registry relies on the new component model. Software security is hard. Security of huge piles of unmanaged third party bundled code is not economically feasible. That’s why Google moved to a formal component system, for the exact same reasons distros moved to formal packages 20+ years ago. (and it was all done in a NIH way Google side, they’re re-discovering all the packaging lessons distros learnt long ago one by one). Thanks for this email thread I also had few discussions off-line and it seems to me that there is a certain shift in the way people want to distribute their software. More specifically I could see more people focus on shipping their software in containers and trying to avoid RPM completely. You can see it because devs keep hoping for a free lunch. That does not exist in the real life. Real world software has maintenance and security issues. Managing those requires a finer grained component model than shoveling piles of unmanaged code in a container and hoping for the best. Upstreams that do not make the effort to manage the third party code they rely on, condemn themselves to obscurity, or to revenue capture by third parties that *will* transform their code in something manageable (typically, by breaking it in components that can be audited). Typically, Amazon, Google, Red Hat, etc. 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: State of FMN (FedMSG Notifications) and Replacement
On Wed, 26 Feb 2020 at 09:43, Fabio Valentini wrote: > On Wed, Feb 26, 2020 at 8:27 AM Clement Verna > wrote: > > > > Hi all, > > > > FMN (https://apps.fedoraproject.org/notifications) is currently one of > the main blocking point for dropping fedmsg in favour of fedora-messaging. > > FMN is quite important to the community and the composition of Fedora > because it gives emails and notifications on commits, composes, builds and > updates via email and other tools. > > > > However, the code base is written in Python 2.7 and not maintained > anymore. Currently the service has to run on a Fedora 28 system to continue > running. This causes multiple problems and concerns, and needs to be > addressed before the datacenter move in June. > > > > In order to start putting together a specification for a replacement, we > should try to look at the minimum requirements for a notification system. > For example the current system supports sending notifications to IRC, > emails and SSE (Server Sent Event), Can we live without SSE ? Can we live > without IRC ? Do we need it to monitor everything it does currently or just > a subset of items that the community has found useful. > > Is that the service that sends IRC notifications from fedora-notif? > Yes It's a bit like drinking from the firehose, but I find it incredibly > useful to get notifications with URLs for whatever's happening to my > packages. So it would be a shame if that were to disappear ... (or > replaced by E-Mails, RIP my inbox) > Yes I also find IRC notifications more useful than the emails, maybe we can prioritize the IRC notifications then ? Although I am sure we will have advocate for emails only :-) > > Fabio > > > Let's use this thread to brainstorm ideas on what we need. > > > > Thanks all > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: State of FMN (FedMSG Notifications) and Replacement
On Wed, 26 Feb 2020 at 09:17, Adam Williamson wrote: > On Wed, 2020-02-26 at 08:26 +0100, Clement Verna wrote: > > Hi all, > > > > FMN (https://apps.fedoraproject.org/notifications) is currently one of > the > > main blocking point for dropping fedmsg in favour of fedora-messaging. > > FMN is quite important to the community and the composition of Fedora > > because it gives emails and notifications on commits, composes, builds > and > > updates via email and other tools. > > > > However, the code base is written in Python 2.7 and not maintained > anymore. > > Currently the service has to run on a Fedora 28 system to continue > running. > > This causes multiple problems and concerns, and needs to be addressed > > before the datacenter move in June. > > > > In order to start putting together a specification for a replacement, we > > should try to look at the minimum requirements for a notification system. > > For example the current system supports sending notifications to IRC, > > emails and SSE (Server Sent Event), Can we live without SSE ? Can we live > > without IRC ? Do we need it to monitor everything it does currently or > just > > a subset of items that the community has found useful. > > > > Let's use this thread to brainstorm ideas on what we need. > > I'd note that a key feature of FMN is that it provides human-readable > summaries of messages. For fedmsg this is achieved through the fedmsg > metadata system, and the Fedora providers for it: > > https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/ > > for fedora-messaging, the intended way to do approximately the same > thing is with message schemas: > > https://fedora-messaging.readthedocs.io/en/latest/messages.html#schema > > as part of modernizing FMN and rewriting it on fedora-messaging, we > might well need to get fedora-messaging schema coverage up to a similar > level as we have fedmsg meta coverage. We may want to see if we can > come up with an automated or semi-automated process for converting > fedmsg meta providers to fedora-messaging schemas, even... > Yes this also part of this thread to identify which messages we really care about, so that we can focus on providing schema for these first. Messages that are a little bit less important would come later. > -- > 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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New font package
Le 2020-02-26 08:51, Iñaki Ucar a écrit : Hi, Welcome ! I've submitted a new font package for review [1], but I have 0 experience with fonts (I need it to unbundle it from [2]), and I found the documentation about font packages a little bit outdated. It's a pretty simple font (OFL, single family with a couple of styles), We were aware of this, so it’s been rewritten, and FPC approved the rewrite two weeks ago. https://pagure.io/packaging-committee/issue/935 It’s not published yet, FPC is proofing the text, but you can already read the pre-proofed version here using asciidoctor.js https://pagure.io/packaging-committee/pull-request/934 APPLICABILITY For a very simple font family like NewsCycle most of the twists of the document won’t apply, you just need to use the new macros available in fonts-?rpm-macros. fonts-rpm-templates in F32+ provides example spec templates. Do read the parts on how to depend on font packages from non font packages, however, you will use them. That will simplify your spec quite a bit, and generate the fonts metainfo file for you (I see you wrote one by hand, you can keep it if you like it, apologies for being slow to update guidelines, and the needless manual work). Once you’ve updated your spec to the new guidelines I will review it and help you wrap it up. TARGET RELEASES The new font macros are available in F32, F33, and currently been pushed to F31. The aim is to have all new packages use them for F31+, and convert existing packages before F34 (at that point compatibility glue for previous macros will be dropped). That will get us a single packaging target for all supported Fedora releases soonish. EL8 & EPEL There is no plan short term to enable them for EPEL8, because the redhat-rpm-config version here is too old and missing some common code. However, an EL8 redhat-rpm-config refresh has already been requested to @rh engineering by another SIG https://bugzilla.redhat.com/show_bug.cgi?id=1774139 It would not take much to complete this refresh with the bits used by out fonts macros, should anyone be interested (both packaging guidelines depend on pretty much the same common code, there are a couple fonts-specific commits in redhat-rpm-config Go does not need, but they are marginal) I won’t drive EPEL-ing myself, but I will help anyone willing to take the subject. 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: Downgrading from rawhide
W dniu 25.02.2020 o 16:09, Christophe de Dinechin pisze: > Is there any documented procedure to safely downgrade from rawhide > to the latest release? > > I tried > > # dnf update --releasever=32 fedora-release > # dnf distro-sync --allowerasing --skip-broken > > Does something like that have any chance of working? At first sight, > it seems to be somewhat successful. I moved from rawhide to F24 few years ago [1]. Took some time but was doable. There can be some extra steps needed than just those two you listed. 1. https://marcin.juszkiewicz.com.pl/2016/09/12/downgrading-fedora-rawhide-fedora-24/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaning most of the ancient Gnome 1 stack
Hi all,
I've been looking after the ancient Gnome 1 library stack for the last
decade as I had a local use for the libraries. That is no longer the
case so I'm planning to orphan the following packages, none of which
appear to be used by anything else in Fedora (Rawhide):
* libglade
* gnome-libs
* ORBit
* imlib
* libxml
* libpng10
(tested using:
dnf repoquery --repo=rawhide{,-source} --whatrequires XXX
)
I expect that nobody will pick them up and they'll get retired along
with other orphaned packages in due course. If anyone actually has an
interest in these packages, let me know and I'll transfer them.
I'll still take care of the bottom two packages in the stack as they
still have several users in Rawhide:
* gtk+
* glib
Regards, 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: Include non-RPM content in buildroot
Hi, thank you all for your input! I have few notes: Review process: I don't think that the review process is a problem. It is independent of the file format we use. I mean we can have regular review process and store the package in a tarball as well as we do it with RPM. Go package management: I know that Go has a package management now, but the question is if upstream communities are going to adopt it. Storage requirements: Regarding the amount of packages, of course I don't want to clone the whole registry, I just want to do the same we already do, but without RPM. -compat packages for Rust: I, personally, don't like the proposed solution because it requires a lot of manual work and my goal is to remove as much manual work as possible. mock: I am aware that we don't have Internet access during RPM build, but as I said above, we can do the same with tarball and RPM. Thanks for this email thread I also had few discussions off-line and it seems to me that there is a certain shift in the way people want to distribute their software. More specifically I could see more people focus on shipping their software in containers and trying to avoid RPM completely. Regards, Martin On 2/21/20 3:57 PM, Martin Sehnoutka wrote: Hi, before I write the proposal itself I just want to stress the fact that it isn’t my intention to change the current packaging workflow and definitely not the user experience. Also if you have C or Python packages it would not affect your work at all (I’m not familiar with all interpreted languages in Fedora, but I guess it is similar to Python and therefore it is not affected by the problems I am going to describe). First of all, let me describe the problem I see in our Fedora ecosystem with relation to Go and Rust language ecosystems. More specifically in the relation between RPM buildroot and packages in these ecosystems. Both of these languages follow the idea that packages should be small and only have a limited set of features. Developers then use a lot of these packages to write the final executable that is meant for end-users [1]. Also both of these languages use static linking of the final binaries meaning that Fedora users don’t install RPM packages of these libraries as they are already baked inside of the binary [2]. The 1st problem is that if we want to build RPMs of the final executables the way we do now, we need to package all these small libraries into RPM even though they are just build dependencies and users never install RPMs of these libraries. Many of these RPMs are automatically generated from the upstream packages meaning that we don’t do anything except for unpacking the upstream package (e.g. plain tarball in case of crates.io) and then we package the same into RPM. This process is unfortunately not fully automated and therefore requires a certain amount of human effort. To sum up the previous paragraph, I don’t think it is necessary to repackage upstream tarball into a downstream RPM. The 2nd problem is present only in the Rust ecosystem (as far as my knowledge goes). Cargo, the official package manager for Rust, can handle the scenario where an executable depends on a single library in two different versions [3]. Dnf, on the other hand, will not install two versions of the same RPM package. What we do now is, that we patch the affected executables and libraries to only use the newest versions everywhere. This is again an additional maintenance cost and we create differences from upstream, because these patches are not necessarily merged. See this as an example: https://src.fedoraproject.org/rpms/rust-bstr/blob/master/f/rust-bstr.spec#_17 https://github.com/BurntSushi/bstr/pull/23 To sum up the 2nd problem: we are using dnf instead of the upstream package manager to install dependencies. These two approaches can be incompatible (and they are in case of Rust). The 3rd problem I see is that issues like this are not going away, they are only going to get worse as other ecosystems emerge. e.g. if the Swift language became popular (for Linux development) it would again have it’s own package manager and probably its own set of issues in relation to our build system. (I mention Swift specifically because it is a compiled language that have stable ABI only for std, other libraries are statically linked) Now, I’d like to point out that Go and Rust packaging works well in Fedora due to the enormous effort of certain people and I very much admire the work they do. But on the other hand I’m afraid where the ecosystem would go without them. This is where we get to the situation in the enterprise derivatives, specifically RHEL and CentOS. Their solution to this problem is not to package all libraries separately but to bundle all libraries directly into source RPMs of each executable. So the bundling is not present only on the binary file level, but also on the source RPM level. Go went
Re: State of FMN (FedMSG Notifications) and Replacement
On Wed, Feb 26, 2020 at 8:27 AM Clement Verna wrote: > > Hi all, > > FMN (https://apps.fedoraproject.org/notifications) is currently one of the > main blocking point for dropping fedmsg in favour of fedora-messaging. > FMN is quite important to the community and the composition of Fedora because > it gives emails and notifications on commits, composes, builds and updates > via email and other tools. > > However, the code base is written in Python 2.7 and not maintained anymore. > Currently the service has to run on a Fedora 28 system to continue running. > This causes multiple problems and concerns, and needs to be addressed before > the datacenter move in June. > > In order to start putting together a specification for a replacement, we > should try to look at the minimum requirements for a notification system. For > example the current system supports sending notifications to IRC, emails and > SSE (Server Sent Event), Can we live without SSE ? Can we live without IRC ? > Do we need it to monitor everything it does currently or just a subset of > items that the community has found useful. Is that the service that sends IRC notifications from fedora-notif? It's a bit like drinking from the firehose, but I find it incredibly useful to get notifications with URLs for whatever's happening to my packages. So it would be a shame if that were to disappear ... (or replaced by E-Mails, RIP my inbox) Fabio > Let's use this thread to brainstorm ideas on what we need. > > Thanks all > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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
[Bug 1807263] perl-Getopt-Long-Descriptive-0.105 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1807263 --- Comment #2 from Fedora Update System --- FEDORA-2020-f72d6a2647 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-f72d6a2647 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1807263] perl-Getopt-Long-Descriptive-0.105 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1807263 Paul Howarth changed: What|Removed |Added Status|NEW |MODIFIED Fixed In Version||perl-Getopt-Long-Descriptiv ||e-0.105-1.fc33 Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: State of FMN (FedMSG Notifications) and Replacement
On Wed, 2020-02-26 at 08:26 +0100, Clement Verna wrote: > Hi all, > > FMN (https://apps.fedoraproject.org/notifications) is currently one of the > main blocking point for dropping fedmsg in favour of fedora-messaging. > FMN is quite important to the community and the composition of Fedora > because it gives emails and notifications on commits, composes, builds and > updates via email and other tools. > > However, the code base is written in Python 2.7 and not maintained anymore. > Currently the service has to run on a Fedora 28 system to continue running. > This causes multiple problems and concerns, and needs to be addressed > before the datacenter move in June. > > In order to start putting together a specification for a replacement, we > should try to look at the minimum requirements for a notification system. > For example the current system supports sending notifications to IRC, > emails and SSE (Server Sent Event), Can we live without SSE ? Can we live > without IRC ? Do we need it to monitor everything it does currently or just > a subset of items that the community has found useful. > > Let's use this thread to brainstorm ideas on what we need. I'd note that a key feature of FMN is that it provides human-readable summaries of messages. For fedmsg this is achieved through the fedmsg metadata system, and the Fedora providers for it: https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/ for fedora-messaging, the intended way to do approximately the same thing is with message schemas: https://fedora-messaging.readthedocs.io/en/latest/messages.html#schema as part of modernizing FMN and rewriting it on fedora-messaging, we might well need to get fedora-messaging schema coverage up to a similar level as we have fedmsg meta coverage. We may want to see if we can come up with an automated or semi-automated process for converting fedmsg meta providers to fedora-messaging schemas, even... -- 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: Include non-RPM content in buildroot
On Tue, Feb 25, 2020 22:26:24 -0500, Randy Barlow wrote: > On 2/25/20 3:12 PM, Ankur Sinha wrote: > > Basically, packages do not pass review merely because they use good > > licenses. > > Note that I just said that I thought it was the primary purpose, not > the only purpose. Sure, but I'm arguing that this isn't correct. Maybe it's to do with how I interpret the phrase: "the primary". To me (so it could be very wrong) "the primary purpose" also implies that the other purposes are "secondary" and that isn't true. So, I would be happier with saying "a primary purpose" instead of "the primary purpose". Sorry, got a bit pedantic with language here. :/ -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
