date:20211006

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2010107
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Schedule for Thursday's FPC Meeting (2021-10-07 16:00 UTC)

2021-10-06 Thread James Antill

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2021-10-07 16:00 UTC in #fedora-meeting-1 on
irc.libera.chat.

 Local time information (via. uitime):

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

 Links to all tickets below can be found at: 

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

= Followup Actions =

#topic #pr-814
 * mhroncok
   talk to authors again, having a working example might help a lot

= Followup Issues =

#topic #886 Enable BRP for detecting RPATH 
.fpc 886
https://pagure.io/packaging-committee/issue/886

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

#topic #1058 How to handle %lang files in package owned directories? .fpc 1058
https://pagure.io/packaging-committee/issue/1058

= Followup Pull Requests =

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

#topic #pr-1045 WIP: Add discussion of macro names beginning with underscores.
https://pagure.io/packaging-committee/pull-request/1045

#topic #pr-#1046 Improve separate test suite sourcing instructions 
https://pagure.io/packaging-committee/pull-request/1046

#topic #pr-1071 Overhaul the RPATH section of the guidelines.
https://pagure.io/packaging-committee/pull-request/1071

#topic #pr-1074 Require deleting unused bundled libraries during %prep
https://pagure.io/packaging-committee/pull-request/1074

#topic #pr-1077 Introduce %sysusers_create
https://pagure.io/packaging-committee/pull-request/1077

= New Issues =

#topic #1099 Contradicting sections regarding duplicate files 
.fpc 1099
https://pagure.io/packaging-committee/issue/1099

#topic #1107 Soft-static allocation of gids for "tcb passwd shadowing" 
.fpc 1107
https://pagure.io/packaging-committee/issue/1107

= New Pull Requests =

#topic #pr-#1094 Add documentation for build constraints macro 
https://pagure.io/packaging-committee/pull-request/1094

#topic #pr-#1097 Use caret in Obsoletes to simplify
https://pagure.io/packaging-committee/pull-request/1097

= Open Floor = 

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

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

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * Bring it up at the end of the meeting, during the open floor topic. Note
    that added topics may be deferred until the following meeting.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F34 Cloud Amazon AMIs unbootable after updates

2021-10-06 Thread Christopher

Running on EC2, it's kinda hard to get good information from a system
that won't boot. The machine won't boot to the point of being able to
capture the system log, and the screenshot of the instance doesn't
appear to be super helpful: https://imgur.com/a/4PWcRSg

On Wed, Oct 6, 2021 at 4:42 PM Joe Doss  wrote:
>
> On 10/6/21 3:18 PM, Christopher wrote:
> > Hi,
> >
> > Has anybody else noticed that the Amazon Public Cloud images for F34
> > (https://alt.fedoraproject.org/cloud/) no longer boot after the latest
> > updates?
> >
> > I had an instance that I've been keeping up-to-date with dnf system
> > upgrades and is now on F34, which is now unbootable after recent
> > updates within the last week. So I tried to create a new instance
> > using a newer base image at https://alt.fedoraproject.org/cloud/, and
> > that one is also now unbootable after doing a routine dnf update.
> >
> > Has anybody else seen this?
> >
> > Does anybody know which package update caused it? (I saw some
> > grub-related updates, but not sure if they are to blame)
> >
> > Does anybody know how to fix a currently broken instance and can share
> > their solution?
>
> Is there anything on the console log when you reboot it after the
> updates? If you can share the log that would be helpful.
>
> Joe
>
>
>
>
> --
> Joe Doss
> j...@solidadmin.com
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Get BR: %{py3_dist } working on EPEL7

2021-10-06 Thread Orion Poplawski

Would it be possible to get BuildRequires: %{py3_dist NAME} working on 
EPEL7?  At first I thought it was sufficient for epel-rpm-macros to 
require python3-rpm-macros, but now I think we may need to override the 
definition of py3_dist.  In fedora it uses %python3_pkgversion, in RHEL7 
it uses %python3_version, and in RHEL8 "python3dist".


But %python3_version requires python to evaluate.

Presumably we're using %python3_version to allow for multiple python 
versions, but I think we've given up on that in single spec files.


Thoughts?

--
Orion Poplawski
he/him/his - surely the least important thing about me
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
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: To buildroot, or not to buildroot

2021-10-06 Thread Neal Gompa

On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson  wrote:
>
> *this is worth a discussion in todays EPEL Steering Committee Meeting*
>
> It sounds like the epel9-next is going to startup by building against the CS 
> buildroot.  Changing it at this time would cause a delay.
>
> Thus we need to write some "verify build deps are released" checker.  I have 
> an idea of how to do this, so I'm willing to volunteer to write and run 
> something.
>
> But, it would be good to have some discussion to determine if we want to keep 
> using the CS buildroot for epel9-next, always.  Or if we want to use it just 
> as a bootstrap mechanism, and then switch to building just off the available 
> CentOS Stream repos at some point.
>
> Thoughts?
> Should we always use buildroot?  Or just keep up until we're fairly stable?
>

We should only use the buildroot repo for as long as we need to. The
*sooner* we can switch to the published content, the better.



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

Re: RISC-V -- are we ready for more, and what do we need to do it?

2021-10-06 Thread Neal Gompa

On Wed, Oct 6, 2021 at 1:50 PM Josh Stone  wrote:
>
> On 10/4/21 12:12 PM, Neal Gompa wrote:
> > On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi  wrote:
> >> * How good is emulation support
> >
> > The lack of real hardware for RISC-V has made it so almost everyone is
> > working with emulation. It's not realistic right now to work with real
> > hardware.
> >
> >> * What would it take to keep up with the other arches? Is that possible?
> >
> > The real hardware options do not have the performance to keep up with
> > the other architectures.
>
> Is it really so slow that emulation is preferable?
>

In my opinion, yes. There's a dearth of so-called "server-class"
hardware, which have such useful characteristics like "large amounts
of RAM", "decent memory cache", "fast I/O", "PCIe lanes", and so on.

The development boards typically are very I/O constrained and have
limited amounts of RAM, making them less useful than emulation for
doing builds.


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

Re: RISC-V -- are we ready for more, and what do we need to do it?

On Wed, Oct 06, 2021 at 10:50:02AM -0700, Josh Stone wrote:
> On 10/4/21 12:12 PM, Neal Gompa wrote:
> > On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi  wrote:
> >> * How good is emulation support
> > 
> > The lack of real hardware for RISC-V has made it so almost everyone is
> > working with emulation. It's not realistic right now to work with real
> > hardware.
> > 
> >> * What would it take to keep up with the other arches? Is that possible?
> > 
> > The real hardware options do not have the performance to keep up with
> > the other architectures.
> 
> Is it really so slow that emulation is preferable?

Actually we prefer the real hardware over qemu for the larger builds.

As the other reply said the main concern is the lack of server-class
hardware.  We could build something with a Pi KVM hat, but that's not
a neat integrated solution.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F34 Cloud Amazon AMIs unbootable after updates

2021-10-06 Thread Joe Doss


On 10/6/21 3:18 PM, Christopher wrote:

Hi,

Has anybody else noticed that the Amazon Public Cloud images for F34
(https://alt.fedoraproject.org/cloud/) no longer boot after the latest
updates?

I had an instance that I've been keeping up-to-date with dnf system
upgrades and is now on F34, which is now unbootable after recent
updates within the last week. So I tried to create a new instance
using a newer base image at https://alt.fedoraproject.org/cloud/, and
that one is also now unbootable after doing a routine dnf update.

Has anybody else seen this?

Does anybody know which package update caused it? (I saw some
grub-related updates, but not sure if they are to blame)

Does anybody know how to fix a currently broken instance and can share
their solution?


Is there anything on the console log when you reboot it after the 
updates? If you can share the log that would be helpful.


Joe




--
Joe Doss
j...@solidadmin.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F34 Cloud Amazon AMIs unbootable after updates

2021-10-06 Thread Christopher

Hi,

Has anybody else noticed that the Amazon Public Cloud images for F34
(https://alt.fedoraproject.org/cloud/) no longer boot after the latest
updates?

I had an instance that I've been keeping up-to-date with dnf system
upgrades and is now on F34, which is now unbootable after recent
updates within the last week. So I tried to create a new instance
using a newer base image at https://alt.fedoraproject.org/cloud/, and
that one is also now unbootable after doing a routine dnf update.

Has anybody else seen this?

Does anybody know which package update caused it? (I saw some
grub-related updates, but not sure if they are to blame)

Does anybody know how to fix a currently broken instance and can share
their solution?


Thanks,
Christopher
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2010107] Provide perl-Mail-RFC822-Address for EPEL-8

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

Stefan Bluhm  changed:

   What|Removed |Added

   Assignee|andr...@bawue.net   |fedoraproject.org@bluhm-de.
   ||com
 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2010107
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Onboarding package

2021-10-06 Thread Otto Urpelainen


Vít Ondruch kirjoitti 6.10.2021 klo 10.51:


Dne 06. 10. 21 v 7:35 Otto Urpelainen napsal(a):

Stephen Snow kirjoitti 5.10.2021 klo 15.39:

we were initially discussing that it could be useful to have some
package one can experiment with without being too much worried about
the
result.

However, discussing this back and forth, we figured that it might
also
where new coming package maintainer could gradually gain experience
with
the packaging workflows. So the simplest tasks could be:

1) Add changelog entry into onboarding package and open PR with the
change. This would not require too many privileges. Alternatively
this
current Fedora contributors might be interested to send such PR ;)


I like this approach, but I was also thinking of a small tutorial/app
to actually package a piece of software as required, going through the
various steps but be a "fake" package that is only used to teach and
test with. This app could record the FAS user ID and assign a badge to
it once they complete the tutorial successfully. Sort of a base
starting point for all new packagersd that give both them some
confidence going in and the sponsors some confidence too about the
level of the new committers capabilities.


Well, in the Quick Docs, we already have Creating RPM packages [1]. It 
has subpage "Publishing your software on Copr", which somehow covers 
the publishing aspect. But honestly, when I was starting out, I spent 
some time with those instructions, but could not understand them or 
complete the tutorials. So one thing would be to revisit these 
instructions and make the better — there is a task about moving them 
over to Package Maintainer Docs [2], it was in progress at some point, 
but apparently stalled now. After that, improvement could happen.


About every packager publishing their own test package, in Copr that 
can be done for sure. If it is deemed too far from the official Fedora 
repositories, the perhaps it could be done in staging. I have never 
really used it, I cannot say if that is a good idea or not.


A similar but different idea I have is to create a "Fedora Packaging 
Guidelines Web Course" that you can complete by yourself. It could be 
implemented as a Git repository. For each entry in the the Review 
Guidelines [3], there would be a directory with a specfile and a srpm. 
For simplicity, we could first implement cases which fedora-review can 
check automatically. The student's assignment would be to run 
fedora-review on the specfile, find the error it gives, refer to the 
Packaging Guidelines to figure out how to fix it, modify the specfile 
as needed and run fedora-review again to check their answer. The 
assignment is completed when fedora-review does not complain any more.


Later, the course could be expanded also to cases where there is no 
automated check available, either by involving a mentor, or simply by 
adding a SOLUTION file.


Awarding a badge for completing this course would be a good idea, if a 
technical solution can be found.


I see this course as complementary to Vít's original proposal about 
the onboarding package. The orboarding package tasks are about 
learning the build system, certainly a required skill for packages. 
The course is about learning the Guidelines. Currently the recommended 
method to do that is to submit inofficial reviews to live Review 
Requests. That has the advantage of exposing the applicant to real 
packages with real problems, but 1) has no guarantee of producing an 
effective learning path, the package that is picked may well be a very 
tricky case and thus unsuitable for starting out and 2) is 
psychologically unsafe, because a total newcomer must participate in 
discussion of two experts who are actually trying to get a package 
into Fedora, not educating the packagers.



Just FTR, I like these ideas. Nevertheless, as with every idea, they 
need to be implemented and maintained. Therefore, from the experience, I 
think that onboarding package could survive longer, because it 
(hopefully) needs less maintenance.


It is a valid concern. The onboarding package is just a single package, 
whereas if the would be N assignments, there would be also N specfiles 
to maintain as the guidelines change. Starting from the sections that 
are the least probable to change would help.


Also note that I did not intend to propose to do something like this 
instead of the onboarding package, which is a good idea. Rather, this 
could be done in addition to that, and serves a different need.


If there is another way, requiring less maintenance work, that allows 
learning how to apply the Packaging Guidelines, even better. It is just 
that the the current method of "just read the Guidelines" is too 
theoretical, and "comment on live reviews" is too hands-on.


Otto
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:

[EPEL-devel] Re: To buildroot, or not to buildroot

2021-10-06 Thread Troy Dawson

*this is worth a discussion in todays EPEL Steering Committee Meeting*

It sounds like the epel9-next is going to startup by building against the
CS buildroot.  Changing it at this time would cause a delay.

Thus we need to write some "verify build deps are released" checker.  I
have an idea of how to do this, so I'm willing to volunteer to write and
run something.

But, it would be good to have some discussion to determine if we want to
keep using the CS buildroot for epel9-next, always.  Or if we want to use
it just as a bootstrap mechanism, and then switch to building just off the
available CentOS Stream repos at some point.

Thoughts?
Should we always use buildroot?  Or just keep up until we're fairly stable?

Troy
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RISC-V -- are we ready for more, and what do we need to do it?

2021-10-06 Thread Matthew Miller

On Wed, Oct 06, 2021 at 10:50:02AM -0700, Josh Stone wrote:
> > The real hardware options do not have the performance to keep up with
> > the other architectures.
> Is it really so slow that emulation is preferable?

Speed isn't the only concern -- in order to be reasonably manageable, we
need this to be server-class hardware. Or at the very least, rackmount
hardware. Dev boards -- even fast ones -- don't help much.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [CoreOS] Fedora CoreOS Community Video Meeting 2021-10-06

2021-10-06 Thread Dusty Mabe



On 10/5/21 5:53 PM, Dusty Mabe wrote:
> Hi All,
> 
> Tomorrow we will be holding a video meeting for the Fedora CoreOS community.
> 
> Harshal Patil will be joining us to give a brief overview of how Fedora 
> CoreOS is used
> for the e2e node tests in upstream Kubernetes. 
> https://github.com/coreos/fedora-coreos-tracker/issues/984
> 
> We'll also be discussing any meeting tickets and possibly revisit our list of 
> high level
> issues.
> 
> 
> Time: 16:30 UTC (same as normal) on Wednesday October 6th
> Location: https://meet.google.com/cgh-oxhd-axg (will be recorded)
> Agenda/Notes: https://hackmd.io/vMWlKGH5TAOsLKYiqce61Q


Thanks to everyone who attended! Here is a link to the meeting recording:

https://dustymabe.fedorapeople.org/meetings/2021-10-06_FCOS-Community-Meeting.mp4
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Onboarding package

2021-10-06 Thread Stephen Snow


On Wed, 2021-10-06 at 18:39 +0200, Vít Ondruch wrote:

--snip--
> So it 
> seems we are in agreement with the `dummy-onboarding-` prefix 
No, it should be something more appropriate like `entry-level-tutor-`
or something equally as nuetrally offensive. Dummy is a very negative
word with no value of positive connotations in the English language.


regards,
Stephen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RISC-V -- are we ready for more, and what do we need to do it?

2021-10-06 Thread Josh Stone

On 10/4/21 12:12 PM, Neal Gompa wrote:
> On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi  wrote:
>> * How good is emulation support
> 
> The lack of real hardware for RISC-V has made it so almost everyone is
> working with emulation. It's not realistic right now to work with real
> hardware.
> 
>> * What would it take to keep up with the other arches? Is that possible?
> 
> The real hardware options do not have the performance to keep up with
> the other architectures.

Is it really so slow that emulation is preferable?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2011114] perl-Encode-3.13 is available

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



--- Comment #5 from Fedora Update System  ---
FEDORA-2021-c6a9bad3aa has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-c6a9bad3aa`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-c6a9bad3aa

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=204
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2008958] CVE-2021-38562 rt: User enumeration through a timing side-channel attack [fedora-all]

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



--- Comment #11 from Fedora Update System  ---
FEDORA-2021-05feb8a8b2 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-05feb8a8b2`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-05feb8a8b2

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2008958
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Python 3.10 in Fedora 36+: sysconfig's "posix_prefix" install scheme now has /usr/local

2021-10-06 Thread Miro Hrončok


On 05. 10. 21 16:02, Miro Hrončok wrote:

Hello Pythonistas,
since Fedora 27, we have been patching Python to install packages to 
/usr/local/lib(64)/python3.X/site-packages if not in rpmbuild:


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

The patch was a pragmatic hack in the distutils module that proved to be 
working quite reliably over the years. Unfortunately, the distutils module is 
deprecated and is going to be removed from Python 3.12:


https://www.python.org/dev/peps/pep-0632/

Working with the upstreams of setuptools, pip, and Python, as well as other 
Linux distros Python maintainers (Arch, Debian), we have now changed the way 
the patch works to patch the sysconfig module instead, changing the 
posix_prefix install scheme to use /usr/local paths.


See https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134/104 
for details.


This change is aligned with the upstream plan for Python 3.11 to offer 
distributors a way to supply their installation schemes to sysconfig:


https://bugs.python.org/issue43976

Nothing should change for Fedora packages. If you encounter problems, do let us 
know and we'll try to help solve them.


Software that reads the posix_prefix install_scheme on runtime to figure out 
where to install stuff should behave the right way by default. OTOH software 
that reads it to figure out where to load stuff from might need changes, see 
e.g. the change we did in dnf: 
https://github.com/rpm-software-management/dnf/pull/1782


Relevant commit: https://src.fedoraproject.org/rpms/python3.10/c/47935cfb9870


This change apparently breaks virtualenv and pipenv:

https://bugzilla.redhat.com/2011455 (virtualenv)

https://bugzilla.redhat.com/2011475 (pipenv)


I'll try to fix that ASAP and if I am unable, will consider temporarily 
reverting the change.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Joining the packaging group to become a co-maintainer - Was: Re: co/lead-maintainer sought: python-mailmerge (python)

2021-10-06 Thread Jerry James

On Wed, Oct 6, 2021 at 10:47 AM Brian (bex) Exelbierd
 wrote:
> It appears that you are not yet a packager.  I don't see a set of guidelines 
> for adding you as a co-maintainer in this case.  I have changed the subject 
> of the email in hopes we can get an answer.  In the meantime, consider 
> submitting an update via PR so that Onuralp can review it.


See 
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/#become_a_co_maintainer
for a description of how that works.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2011114] perl-Encode-3.13 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2021-a461198449 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-a461198449`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-a461198449

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=204
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2008958] CVE-2021-38562 rt: User enumeration through a timing side-channel attack [fedora-all]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #10 from Fedora Update System  ---
FEDORA-2021-7ddc28a14b has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-7ddc28a14b`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-7ddc28a14b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2008958
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Joining the packaging group to become a co-maintainer - Was: Re: co/lead-maintainer sought: python-mailmerge (python)

2021-10-06 Thread Brian (bex) Exelbierd

On Wed, Oct 6, 2021 at 5:37 PM TItouan Bénard  wrote:

> Le lundi 04 octobre 2021 à 11:54 +0200, Brian (bex) Exelbierd a écrit :
>
>
>
> On Sun, Oct 3, 2021 at 6:48 PM TItouan Bénard  wrote:
>
> Hi,
>
> I want to help you
>
>
> Sweet.  Onuralp replied via direct mail and I have added them to the repo
> as well.  Can you work with them (or agree on any other organization)
> around the upgrades indicated in
> https://bugzilla.redhat.com/show_bug.cgi?id=1937525
>
> also, send me your FAS id so I can add you to the repo.
>
>
> My FAS id is itotutona
>

It appears that you are not yet a packager.  I don't see a set of
guidelines for adding you as a co-maintainer in this case.  I have changed
the subject of the email in hopes we can get an answer.  In the meantime,
consider submitting an update via PR so that Onuralp can review it.

Thank you.

regards,

bex



>
>
> Once the upgrades are good I can hand off the repo to one of you all as
> main maintainer :)
>
> Thank you.
>
> regards,
>
> bex
>
>
>
>
>
> Thanks
>
> Titouan
>
> Le dimanche 03 octobre 2021 à 13:34 +0300, Onuralp SEZER a écrit :
>
> Hello Brian, I would like to step-up.
>
> Thank you
> Regards
>
>
> Onuralp S.
>
> On Sun, Oct 3, 2021 at 11:36 AM Brian (bex) Exelbierd 
> wrote:
>
> Hi,
>
> Want to play with python packaging?  I am still looking for some
> assistance here :)
>
> Thank you.
>
> regards,
>
> bex
>
> On Wed, May 5, 2021 at 12:01 PM Brian (bex) Exelbierd 
> wrote:
>
> Hi,
>
> I added python-mailmerge to Fedora Linux as it was super important to
> large parts of my work as FCAIC.  In my current $dayjob I use it less
> frequently, though I know of colleagues who still depend on it.
>
> I'd love to find a maintainer to help me with it.  There is a new
> release pending, which I suspect will just be "build the rpm with new
> code; test it; ship it" level effort.  I am happy to hand the whole
> thing off to someone or to work with you.
>
> Thank you.
>
> regards,
>
> bex
> --
> Did this email arrive after work for you?  Stop reading it and enjoy
> some work/life balance.
>
> Brian "bex" Exelbierd (he/him/his)
> Community Business Owner, RHEL Product Management
> @bexelbie | http://www.winglemeyer.org
> bexel...@redhat.com
>
>
>
> --
> Did this email arrive after work for you?  Stop reading it and enjoy some
> work/life balance.
>
> Brian "bex" Exelbierd (he/him/his)
> Community Business Owner, RHEL Product Management
> @bexelbie | http://www.winglemeyer.org
> bexel...@redhat.com
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
>

Re: Onboarding package

Dne 06. 10. 21 v 15:08 Zbigniew Jędrzejewski-Szmek napsal(a):

On Wed, Oct 06, 2021 at 11:20:47AM +0200, Vít Ondruch wrote:

Dne 06. 10. 21 v 9:44 Zbigniew Jędrzejewski-Szmek napsal(a):

On Wed, Oct 06, 2021 at 09:39:46AM +0200, Vít Ondruch wrote:

Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a):

On Tue, 5 Oct 2021 at 11:28, Matthew Miller wrote:

On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote:

Is this really necessary?

Yes. Because anyone can add something like this:
%post
rm -rf /

And it will destroy the installed system or even the hardware.

Yeah, but... that's not going get through the PR process? In fact, that
specific thing should fail in CI before a human gets to it even.

Overall, we put a lot of trust in maintainers. I don't see this _particular_
route as a likely one for violating that trust.

I think part of the problem is that I don't think the proposal has
enough flesh on its bones for people not to see it causing all kinds
of problems somewhere. Or vice versa seeing not enough to see it being
worthwhile for a beginner. [For many a developer, PR's aren't that
interesting to most developers and not what they think about when
looking at packaging. Running fedpkg and making a spec file work on my
system and through the complicated koji+bodhi+mbs+.. stack is real
packaging.] So we need a real proposal with an end to end idea of what
is being done, what is to be learned, and how it is to be 'watched' by
real developers to make sure people are learning things.

This was proposed in the "release early, release often" spirit. So I
am glad for the generally positive feedback for this idea and I also
appreciate the concerns which were risen.

And as I said, this targets the newcomers, so start with the PR is
probably the right thing to do. But even "start with PR" has more
degrees of freedom, e.g. should the contributors modify the
changelog manually or should the `%autorelease` / `%autochangelog`
be used as proposed by Matt? Maybe this could be two scenarios after
all. But it is hard to judge where the line is between being useful
to learn something and being tedious, boring, unattractive or
discouraging.

I'd very much lean on the side of %autorelease/%autochangelog.
That workflow isn't perfect yet, but it's certainly the feature, and
in general, newcomers should learn the new workflows.
(There's also the issue raised by Matt that with traditional
%changelog pretty much each and every parallel pull request would
conflict.)

I have put together very naive concept here:

https://fedorapeople.org/cgit/vondruch/public_git/dummy-onboarding-contributors-pr.git/

master → main

I just went with defaults.

Why does the package have "-pr" in the name? We want people to
contribute to it through PRs, but I don't think this needs to be part
of the name.

Remember that my initial proposal consisted at least from two scenarios.
Submitting (as simple as possible) PR was just the first one. So it
seems we are in agreement with the `dummy-onboarding-` prefix and I am
open to better suggestion for the rest (including what other scenarios
we can think of, Copr was mentioned already ;) ).

BTW should the PR be preceded by opening BZ ticket against the component?

However, with more traffic commits like [1] will conflict anyway.

That's true. Maybe we can figure out some non-conflicting format, e.g.
concatenate all files in contributors.d/ directory?

Interesting idea. I'll try to look into this (and patches are welcomed).

Also, I think the default license should be CC by-sa 4.0, the same
as the default for Fedora [2].

Vít

Zbyszek

[2]
https://communityblog.fedoraproject.org/fedoras-default-license-for-content-is-now-cc-by-sa-4-0/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure

[Bug 2011114] perl-Encode-3.13 is available

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-a461198449 has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-a461198449


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=204
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-35-20211006.n.0 compose check report

2021-10-06 Thread Fedora compose checker

No missing expected images.

Failed openQA tests: 6/204 (x86_64), 6/141 (aarch64)

New failures (same test not failed in Fedora-35-20211005.n.0):

ID: 1016323 Test: x86_64 Server-dvd-iso install_resize_lvm
URL: https://openqa.fedoraproject.org/tests/1016323
ID: 1016442 Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/1016442
ID: 1016493 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1016493
ID: 1016584 Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1016584
ID: 1016632 Test: aarch64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/1016632

Old failures (same test failed in Fedora-35-20211005.n.0):

ID: 1016386 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1016386
ID: 1016389 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1016389
ID: 1016399 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1016399
ID: 1016401 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/1016401
ID: 1016475 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1016475
ID: 1016498 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi
URL: https://openqa.fedoraproject.org/tests/1016498
ID: 1016604 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1016604

Soft failed openQA tests: 2/204 (x86_64), 2/141 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-35-20211005.n.0):

ID: 1016360 Test: x86_64 Workstation-live-iso gedit
URL: https://openqa.fedoraproject.org/tests/1016360
ID: 1016414 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1016414
ID: 1016487 Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1016487
ID: 1016505 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1016505

Passed openQA tests: 185/204 (x86_64), 133/141 (aarch64)

New passes (same test not passed in Fedora-35-20211005.n.0):

ID: 1016348 Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/1016348
ID: 1016432 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1016432
ID: 1016436 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/1016436
ID: 1016440 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/1016440
ID: 1016441 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/1016441
ID: 1016491 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1016491
ID: 1016499 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1016499
ID: 1016513 Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/1016513
ID: 1016518 Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/1016518
ID: 1016522 Test: x86_64 universal install_blivet_with_swap
URL: https://openqa.fedoraproject.org/tests/1016522
ID: 1016563 Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/1016563
ID: 1016586 Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/1016586
ID: 1016594 Test: aarch64 universal install_blivet_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/1016594
ID: 1016605 Test: aarch64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/1016605
ID: 1016613 Test: aarch64 universal support_server@uefi
URL: https://openqa.fedoraproject.org/tests/1016613
ID: 1016627 Test: aarch64 universal install_kickstart_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/1016627

Skipped non-gating openQA tests: 11 of 345

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used swap changed from 6 MiB to 4 MiB
1 packages(s) added since previous compose: shadow-utils-subid
System load changed from 0.62 to 0.36
Previous test data: https://openqa.fedoraproject.org/tests/1014356#downloads
Current test data: https://openqa.fedoraproject.org/tests/1016355#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
Used swap changed from 4 MiB to 5 MiB
1 packages(s) added since previous compose:

Re: co/lead-maintainer sought: python-mailmerge (python)

2021-10-06 Thread TItouan Bénard

Le lundi 04 octobre 2021 à 11:54 +0200, Brian (bex) Exelbierd a écrit :
> 
> 
> On Sun, Oct 3, 2021 at 6:48 PM TItouan Bénard  wrote:
> > Hi,
> > 
> > I want to help you
> > 
> 
> 
> Sweet.  Onuralp replied via direct mail and I have added them to the repo as
> well.  Can you work with them (or agree on any other organization) around the
> upgrades indicated in https://bugzilla.redhat.com/show_bug.cgi?id=1937525
> 
> also, send me your FAS id so I can add you to the repo.

My FAS id is itotutona

> 
> Once the upgrades are good I can hand off the repo to one of you all as main
> maintainer :)
> 
> Thank you.
> 
> regards,
> 
> bex
> 
> 
>  
> > 
> > Thanks
> > 
> > Titouan
> > 
> > Le dimanche 03 octobre 2021 à 13:34 +0300, Onuralp SEZER a écrit :
> > > Hello Brian, I would like to step-up. 
> > > 
> > > Thank you 
> > > Regards
> > > 
> > > 
> > > Onuralp S.
> > > 
> > > On Sun, Oct 3, 2021 at 11:36 AM Brian (bex) Exelbierd
> > >  wrote:
> > > > Hi,
> > > > 
> > > > Want to play with python packaging?  I am still looking for some
> > > > assistance here :)
> > > > 
> > > > Thank you.
> > > > 
> > > > regards,
> > > > 
> > > > bex 
> > > > 
> > > > On Wed, May 5, 2021 at 12:01 PM Brian (bex) Exelbierd
> > > >  wrote:
> > > > > Hi,
> > > > > 
> > > > > I added python-mailmerge to Fedora Linux as it was super important to
> > > > > large parts of my work as FCAIC.  In my current $dayjob I use it less
> > > > > frequently, though I know of colleagues who still depend on it.
> > > > > 
> > > > > I'd love to find a maintainer to help me with it.  There is a new
> > > > > release pending, which I suspect will just be "build the rpm with new
> > > > > code; test it; ship it" level effort.  I am happy to hand the whole
> > > > > thing off to someone or to work with you.
> > > > > 
> > > > > Thank you.
> > > > > 
> > > > > regards,
> > > > > 
> > > > > bex
> > > > > -- 
> > > > > Did this email arrive after work for you?  Stop reading it and enjoy
> > > > > some work/life balance.
> > > > > 
> > > > > Brian "bex" Exelbierd (he/him/his)
> > > > > Community Business Owner, RHEL Product Management
> > > > > @bexelbie | http://www.winglemeyer.org
> > > > > bexel...@redhat.com
> > > > 
> > > > 
> > > > -- 
> > > > Did this email arrive after work for you?  Stop reading it and enjoy
> > > > some work/life balance.
> > > > 
> > > > Brian "bex" Exelbierd (he/him/his)
> > > > Community Business Owner, RHEL Product Management
> > > > @bexelbie | http://www.winglemeyer.org
> > > > bexel...@redhat.com
> > > > ___
> > > > devel mailing list -- devel@lists.fedoraproject.org
> > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > > Fedora Code of Conduct:
> > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives:
> > > >
> > >
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > > > Do not reply to spam on the list, report it:
> > > > https://pagure.io/fedora-infrastructure
> > > 
> > > 
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > >
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > > Do not reply to spam on the list, report it:
> > > https://pagure.io/fedora-infrastructure
> > 
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure



signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to

Migrate python3-language-server upstream to the version maintained by the community

2021-10-06 Thread Mairo Paul Rufus

Currently python3-language-server upstream is 
https://github.com/palantir/python-language-server which is currently 
unmaintained, this is a proposal to move that to 
https://github.com/python-lsp/python-lsp-server which is a community-maintained 
fork.
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RISC-V -- are we ready for more, and what do we need to do it?

2021-10-06 Thread Justin Forbes

On Mon, Oct 4, 2021 at 12:03 PM Matthew Miller  wrote:
>
> Hi all! I just got back from Open Source Summit, several of the talks I
> found interesting were on RISC-V -- a high-level one about the
> organizational structure, and Drew Fustini's more technical talk.
>
> In that, he noted that there's a Fedora build *, but it isn't an official
> Fedora arch. As I understand it, the major infrastructure blocker is simply
> that there isn't server-class hardware (let alone hardware that will build
> fast enough that it isn't a frustrating bottleneck).
>
> So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances
> as builders, could we build fast enough under QEMU emulation to work? We
> have a nice early advantage, but if we don't keep moving, we'll lose that.
>
> But beyond that: What other things might be limits? Are there key bits of
> the distro which don't build yet? Is there a big enough risc-v team to
> respond to arch-specific build failures? And, do we have enough people to do
> QA around release time?

Kernel is still an issue, in that the changes to support RISC-V have
not been merged yet, though I expect that is not a massive
undertaking.

Justin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora  Java: The Death of Two SIGs

2021-10-06 Thread Mikolaj Izdebski

On Tue, Oct 5, 2021 at 1:27 PM Peter Boy  wrote:
>
>
>
> > Am 04.10.2021 um 15:29 schrieb Mikolaj Izdebski :
> >
> > On Mon, Oct 4, 2021 at 2:08 PM Peter Boy  wrote:
> >> However, we lack concepts on how to proceed after removing java-maint-sig. 
> >> What consequences do we draw from the analyses?
> >
> > … If you want
> > to improve docs, just do it. And so on. ...
> > ... or to plan editing the wiki. Whoever wants to clean up some wiki
> > pages can simply do so, without asking.
>
> It’s not as easy as you think of. That way you will end with the docs as 
> Stephen Smoogen described 4 posts back, just chaos and misinformation. You 
> need  collaboration and agreement (shared plan) from participants in all 
> affected areas - including you as the (main) developer of a core package (not 
> writing text, but e.g check the concept, check technical correctness and 
> completeness). It simply doesn’t work the way you are proposing.

Sure, some major changes may indeed require planning or cooperation.
That's what we have the SIG and its communication channels for. For
example, if I wanted to rewrite Java documentation and move it from
the wiki to docs.fedoraproject.org at the same time, I would start
with sending a proposal to java-devel mailing list and ask for
feedback. We would discuss what should and what should not be
documented, who wants to document what and so on. Depending on how the
discussion goes there, I might propose an IRC meeting to ease the
discussion process.

>
>
> >> I posted on the java list some ideas some time ago ('Empowering Fedora 
> >> Java’). Any comments on those?
> >
> > These were about java-maint-sig, IIRC, which basically does not exist
> > any longer.
>
> No! It was about:
> > The biggest success is that with all the adversities in java packaging we 
> > have a stabilized Fedora Java core platform.

I'll re-read it then and try to reply.

> >
> > The next urgent step, in my opinion, is to update and improve information 
> > materials and documentation, followed by a community building process based 
> > on it.
> >
> >
> > I can offer to do the writing. …
> followed by tentative ideas about details of documentation.
>
> You wrote:
> > Java SIG has resources in form
> > of communication channels that can be used by members to help each
> > other. There is a mailing list and an IRC channel.
> So much for the theory, yes. I would have appreciated even a tiny bit of it.

I don't understand. These communication channels exist and are
functional. The most active Java packagers I know of are subscribed to
the mailing list and are present in the IRC channel. The fact that
there is not much ongoing communication is a different problem - I
find that people very often approach me directly or through other
channels, and many times I ask them to use public Java SIG channels
because that allows others to benefit from the conversation.

> You are one of the developers without whose contributions the Fedora Java 
> stack would probably collapse in a short time.  I would really be interested 
> in the same question as to Mat: With java-paint-sig removed, are you really 
> completely content with the Fedora Java world?  No change? No improvement 
> anywhere?

I'm happy with how Java SIG works in general - as an informal group
that does not limit packagers freedom, like by enforcing agile
processes, or mandating code review for every change. I like that Java
SIG doesn't have any authority to make any decisions - there can be
discussion, but ultimately each package owner makes decisions
regarding their own packages, within boundaries defined by Fedora
policies. The Fedora change process can be used when required - anyone
can propose a change, and once approved by FESCo, the package owner
must obey. I like that unmaintained packages are being removed from
distribution - with decreasing manpower in Java SIG I think it's
better to focus on fewer important packages.

For sure we should clean outdated Java SIG wiki pages - that's
relatively simple and I can do that myself. We should pay better
attention to announcing important changes that can affect others. We
can try regular IRC meetings instead of ad-hoc meetings. We could try
to come up with common goals for the SIG, but I'm not sure if that
will help. Right now I don't have any other ideas regarding improving
Java SIG organization.

Regarding Java content in Fedora Linux, there is a lot to improve, and
I have many ideas. I started writing them down as they come to my mind
and for each of them I'll start separate threads on java-devel list.

I also promise to document ongoing or planned projects that I am or
would like to be working on. Then anyone interested will be able to
more easily see what is going on, and possibly help with these
projects. Some of the projects that I have in mind:
Ongoing:
- MBI (Maven Bootstrap Initiative, an ability to build Maven and XMvn
fully from source from scratch, without reliance on pre-existing
binaries),
- Maven

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

2021-10-06 Thread Matthew Miller

On Wed, Oct 06, 2021 at 07:08:46AM +0200, Michal Srb wrote:
> @Matthew Miller  Are you still trying to save Fedora
> from packaging the ocean? :)

Oh, you remember. Yes. :)

Let's do what we do really well, really well, and not do things where we're
fighting against 99.% of all actual use both in dev and prod.



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [RFC] Remove supoort for NIS(+) from PAM

2021-10-06 Thread Matthew Miller

On Wed, Oct 06, 2021 at 01:28:33PM +0200, Björn 'besser82' Esser wrote:
> Yes, finally dropping the ypbind, yp-tools, and ypserv packages seems to
> make sense in this context, as from my understanding they won't be of
> any practical use anymore.

+1. Time to say goodbye.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2011383] New: perl-CPANPLUS-Dist-Fedora-0.4.4 is available

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

Bug ID: 2011383
   Summary: perl-CPANPLUS-Dist-Fedora-0.4.4 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-CPANPLUS-Dist-Fedora
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: i...@cicku.me, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.4.4
Current version/release in rawhide: 0.4.3-1.fc36
URL: http://search.cpan.org/dist/CPANPLUS-Dist-Fedora/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/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/5882/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2011383
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned packages

2021-10-06 Thread Ben Beasley

I claimed libfakekey. I’ll modernize the spec file a bit and update it 
to 0.3 from https://git.yoctoproject.org/cgit/cgit.cgi/libfakekey/.


On 10/4/21 18:20, Peter Robinson wrote:

Looking through the packages I own there's a bunch I no longer use.
I've tried to group these, from memory, where I own something because
it's a dependency of something else. I was going to ask people if they
were interested in them but I decided to straight up orphan them so
they#ll can go through the usual garbage collection process unless
someone claims them. The top two groups of packages need to be
maintained together as the key package, at the top, depends on the
rest. The bottom group are independent.

speech-dispatcher
dotconf
festival-freebsoft-utils
flite

libcec
platform

crcimg
csound
libsoc
python-webthing
zram
libfakekey
ptpd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora 35 compose report: 20211006.n.0 changes

2021-10-06 Thread Fedora Rawhide Report

OLD: Fedora-35-20211005.n.0
NEW: Fedora-35-20211006.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   16
Downgraded packages: 0

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

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  apache-cloudstack-cloudmonkey-6.2.0-1.fc35
Old package:  apache-cloudstack-cloudmonkey-6.1.0-3.fc35
Summary:  Apache Cloudstack Cloudmonkey
RPMs: apache-cloudstack-cloudmonkey 
golang-github-apache-cloudstack-cloudmonkey-devel
Size: 10.31 MiB
Size change:  16.09 KiB
Changelog:
  * Sat Sep 25 2021 Olivier Lemasle  - 6.2.0-1
  - Update to upstream 6.2.0 (fixes rhbz#2007649)


Package:  arbor-0.5.2-4.fc35
Old package:  arbor-0.3-9.fc35
Summary:  Multi-compartment neural network simulation library
RPMs: arbor arbor-devel arbor-doc arbor-mpich arbor-mpich-devel 
arbor-openmpi arbor-openmpi-devel
Size: 402.17 MiB
Size change:  183.61 MiB
Changelog:
  * Fri Jun 04 2021 Python Maint  0.3-11
  - Rebuilt for Python 3.10

  * Wed Jul 21 2021 Fedora Release Engineering  0.3-12
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Wed Jul 21 2021 Fedora Release Engineering  0.3-13
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Sat Sep 25 2021 Ankur Sinha (Ankur Sinha Gmail)  
0.5.2-1
  - feat: update to 0.5.2

  * Sat Sep 25 2021 Ankur Sinha (Ankur Sinha Gmail)  
0.5.2-2
  - chore: remove unused patch

  * Sat Sep 25 2021 Ankur Sinha (Ankur Sinha Gmail)  
0.5.2-3
  - feat: correct flags for s390 builds

  * Sat Sep 25 2021 Ankur Sinha (Ankur Sinha Gmail)  
0.5.2-4
  - chore: remove second unneeded patch


Package:  conmon-2:2.0.30-2.fc35
Old package:  conmon-2:2.0.29-0.2.dev.git2947bb2.fc35
Summary:  OCI container runtime monitor
RPMs: conmon
Size: 280.33 KiB
Size change:  12.05 KiB
Changelog:
  * Mon Aug 16 2021 RH Container Bot  - 
2:2.0.29-1
  - autobuilt v2.0.29

  * Mon Aug 16 2021 Lokesh Mandvekar  - 2:2.0.29-2
  - build correct tag lol

  * Wed Sep 22 2021 RH Container Bot  - 
2:2.0.30-1
  - autobuilt v2.0.30

  * Wed Sep 22 2021 Lokesh Mandvekar  - 2:2.0.30-2
  - bump timeout for gating tests


Package:  containers-common-4:1-30.fc35
Old package:  containers-common-4:1-24.fc35
Summary:  Common configuration and documentation for containers
RPMs: containers-common
Size: 73.18 KiB
Size change:  9.33 KiB
Changelog:
  * Thu Aug 12 2021 Dan Walsh  - 4:1-25
  - Update to grab latest man pages and configuration files

  * Wed Aug 25 2021 Dan Walsh  - 4:1-26
  - Add memfd_secret to seccomp.json

  * Wed Sep 08 2021 Dan Walsh  - 4:1-27
  - Update to grab latest man pages and configuration files

  * Tue Sep 14 2021 Dan Walsh  - 4:1-28
  - Update to grab latest man pages and configuration files

  * Mon Sep 20 2021 Dan Walsh  - 4:1-29
  - Update to grab latest man pages and configuration files

  * Sun Sep 26 2021 Dan Walsh  - 4:1-30
  - Update to grab latest man pages and configuration files
  - Add containerfile.md


Package:  gnote-41.0-1.fc35
Old package:  gnote-41~beta-2.fc35
Summary:  Note-taking application
RPMs: gnote
Size: 21.93 MiB
Size change:  -10.86 KiB
Changelog:
  * Sun Sep 26 2021 Kalev Lember  - 41.0-1
  - Update to 41.0


Package:  golang-github-dpotapov-spnego-0-6.20210926git298b63a.fc35
Old package:  golang-github-dpotapov-spnego-0-0.4.20200222gitc2c6091.fc35
Summary:  Cross-platform HTTP calls with Kerberos authentication
RPMs: golang-github-dpotapov-spnego-devel
Size: 13.28 KiB
Size change:  80 B
Changelog:
  * Sun Sep 26 2021 Elliott Sales de Andrade  0-6
  - Update to latest commit


Package:  golang-github-tdewolff-parse-2.5.21-1.fc35
Old package:  golang-github-tdewolff-parse-2.5.19-2.fc35
Summary:  Go parsers for web formats
RPMs: compat-golang-github-tdewolff-parse-2-devel 
golang-github-tdewolff-parse-devel
Size: 108.20 KiB
Size change:  205 B
Changelog:
  * Sun Sep 12 2021 Elliott Sales de Andrade  
2.5.21-1
  - Update to latest version (#2003317)


Package:  libyui-mga-ncurses-1.1.0-4.fc35
Old package:  libyui-mga-ncurses-1.1.0-2.fc34
Summary:  Libyui-Ncurses extensions for Mageia tools
RPMs: libyui-mga-ncurses libyui-mga-ncurses-devel libyui-mga-ncurses-doc
Size: 790.03 KiB
Size change:  -15.12 KiB
Changelog:
  * Thu Jul 22 2021 Fedora Release Engineering  - 
1.1.0-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Sun Sep 26 2021 Neal Gompa  - 1.1.0-4
  - Add workaround to fix FTBFS with ncurses-6.2-8.20210508 (#1987669)


Package

Re: ELN building packages in wrong order

2021-10-06 Thread Stephen Gallagher

On Wed, Oct 6, 2021 at 6:12 AM Richard W.M. Jones  wrote:
>
> On Wed, Oct 06, 2021 at 12:08:11PM +0200, Miro Hrončok wrote:
> > On 06. 10. 21 11:29, Richard W.M. Jones wrote:
> > >On Wed, Oct 06, 2021 at 10:25:42AM +0100, Richard W.M. Jones wrote:
> > >>
> > >>https://koji.fedoraproject.org/koji/userinfo?userID=5159
> > >>
> > >>I noticed that ELN picked up the ~170 OCaml packages that I just added
> > >>to Rawhide in a single update.  However it appears to be building them
> > >>all at once which ain't going to work.
> > >
> > >... or maybe it will.  It seems to work by rebuilding all the packages
> > >against the F36 buildroot?  That should work.
> >
> > Against the ELN buildroot, but with the ~170 rawhide OCaml builds in it.
> >
> > See 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/EKBW5DRRYGMJ5KOAHBGSXMOKGVSA3NPE/
> >
> > Stephen, is this laready happening?
>
> It seems to be.  I checked some of the builds and they are building
> against the ocaml packages from Rawhide (which is the right way to do it).

Yes, this went into effect on Sept. 30th, but it's had a couple
hiccups that I've been trying to fix before making a wider
announcement about it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned packages

2021-10-06 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Oct 06, 2021 at 07:43:48AM -0300, Pablo Sebastián Greco wrote:
> 
> On 4/10/21 19:20, Peter Robinson wrote:
> >zram
> I picked up zram

This package is not harmful, but it's mostly obsoleted by
https://src.fedoraproject.org/rpms/rust-zram-generator.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned packages

2021-10-06 Thread Gary Buhrmaster

On Mon, Oct 4, 2021 at 11:08 PM Gary Buhrmaster
 wrote:
>
> On Mon, Oct 4, 2021 at 10:21 PM Peter Robinson  wrote:
>
> > I was going to ask people if they
> > were interested in them but I decided to straight up orphan them so
> > they#ll can go through the usual garbage collection process unless
> > someone claims them.
>
> > libcec
> > platform
>
> I'll volunteer to take these two, as they are
> useful for a couple of projects I am involved with
> (unless, of course, someone else wants them
> more than I do).

I was about to take these two after they finally
got orphaned, but found that melmorabity
(pikachu.2...@gmail.com) had quickly picked
up libcec, but NOT platform.

So, if melmarabity wants libcec, they need
to also take platform.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2011114] perl-Encode-3.13 is available

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



--- Comment #1 from Fedora Update System  ---
FEDORA-2021-c6a9bad3aa has been submitted as an update to Fedora 34.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-c6a9bad3aa


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=204
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2011114] perl-Encode-3.13 is available

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-974b321a83 has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-974b321a83


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=204
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2011114] perl-Encode-3.13 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Encode-3.13-481.fc36




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=204
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Onboarding package

2021-10-06 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Oct 06, 2021 at 11:20:47AM +0200, Vít Ondruch wrote:
> 
> Dne 06. 10. 21 v 9:44 Zbigniew Jędrzejewski-Szmek napsal(a):
> >On Wed, Oct 06, 2021 at 09:39:46AM +0200, Vít Ondruch wrote:
> >>Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a):
> >>>On Tue, 5 Oct 2021 at 11:28, Matthew Miller  
> >>>wrote:
> On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote:
> >>Is this really necessary?
> >Yes. Because anyone can add something like this:
> >%post
> >rm -rf /
> >
> >And it will destroy the installed system or even the hardware.
> Yeah, but... that's not going get through the PR process? In fact, that
> specific thing should fail in CI before a human gets to it even.
> 
> Overall, we put a lot of trust in maintainers. I don't see this 
> _particular_
> route as a likely one for violating that trust.
> 
> >>>I think part of the problem is that I don't think the proposal has
> >>>enough flesh on its bones for people not to see it causing all kinds
> >>>of problems somewhere. Or vice versa seeing not enough to see it being
> >>>worthwhile for a beginner. [For many a developer, PR's aren't that
> >>>interesting to most developers and not what they think about when
> >>>looking at packaging. Running fedpkg and making a spec file work on my
> >>>system and through the complicated koji+bodhi+mbs+.. stack is real
> >>>packaging.] So we need a real proposal with an end to end idea of what
> >>>is being done, what is to be learned, and how it is to be 'watched' by
> >>>real developers to make sure people are learning things.
> >>>
> >>>
> >>This was proposed in the "release early, release often" spirit. So I
> >>am glad for the generally positive feedback for this idea and I also
> >>appreciate the concerns which were risen.
> >>
> >>And as I said, this targets the newcomers, so start with the PR is
> >>probably the right thing to do. But even "start with PR" has more
> >>degrees of freedom, e.g. should the contributors modify the
> >>changelog manually or should the `%autorelease` / `%autochangelog`
> >>be used as proposed by Matt? Maybe this could be two scenarios after
> >>all. But it is hard to judge where the line is between being useful
> >>to learn something and being tedious, boring, unattractive or
> >>discouraging.
> >I'd very much lean on the side of %autorelease/%autochangelog.
> >That workflow isn't perfect yet, but it's certainly the feature, and
> >in general, newcomers should learn the new workflows.
> >(There's also the issue raised by Matt that with traditional
> >%changelog pretty much each and every parallel pull request would
> >conflict.)
> 
> 
> I have put together very naive concept here:
> 
> https://fedorapeople.org/cgit/vondruch/public_git/dummy-onboarding-contributors-pr.git/

master → main

Why does the package have "-pr" in the name? We want people to
contribute to it through PRs, but I don't think this needs to be part
of the name.

> However, with more traffic commits like [1] will conflict anyway.

That's true. Maybe we can figure out some non-conflicting format, e.g.
concatenate all files in contributors.d/ directory?

Also, I think the default license should be CC by-sa 4.0, the same
as the default for Fedora [2].

Zbyszek

[2] 
https://communityblog.fedoraproject.org/fedoras-default-license-for-content-is-now-cc-by-sa-4-0/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

2021-10-06 Thread Mikolaj Izdebski

On Mon, Oct 4, 2021 at 8:50 PM Matthew Miller  wrote:
>
> On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
> > I'm not sure what's the best solution, but I guess the number one
> > reason to have packages within the Fedora distribution is for a matter
> > of trust, if this is the case I would argue that a curated list of
> > maven packages served via a Fedora managed repository would be a
> > better investment.
>
> I'd love to see someone interested in this pursue this idea! I know we
> talked about it as long ago as... Flock Prague... and probably before.

That's a very old idea that has been partially implemented years ago,
but never approved for use in Fedora. Maven artifacts can be built in
Koji (there is an existing "koji maven-build" command). Once built
they appear in a "curated" Maven repository hosted on Koji, that can
be synced to mirrors, from where users can consume it. Consumers of
this Maven repository don't need to be running Fedora, not even Linux.

Curated Maven repository contains additional metadata, eg. CVEs
affecting given artifact version, whether upstream is active, whether
given artifact is available in Fedora and in which releases, etc. For
each Fedora Linux release there is an auto-generated BOM (bill of
materials POM) listing artifacts available in the release.

Binaries from this trusted/curated Maven repository can also be
wrapped into RPMs (using "koji wrapper-rpm" command) and put into
distribution repos and composes. Other packages can depend on such
RPMs. This is a hybrid packaging model, where some Java RPM packages
can be built in the traditional way (where code is compiled during
rpmbuild) and some are built elsewhere, and only wrapped in RPMs.

--
Mikolaj Izdebski

>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2011114] perl-Encode-3.13 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
 Status|NEW |ASSIGNED
 CC|jples...@redhat.com,|
   |mspa...@redhat.com, |
   |ppi...@redhat.com   |




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=204
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Onboarding package

2021-10-06 Thread information


On 2021-10-05 10:35 pm, Otto Urpelainen wrote:

Stephen Snow kirjoitti 5.10.2021 klo 15.39:

we were initially discussing that it could be useful to have some
package one can experiment with without being too much worried about
the
result.

However, discussing this back and forth, we figured that it might
also
where new coming package maintainer could gradually gain experience
with
the packaging workflows. So the simplest tasks could be:

1) Add changelog entry into onboarding package and open PR with the
change. This would not require too many privileges. Alternatively
this
current Fedora contributors might be interested to send such PR ;)


I like this approach, but I was also thinking of a small tutorial/app
to actually package a piece of software as required, going through the
various steps but be a "fake" package that is only used to teach and
test with. This app could record the FAS user ID and assign a badge to
it once they complete the tutorial successfully. Sort of a base
starting point for all new packagersd that give both them some
confidence going in and the sponsors some confidence too about the
level of the new committers capabilities.


Well, in the Quick Docs, we already have Creating RPM packages [1]. It
has subpage "Publishing your software on Copr", which somehow covers
the publishing aspect. But honestly, when I was starting out, I spent
some time with those instructions, but could not understand them or
complete the tutorials. So one thing would be to revisit these
instructions and make the better — there is a task about moving them
over to Package Maintainer Docs [2], it was in progress at some point,
but apparently stalled now. After that, improvement could happen.

About every packager publishing their own test package, in Copr that
can be done for sure. If it is deemed too far from the official Fedora
repositories, the perhaps it could be done in staging. I have never
really used it, I cannot say if that is a good idea or not.

A similar but different idea I have is to create a "Fedora Packaging
Guidelines Web Course" that you can complete by yourself. It could be
implemented as a Git repository. For each entry in the the Review
Guidelines [3], there would be a directory with a specfile and a srpm.
For simplicity, we could first implement cases which fedora-review can
check automatically. The student's assignment would be to run
fedora-review on the specfile, find the error it gives, refer to the
Packaging Guidelines to figure out how to fix it, modify the specfile
as needed and run fedora-review again to check their answer. The
assignment is completed when fedora-review does not complain any more.

Later, the course could be expanded also to cases where there is no
automated check available, either by involving a mentor, or simply by
adding a SOLUTION file.

Awarding a badge for completing this course would be a good idea, if a
technical solution can be found.

I see this course as complementary to Vít's original proposal about
the onboarding package. The orboarding package tasks are about
learning the build system, certainly a required skill for packages.
The course is about learning the Guidelines. Currently the recommended
method to do that is to submit inofficial reviews to live Review
Requests. That has the advantage of exposing the applicant to real
packages with real problems, but 1) has no guarantee of producing an
effective learning path, the package that is picked may well be a very
tricky case and thus unsuitable for starting out and 2) is
psychologically unsafe, because a total newcomer must participate in
discussion of two experts who are actually trying to get a package
into Fedora, not educating the packagers.

[1]: 
https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/

[2]: https://pagure.io/fedora-docs/package-maintainer-docs/issue/19
[3]:
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process


packager to be already sponsored and they could go through the whole
process themeselves just with some light guidance if needed.

This could be extended in the future. E.g. next step could be:

3) Submit module update.

Apart from gaining experience, this could also help with the common
question "where should I start". And of course our sponsoring
guidelines
could be refreshed suggesting/requesting to take these steps at some
point.

Thoughts?


Personnaly I am for this type of approach since it is also clarifying
the roles a bit more too. It wouldn't hurt to outline what is expected
of a packager of Fedora Linux in general. You know expectations are
very often left unsaid thinking that roles and responsibilities fill 
in

the info, but that is not always the case.


Are you aware of the page "Package maintainer responsibilities" [4]?
Is there some aspects of the responsibilities that are not covered
there?

[4]:
https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/

Re: [RFC] Remove supoort for NIS(+) from PAM

2021-10-06 Thread Alexander Bokovoy

On ke, 06 loka 2021, Björn 'besser82' Esser wrote:

Am Freitag, dem 01.10.2021 um 09:31 -0400 schrieb Stephen John Smoogen:

On Fri, 1 Oct 2021 at 06:14, Björn 'besser82' Esser
 wrote:
>
> Hello,
>
> I'm currently doing some experiments with replacing the - upstream
> mostly unmaintained - pam_unix module (authentication with user
> passwd)
> with something using less bloated and cleaner code.  This topic is
> currently also discussed with the upstream maintainer of pam_unix.
>
> Replacing parts of a software for the sake of less complexity
> usually
> comes with a cut-down of features; in this particular case it would
> be
> dropping support for NIS(+), which has already been abandoned by its
> initial developer SUN / Oracle for about 10 years [1].
>
> Before starting some more concrete plans, I'd like to get some
> feedback
> from the Fedora community how they feel about removing NIS(+)
> support in
> PAM.  Is it even still actively used anywhere and/or by anyone in
> the
> Fedora universe?
>

The places I have seen it still being used are in Universities run by
people who learned sysadmin in the 1990's and early 2000's. It is a
light weight system which is simple to set up and tends to be the
goto-stick for a lot of 'we put this together in 1999 with RHL6 and
upgraded ever since' places.

That said, NIS in most setups causes all kinds of security problems
and audit failures that those areas are probably rapidly going away.
[And the ones I know have been moving to Debian because it keeps
various other technologies we jettisoned long ago.]

If we drop this from pam_unix, should we look to dropping ypbind and
similar tools?

Yes, finally dropping the ypbind, yp-tools, and ypserv packages seems to
make sense in this context, as from my understanding they won't be of
any practical use anymore.

Maybe libnsl, libnsl2, nss_nis, and slapi-nis can be evaluated to be
dropped also.

slapi-nis implements two separate plugins, one of which provides NIS
support. It is going to be supported in RHEL 9 and I'd like to keep NIS
part supported in Fedora as well for some time. This only requires
existence of libnsl2.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2008958] CVE-2021-38562 rt: User enumeration through a timing side-channel attack [fedora-all]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |MODIFIED



--- Comment #7 from Fedora Update System  ---
FEDORA-2021-05feb8a8b2 has been submitted as an update to Fedora 34.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-05feb8a8b2


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2008958
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2008958] CVE-2021-38562 rt: User enumeration through a timing side-channel attack [fedora-all]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |MODIFIED



--- Comment #7 from Fedora Update System  ---
FEDORA-2021-05feb8a8b2 has been submitted as an update to Fedora 34.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-05feb8a8b2

--- Comment #8 from Fedora Update System  ---
FEDORA-2021-7ddc28a14b has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-7ddc28a14b


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2008958
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2008958] CVE-2021-38562 rt: User enumeration through a timing side-channel attack [fedora-all]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |MODIFIED



--- Comment #7 from Fedora Update System  ---
FEDORA-2021-05feb8a8b2 has been submitted as an update to Fedora 34.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-05feb8a8b2

--- Comment #8 from Fedora Update System  ---
FEDORA-2021-7ddc28a14b has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-7ddc28a14b

--- Comment #9 from Fedora Update System  ---
FEDORA-2021-825dd1879f has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-825dd1879f


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2008958
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

2021-10-06 Thread Mat Booth

On Wed, 6 Oct 2021 at 11:02, Peter Boy  wrote:
>
>
>
> Am 06.10.2021 um 07:08 schrieb Michal Srb :
>
> Hi folks,
>
> @Matthew Miller Are you still trying to save Fedora from packaging the ocean? 
> :)
>
> On Mon, Oct 4, 2021 at 9:10 PM Fabio Valentini  wrote:
> On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller  
> wrote:
>
>
> On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
>
> I'm not sure what's the best solution, but I guess the number one
> reason to have packages within the Fedora distribution is for a matter
> of trust, if this is the case I would argue that a curated list of
> maven packages served via a Fedora managed repository would be a
> better investment.
>
>
> I'd love to see someone interested in this pursue this idea! I know we
> talked about it as long ago as... Flock Prague... and probably before.
>
>
> …..
>
> Fedora could ship just Java applications that would bundle JARs (whatever 
> version they need) from the Fedora Maven repository. I don't see this as a 
> problem, as long as it would be possible to track what JARs are bundled in 
> what application.
>
> Fedora maintainers could then focus on maintaining applications, and not 
> maintaining a ton of individual libraries that nobody really cares about that 
> much.
>
>
> I've roughly thought this through with our Java Web CMS project (we don't 
> currently create Fedora rpm). I think with this idea the effort would be 
> noticeably reduced. A number of intermediate steps could be omitted.
>
> My main question: how can we get this going?
>
> Normally we would first need a concise description and then (try to) discuss 
> it on java-devel.
>
> Or is this a case of "do-ocracy“?
>

Yes ;-) I look forward to reading your proposal on java-devel.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [RFC] Remove supoort for NIS(+) from PAM

2021-10-06 Thread Björn 'besser82' Esser

Am Freitag, dem 01.10.2021 um 09:31 -0400 schrieb Stephen John Smoogen:
> On Fri, 1 Oct 2021 at 06:14, Björn 'besser82' Esser
>  wrote:
> > 
> > Hello,
> > 
> > I'm currently doing some experiments with replacing the - upstream
> > mostly unmaintained - pam_unix module (authentication with user
> > passwd)
> > with something using less bloated and cleaner code.  This topic is
> > currently also discussed with the upstream maintainer of pam_unix.
> > 
> > Replacing parts of a software for the sake of less complexity
> > usually
> > comes with a cut-down of features; in this particular case it would
> > be
> > dropping support for NIS(+), which has already been abandoned by its
> > initial developer SUN / Oracle for about 10 years [1].
> > 
> > Before starting some more concrete plans, I'd like to get some
> > feedback
> > from the Fedora community how they feel about removing NIS(+)
> > support in
> > PAM.  Is it even still actively used anywhere and/or by anyone in
> > the
> > Fedora universe?
> > 
> 
> The places I have seen it still being used are in Universities run by
> people who learned sysadmin in the 1990's and early 2000's. It is a
> light weight system which is simple to set up and tends to be the
> goto-stick for a lot of 'we put this together in 1999 with RHL6 and
> upgraded ever since' places.
> 
> That said, NIS in most setups causes all kinds of security problems
> and audit failures that those areas are probably rapidly going away.
> [And the ones I know have been moving to Debian because it keeps
> various other technologies we jettisoned long ago.]
> 
> If we drop this from pam_unix, should we look to dropping ypbind and
> similar tools?


Yes, finally dropping the ypbind, yp-tools, and ypserv packages seems to
make sense in this context, as from my understanding they won't be of
any practical use anymore.

Maybe libnsl, libnsl2, nss_nis, and slapi-nis can be evaluated to be
dropped also.

Björn


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned packages

2021-10-06 Thread Pablo Sebastián Greco



On 4/10/21 19:20, Peter Robinson wrote:

zram

I picked up zram
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN building packages in wrong order

On Wed, Oct 06, 2021 at 12:08:11PM +0200, Miro Hrončok wrote:
> On 06. 10. 21 11:29, Richard W.M. Jones wrote:
> >On Wed, Oct 06, 2021 at 10:25:42AM +0100, Richard W.M. Jones wrote:
> >>
> >>https://koji.fedoraproject.org/koji/userinfo?userID=5159
> >>
> >>I noticed that ELN picked up the ~170 OCaml packages that I just added
> >>to Rawhide in a single update.  However it appears to be building them
> >>all at once which ain't going to work.
> >
> >... or maybe it will.  It seems to work by rebuilding all the packages
> >against the F36 buildroot?  That should work.
> 
> Against the ELN buildroot, but with the ~170 rawhide OCaml builds in it.
> 
> See 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/EKBW5DRRYGMJ5KOAHBGSXMOKGVSA3NPE/
> 
> Stephen, is this laready happening?

It seems to be.  I checked some of the builds and they are building
against the ocaml packages from Rawhide (which is the right way to do it).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN building packages in wrong order

2021-10-06 Thread Miro Hrončok


On 06. 10. 21 11:29, Richard W.M. Jones wrote:

On Wed, Oct 06, 2021 at 10:25:42AM +0100, Richard W.M. Jones wrote:


https://koji.fedoraproject.org/koji/userinfo?userID=5159

I noticed that ELN picked up the ~170 OCaml packages that I just added
to Rawhide in a single update.  However it appears to be building them
all at once which ain't going to work.


... or maybe it will.  It seems to work by rebuilding all the packages
against the F36 buildroot?  That should work.


Against the ELN buildroot, but with the ~170 rawhide OCaml builds in it.

See 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/EKBW5DRRYGMJ5KOAHBGSXMOKGVSA3NPE/


Stephen, is this laready happening?

--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

2021-10-06 Thread Peter Boy



> Am 06.10.2021 um 07:08 schrieb Michal Srb  >:
> 
> Hi folks,
> 
> @Matthew Miller Are you still trying to save Fedora from packaging the ocean? 
> :)
> 
> On Mon, Oct 4, 2021 at 9:10 PM Fabio Valentini  wrote:
> On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller  
> wrote:
>> 
>> On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
>>> I'm not sure what's the best solution, but I guess the number one
>>> reason to have packages within the Fedora distribution is for a matter
>>> of trust, if this is the case I would argue that a curated list of
>>> maven packages served via a Fedora managed repository would be a
>>> better investment.
>> 
>> I'd love to see someone interested in this pursue this idea! I know we
>> talked about it as long ago as... Flock Prague... and probably before.
> 
> …..
> 
> Fedora could ship just Java applications that would bundle JARs (whatever 
> version they need) from the Fedora Maven repository. I don't see this as a 
> problem, as long as it would be possible to track what JARs are bundled in 
> what application.
> 
> Fedora maintainers could then focus on maintaining applications, and not 
> maintaining a ton of individual libraries that nobody really cares about that 
> much.

I've roughly thought this through with our Java Web CMS project (we don't 
currently create Fedora rpm). I think with this idea the effort would be 
noticeably reduced. A number of intermediate steps could be omitted. 

My main question: how can we get this going? 

Normally we would first need a concise description and then (try to) discuss it 
on java-devel. 

Or is this a case of "do-ocracy“?

And who is able / willing to (co-)work?___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20211006.0 compose check report

2021-10-06 Thread Fedora compose checker

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-20211005.0):

ID: 1015863 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1015863
ID: 1015871 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1015871

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora  Java: The Death of Two SIGs

2021-10-06 Thread Miro Hrončok


On 29. 09. 21 13:49, Miro Hrončok wrote:

On 26. 09. 21 21:20, Fabio Valentini wrote:

Should the @java-maint-sig group be removed from any packages it is
still associated with? Should it be dissolved, and members be removed?
Should the remaining ruins that used to be packages be orphaned?
Retired? Buried? Forgotten?


Since many have moved this discussion away from this question, let me please 
bring back the main reason this was posted.


Since the @java-maint-sig group is esentially non-responsive, I suggest we do 
the following:



1) We remove all BZ assignee overrides to @java-maint-sig. This is a must.
2) We remove access of @java-maint-sig from all packages.
3) We ask the members of the group if they want to admin the list/BZ account.
   3a) We give it to the volunteer.
   3b) We empty the group and cancel the BZ account/list if nobody shows up.
4) We *don't orphan the packages*, they have some "de jure" maintainers.

The packages that fail to install and/or build will eventually die out due to 
the existing processes.


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

--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN building packages in wrong order

On Wed, Oct 06, 2021 at 10:25:42AM +0100, Richard W.M. Jones wrote:
> 
> https://koji.fedoraproject.org/koji/userinfo?userID=5159
> 
> I noticed that ELN picked up the ~170 OCaml packages that I just added
> to Rawhide in a single update.  However it appears to be building them
> all at once which ain't going to work.

... or maybe it will.  It seems to work by rebuilding all the packages
against the F36 buildroot?  That should work.

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

ELN building packages in wrong order


https://koji.fedoraproject.org/koji/userinfo?userID=5159

I noticed that ELN picked up the ~170 OCaml packages that I just added
to Rawhide in a single update.  However it appears to be building them
all at once which ain't going to work.

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Onboarding package

Dne 06. 10. 21 v 9:44 Zbigniew Jędrzejewski-Szmek napsal(a):

On Wed, Oct 06, 2021 at 09:39:46AM +0200, Vít Ondruch wrote:

Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a):

On Tue, 5 Oct 2021 at 11:28, Matthew Miller wrote:

On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote:

Is this really necessary?

Yes. Because anyone can add something like this:
%post
rm -rf /

And it will destroy the installed system or even the hardware.

Yeah, but... that's not going get through the PR process? In fact, that
specific thing should fail in CI before a human gets to it even.

Overall, we put a lot of trust in maintainers. I don't see this _particular_
route as a likely one for violating that trust.

This was proposed in the "release early, release often" spirit. So I
am glad for the generally positive feedback for this idea and I also
appreciate the concerns which were risen.

I have put together very naive concept here:

https://fedorapeople.org/cgit/vondruch/public_git/dummy-onboarding-contributors-pr.git/

https://copr.fedorainfracloud.org/coprs/vondruch/dummy-onboarding-contributors-pr/

However, with more traffic commits like [1] will conflict anyway.

Vít

[1]
https://fedorapeople.org/cgit/vondruch/public_git/dummy-onboarding-contributors-pr.git/commit/?id=606ff9d7ff7672ad2692102c7a078ceaacaeeb9b

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

Dne 06. 10. 21 v 7:08 Michal Srb napsal(a):

Hi folks,

@Matthew Miller  Are you still trying to 
save Fedora from packaging the ocean? :)

On Mon, Oct 4, 2021 at 9:10 PM Fabio Valentini  
wrote:

On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller
 wrote:
>
> On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
> > I'm not sure what's the best solution, but I guess the number one
> > reason to have packages within the Fedora distribution is for
a matter
> > of trust, if this is the case I would argue that a curated list of
> > maven packages served via a Fedora managed repository would be a
> > better investment.
>
> I'd love to see someone interested in this pursue this idea! I
know we
> talked about it as long ago as... Flock Prague... and probably
before.

This approach will buy you *literally nothing* compared to how things
already work, assuming you don't advocate just redistributing binary
artifacts / JARs from Maven Central.

Given that assumption, JARs would still need to be built 1) from
source, in a 2) trusted environment, 3) against trusted dependencies,
as I don't think any other approach should be acceptable for content
distributed by the Fedora Project.

But then you're back to *exactly how Fedora packages for Java projects
already work* - only with the added complication that distributing
those build artifacts as plain JARs instead of RPMs now makes them
impossible to consume as dependencies from other RPM builds.

I think it would actually make a huge difference.

Unlike RPM repositories, Maven repositories can easily hold multiple 
versions of libraries.

RPM repositories can hold multiple version of libraries as well. This is 
self inflicted limitation of Fedora, because once you have multiple 
versions of libraries, you should also fix (security) bugs in those 
versions. And this is where it starts to be complicated.

Vít

Once a JAR is built, the resulting bytecode will work with current and 
future JVMs. There is no need to mass-rebuild JARs every 6 months. And 
there is certainly no need to try to run every single Java application 
with a single "system-wide" version of a library.

Fedora could ship just Java applications that would bundle JARs 
(whatever version they need) from the Fedora Maven repository. I don't 
see this as a problem, as long as it would be possible to track what 
JARs are bundled in what application.

Fedora maintainers could then focus on maintaining applications, and 
not maintaining a ton of individual libraries that nobody really cares 
about that much.

Thanks,
Michal

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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure

___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report 
it:https://pagure.io/fedora-infrastructure___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Onboarding package

2021-10-06 Thread Vitaly Zaitsev via devel


On 05/10/2021 18:04, Stephen John Smoogen wrote:

So we need a real proposal with an end to end idea of what
is being done, what is to be learned, and how it is to be 'watched' by
real developers to make sure people are learning things.


Maybe we can make a VM image (for KVM/qemu + VirtualBox) with a small 
set of Fedora infra, including Koji+Bodhi.


Users can make "official" builds and then push them to the "repositories".

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Onboarding package



Dne 06. 10. 21 v 7:35 Otto Urpelainen napsal(a):

Stephen Snow kirjoitti 5.10.2021 klo 15.39:

we were initially discussing that it could be useful to have some
package one can experiment with without being too much worried about
the
result.

However, discussing this back and forth, we figured that it might
also
where new coming package maintainer could gradually gain experience
with
the packaging workflows. So the simplest tasks could be:

1) Add changelog entry into onboarding package and open PR with the
change. This would not require too many privileges. Alternatively
this
current Fedora contributors might be interested to send such PR ;)


I like this approach, but I was also thinking of a small tutorial/app
to actually package a piece of software as required, going through the
various steps but be a "fake" package that is only used to teach and
test with. This app could record the FAS user ID and assign a badge to
it once they complete the tutorial successfully. Sort of a base
starting point for all new packagersd that give both them some
confidence going in and the sponsors some confidence too about the
level of the new committers capabilities.


Well, in the Quick Docs, we already have Creating RPM packages [1]. It 
has subpage "Publishing your software on Copr", which somehow covers 
the publishing aspect. But honestly, when I was starting out, I spent 
some time with those instructions, but could not understand them or 
complete the tutorials. So one thing would be to revisit these 
instructions and make the better — there is a task about moving them 
over to Package Maintainer Docs [2], it was in progress at some point, 
but apparently stalled now. After that, improvement could happen.


About every packager publishing their own test package, in Copr that 
can be done for sure. If it is deemed too far from the official Fedora 
repositories, the perhaps it could be done in staging. I have never 
really used it, I cannot say if that is a good idea or not.


A similar but different idea I have is to create a "Fedora Packaging 
Guidelines Web Course" that you can complete by yourself. It could be 
implemented as a Git repository. For each entry in the the Review 
Guidelines [3], there would be a directory with a specfile and a srpm. 
For simplicity, we could first implement cases which fedora-review can 
check automatically. The student's assignment would be to run 
fedora-review on the specfile, find the error it gives, refer to the 
Packaging Guidelines to figure out how to fix it, modify the specfile 
as needed and run fedora-review again to check their answer. The 
assignment is completed when fedora-review does not complain any more.


Later, the course could be expanded also to cases where there is no 
automated check available, either by involving a mentor, or simply by 
adding a SOLUTION file.


Awarding a badge for completing this course would be a good idea, if a 
technical solution can be found.


I see this course as complementary to Vít's original proposal about 
the onboarding package. The orboarding package tasks are about 
learning the build system, certainly a required skill for packages. 
The course is about learning the Guidelines. Currently the recommended 
method to do that is to submit inofficial reviews to live Review 
Requests. That has the advantage of exposing the applicant to real 
packages with real problems, but 1) has no guarantee of producing an 
effective learning path, the package that is picked may well be a very 
tricky case and thus unsuitable for starting out and 2) is 
psychologically unsafe, because a total newcomer must participate in 
discussion of two experts who are actually trying to get a package 
into Fedora, not educating the packagers.



Just FTR, I like these ideas. Nevertheless, as with every idea, they 
need to be implemented and maintained. Therefore, from the experience, I 
think that onboarding package could survive longer, because it 
(hopefully) needs less maintenance.



Vít





[1]: 
https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/

[2]: https://pagure.io/fedora-docs/package-maintainer-docs/issue/19
[3]: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process



packager to be already sponsored and they could go through the whole
process themeselves just with some light guidance if needed.

This could be extended in the future. E.g. next step could be:

3) Submit module update.

Apart from gaining experience, this could also help with the common
question "where should I start". And of course our sponsoring
guidelines
could be refreshed suggesting/requesting to take these steps at some
point.

Thoughts?


Personnaly I am for this type of approach since it is also clarifying
the roles a bit more too. It wouldn't hurt to outline what is expected
of a packager of Fedora Linux in general. You know expectations are
very often left unsaid thinking that roles and responsibilities

Fedora-Cloud-33-20211006.0 compose check report

2021-10-06 Thread Fedora compose checker

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-33-20211005.0):

ID: 1015731 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1015731
ID: 1015739 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1015739

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Onboarding package

2021-10-06 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Oct 06, 2021 at 09:39:46AM +0200, Vít Ondruch wrote:
> 
> Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a):
> >On Tue, 5 Oct 2021 at 11:28, Matthew Miller  wrote:
> >>On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote:
> Is this really necessary?
> >>>Yes. Because anyone can add something like this:
> >>>%post
> >>>rm -rf /
> >>>
> >>>And it will destroy the installed system or even the hardware.
> >>Yeah, but... that's not going get through the PR process? In fact, that
> >>specific thing should fail in CI before a human gets to it even.
> >>
> >>Overall, we put a lot of trust in maintainers. I don't see this _particular_
> >>route as a likely one for violating that trust.
> >>
> >I think part of the problem is that I don't think the proposal has
> >enough flesh on its bones for people not to see it causing all kinds
> >of problems somewhere. Or vice versa seeing not enough to see it being
> >worthwhile for a beginner. [For many a developer, PR's aren't that
> >interesting to most developers and not what they think about when
> >looking at packaging. Running fedpkg and making a spec file work on my
> >system and through the complicated koji+bodhi+mbs+.. stack is real
> >packaging.] So we need a real proposal with an end to end idea of what
> >is being done, what is to be learned, and how it is to be 'watched' by
> >real developers to make sure people are learning things.
> >
> >
> 
> This was proposed in the "release early, release often" spirit. So I
> am glad for the generally positive feedback for this idea and I also
> appreciate the concerns which were risen.
> 
> And as I said, this targets the newcomers, so start with the PR is
> probably the right thing to do. But even "start with PR" has more
> degrees of freedom, e.g. should the contributors modify the
> changelog manually or should the `%autorelease` / `%autochangelog`
> be used as proposed by Matt? Maybe this could be two scenarios after
> all. But it is hard to judge where the line is between being useful
> to learn something and being tedious, boring, unattractive or
> discouraging.

I'd very much lean on the side of %autorelease/%autochangelog.
That workflow isn't perfect yet, but it's certainly the feature, and
in general, newcomers should learn the new workflows.
(There's also the issue raised by Matt that with traditional
%changelog pretty much each and every parallel pull request would
conflict.)

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Onboarding package