Re: Incredible lag of koji notifications

2022-01-25 Thread Kevin Fenzi
On Tue, Jan 25, 2022 at 09:53:10AM +0100, Vitaly Zaitsev via devel wrote:
> On 24/01/2022 21:53, Kevin Fenzi wrote:
> > We have a number of ideas how to improve this situation and hopefully we
> > will get to doing some of that soon.
> 
> Is it possible to completely disable build notifications for my packages? I
> think it's better to get nothing than to get dozens of late emails a week
> later.

Sure. Go to: 

https://apps.fedoraproject.org/notifications/

login and disable both email and irc. 

kevin


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


Re: mass rebuild status - 2022-01-25

2022-01-25 Thread Kevin Fenzi
On Tue, Jan 25, 2022 at 08:39:31PM +0100, Iñaki Ucar wrote:
> On Tue, 25 Jan 2022 at 19:13, Kevin Fenzi  wrote:
> >
> > Greetings.
> >
> > The mass rebuild finished it's first pass on saturday morning, leaving
> > 3448 failed builds.
> >
> > We then did a second pass yesterday ( 2022-01-24 ) of all failed builds,
> > and that resulted in 1282 failed builds.
> >
> > The f36-rebuild tag is being merged now, but unfortunately our SOP had
> > it merge via f36-signing-pending, so all the builds will pass through
> > signing again, which will be a slow process. We have updated docs and
> > next time will be just tagging directly into the final tag and signing
> > along the way.
> >
> > There's a gcc build currently going that has fixes for some common
> > issues that caused failures on ppc64le builds along with some other
> > fixes. As soon as it's done we are going to do another pass of
> > resubmitting the failed builds and will tag any that finish there.
> >
> > After that we will be done and it will be on maintainers to sort out
> > FTBFS issues.
> 
> What do we do with the FTBFS issues filed as a result of the ppc64le
> issues? Do we close them, or are they gonna be closed automatically if
> the second pass succeeds?

Go ahead and close them... they would get closed at some point, but
better to close them while you were there.

kevin


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


Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

2022-01-25 Thread Kevin Fenzi
On Fri, Jan 21, 2022 at 04:08:04PM +, Roberto Sassu via devel wrote:
> Hi everyone
> 
> (note for the infrastructure mailing list: please check if the changes
> I'm proposing could be tested in the Fedora infrastructure, like Copr)

copr uses a different signing setup... so probibly won't work there. 

We could perhaps work with you to try and get it in our staging env to
test, but I am not sure how involved that might be. I guess the first
step would be filing a infratructure ticket and explain what you would
need to change/test.

So, question for the change owners:

This is not enabled by default, I assume you wish to enable it for
something, can you expand on what you will use it for and what that
helps you with?

Also, is there any plan to enable it by default? Is there some way this
could be useful to all our users? or more of our users?

This change and the DIGLIM change both feel to me like we are spending
time and effort enabling something that only helps a tiny fraction of
our users. Is there some way this could be more generally useful to our
users?

kevin


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


mass rebuild status - 2022-01-25

2022-01-25 Thread Kevin Fenzi
Greetings. 

The mass rebuild finished it's first pass on saturday morning, leaving
3448 failed builds.

We then did a second pass yesterday ( 2022-01-24 ) of all failed builds,
and that resulted in 1282 failed builds. 

The f36-rebuild tag is being merged now, but unfortunately our SOP had
it merge via f36-signing-pending, so all the builds will pass through
signing again, which will be a slow process. We have updated docs and
next time will be just tagging directly into the final tag and signing
along the way. 

There's a gcc build currently going that has fixes for some common
issues that caused failures on ppc64le builds along with some other
fixes. As soon as it's done we are going to do another pass of
resubmitting the failed builds and will tag any that finish there.

After that we will be done and it will be on maintainers to sort out
FTBFS issues. 

kevin


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


mass rebuild status - 2022-01-25

2022-01-25 Thread Kevin Fenzi
Greetings. 

The mass rebuild finished it's first pass on saturday morning, leaving
3448 failed builds.

We then did a second pass yesterday ( 2022-01-24 ) of all failed builds,
and that resulted in 1282 failed builds. 

The f36-rebuild tag is being merged now, but unfortunately our SOP had
it merge via f36-signing-pending, so all the builds will pass through
signing again, which will be a slow process. We have updated docs and
next time will be just tagging directly into the final tag and signing
along the way. 

There's a gcc build currently going that has fixes for some common
issues that caused failures on ppc64le builds along with some other
fixes. As soon as it's done we are going to do another pass of
resubmitting the failed builds and will tag any that finish there.

After that we will be done and it will be on maintainers to sort out
FTBFS issues. 

kevin


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


Re: Incredible lag of koji notifications

2022-01-24 Thread Kevin Fenzi
On Mon, Jan 24, 2022 at 02:44:21PM -0600, Ron Olson wrote:
> Hey all, I _just_ got an email for my failed job from koji
> (https://koji.fedoraproject.org/koji/taskinfo?taskID=81627145). The job
> started (and finished) on Friday the 21st and yet I just got the email about
> five minutes ago. Is something going on, or is this a normal amount of time?

It's the mass rebuild. 

FMN can't handle the volume, it gets behind. Sometimes it stops
processing. ;( 

We have a number of ideas how to improve this situation and hopefully we
will get to doing some of that soon. 

kevin


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


Re: mass rebuild status - 2022-01-24

2022-01-24 Thread Kevin Fenzi
On Mon, Jan 24, 2022 at 08:08:25PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 24, 2022 at 08:00:31PM +0100, Vitaly Zaitsev via devel wrote:
> > On 24/01/2022 19:06, Kevin Fenzi wrote:
> > > This seems kind of high, so we are going to resubmit all the failed
> > > builds in a short second round to reduce the chance of transitory issues
> > > causing the build failures.
> > 
> > I think the ppc64 GCC regressions should be fixed first.
> 
> Yeah.
> The current state is that both the ppc64le long double related bugs have
> been discussed with IBM, I have patches for both, bootstrapping/regtesting
> them now on GCCFarm and am also doing a scratch koji build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81773481
> If the first testing looks ok, will submit them for upstream review,
> if that is approved tonight or tomorrow will include those in tomorrow's
> gcc rebuild (unlike the scratch build, that will include various other
> fixes).  But ETA from the build start is ~ 20 or more hours, so Wednesday.

That seems long to wait for mass rebuild merging. I'd like to start
trying to get composes and get the rebuilt packages out so people can
start testing them/fixing fallout from the rebuild.

Perhaps we could merge today and then do another pass of failed builds
into f36-rebuild tag and merge that back on thursday or something?
Can we easily identify those builds that failed due to these ppc64le
issues?

kevin


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


mass rebuild status - 2022-01-24

2022-01-24 Thread Kevin Fenzi
The mass rebuild finished early saturday morning. 

This resulted in 3448 failed builds.

This seems kind of high, so we are going to resubmit all the failed
builds in a short second round to reduce the chance of transitory issues
causing the build failures.

It's expected that should finish later today and we will tag f36 rebuild
into f36.

kevin


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


Re: s390 ruby build failure

2022-01-21 Thread Kevin Fenzi
On Fri, Jan 21, 2022 at 12:20:48PM +0100, Vít Ondruch wrote:
> 
> 
> I can't do that:
> 
> 
> ~~~
> 
> $ koji save-failed-tree 81534987
> 2022-01-21 12:20:12,267 [ERROR] koji: ActionNotAllowed: Only owner of failed
> task or 'admin' can run this task.

And sadly due to the mass rebuild churn it's already not available: 

 ~ koji save-failed-tree 81534987
Created task 81611235 for buildroot 32534387
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=81611235
Watching tasks (this may be safely interrupted)...
81611235 saveFailedTree (noarch): assigned
81611235 saveFailedTree (noarch): assigned -> FAILED: GenericError: Buildroot 
directory is missing: /var/lib/mock/f36-build-32534387-4400356/root/builddir
  0 free  0 open  0 done  1 failed

81611235 saveFailedTree (noarch) failed

I'd suggest just doing a scratch build and in that spec dumping out the
files you need for debugging.

kevin


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


Re: F36 Change: DIGLIM (System-Wide Change proposal)

2022-01-21 Thread Kevin Fenzi
On Wed, Jan 19, 2022 at 11:34:28AM +, Roberto Sassu via devel wrote:
> > From: Roberto Sassu
> > Sent: Tuesday, January 18, 2022 3:36 PM
> > Hi everyone
> > 
> > I recently sent to the kernel mailing lists a patch set to support
> > PGP keys and signatures.
> > 
> > Other than allowing the appraisal of RPM headers without
> > changes to the building infrastructure, it would also simplify
> > key management for the use cases requiring file or fsverity
> > signatures (no need for a secondary key).
> > 
> > This is the link of the patch set:
> > 
> > https://lore.kernel.org/linux-integrity/2022080318.591029-1-
> > roberto.sa...@huawei.com/
> > 
> > One point of the discussion was if there is the need to support
> > PGP in the kernel, or if a distribution should adapt its key
> > management to be compatible with key types currently available
> > in the kernel.
> 
> I have a question related to this. Is the private key used to sign
> kernel modules available also when other packages are built?

Nope. My understanding is that this is only available during that kernel
build and then disguarded. (But you could perhaps ask on fedora's kernel
list about it for more info). 

kevin


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


Fedora 36 Mass Rebuild

2022-01-19 Thread Kevin Fenzi
Hi all,

Per the Fedora 36 schedule[1] we have started a mass rebuild for Fedora 36
on Jan 19th, 2021. We will run a mass rebuild for Fedora 36 for the
changes listed in:

https://pagure.io/releng/issues?status=Open=mass+rebuild

The mass rebuild will be done in a side tag (f36-rebuild) and moved over
when completed.

Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f36-failures.html


Things still needing rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f36-need-rebuild.html


FTBFS bugs will be filed shortly after the mass rebuild is complete.

Please be sure to let releng know if you see any bugs in the
reporting. You can contact releng in #fedora-releng on Libera.Chat, by
dropping an email to our list[2] or filing an issue in pagure[3]

Regards,

Kevin

[1] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/


signature.asc
Description: PGP signature
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@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 36 Mass Rebuild

2022-01-19 Thread Kevin Fenzi
Hi all,

Per the Fedora 36 schedule[1] we have started a mass rebuild for Fedora 36
on Jan 19th, 2021. We will run a mass rebuild for Fedora 36 for the
changes listed in:

https://pagure.io/releng/issues?status=Open=mass+rebuild

The mass rebuild will be done in a side tag (f36-rebuild) and moved over
when completed.

Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f36-failures.html


Things still needing rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f36-need-rebuild.html


FTBFS bugs will be filed shortly after the mass rebuild is complete.

Please be sure to let releng know if you see any bugs in the
reporting. You can contact releng in #fedora-releng on Libera.Chat, by
dropping an email to our list[2] or filing an issue in pagure[3]

Regards,

Kevin

[1] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/


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


Re: hiredis soname bump

2022-01-19 Thread Kevin Fenzi
Thanks for the fixes. 

I went ahead and merged the side tag because the broken by gcc packages
will be broken by the mass rebuild anyhow. :( 

I'll try and poke at them some more next weekend...

kevin


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


Re: Self Introduction: Malcolm Inglis (mcinglis)

2022-01-18 Thread Kevin Fenzi
On Tue, Jan 18, 2022 at 08:31:05AM +0200, Otto Urpelainen wrote:
> Thank you, this is great!
> 
> Those two seem to contradict each other:
> 
> # If you are a new packager seeking sponsorship via new package or reviews
> # please close this
> 
> and
> 
> # If you are a new packager seeking sponsorship after your new package
> submission
> # was approved, please note the link to that review and your background here
> # for sponsors to review.

Well, the first was intended to tell people to first get a package
approved before filing a ticket. Otherwise they would file the
sponsorship ticket before they even filed a review or before it's
approved and then the ticket would have to wait and clog up the tracker. 

> For the re-reviewing of orphaned packages, I opened a FESCo ticket [1] so it
> can be properly added to relevant policies, or have the decision logged that
> those should not be required.
> 
> [1]: https://pagure.io/fesco/issue/2734

ok. 

I'll comment there. 

Thanks for helping document all this better!

kevin


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


Re: hiredis soname bump

2022-01-17 Thread Kevin Fenzi
On Mon, Jan 17, 2022 at 10:44:57AM +1100, Nathan Scott wrote:
> On Mon, Jan 17, 2022 at 10:35 AM Iñaki Ucar  wrote:
> > On Mon, 17 Jan 2022 at 00:21, Nathan Scott  wrote:
> > > On Mon, Jan 17, 2022 at 7:05 AM Kevin Fenzi  wrote:
> > > >
> > > > Greetings.
> > > >
> > > > We currently have hiredis-0.13.3-16 in rawhide, I'd like to upgrade to
> > > > 1.0.2, which includes a soname bump.
> > >
> > > I think upstream may have reverted this change FWIW ...
> > > https://github.com/redis/hiredis/issues/990
> >
> > This refers to the incorrect SONAME bump in 1.0.1 with respect to
> > 1.0.0. But as Kevin said, we still have 0.13.3 in Fedora, so...
> 
> Aha - right you are, thanks for the correction.

ok, so I made the sidetag (f36-build-side-49618) and rebuilt things, 
but of course now there's 4 more erroring packages (I guess due to gcc12?).
Any help welcomed. :) 

(bccing maintainers)

gearmand
https://koji.fedoraproject.org/koji/taskinfo?taskID=81386050
...
./gear_config.h:35:25: error: conversion from 'int' to 'const std::string' {aka 
'const std::__cxx11::basic_string'} is ambiguous

sems
https://koji.fedoraproject.org/koji/taskinfo?taskID=81386117
...
/builddir/build/BUILD/sems-baad4717fdb3c02a63eb4869f31ec33ff8ec1fed/core/tests/fct.h:267:12:
 error: '__builtin_strncpy' specified bound 256 equals destination size 
[-Werror=stringop-truncation]

seqan3
https://koji.fedoraproject.org/koji/taskinfo?taskID=81386062
/builddir/build/BUILD/seqan3-3.1.0/include/seqan3/utility/concept/exposition_only/core_language.hpp:67:5:
 error: testing if a concept-id is a valid expression; add 'requires' to check 
satisfaction [-Werror=missing-requires]
   67 | std::convertible_to= v1), bool>;

suircata
https://koji.fedoraproject.org/koji/taskinfo?taskID=81386008
   Compiling suricata v6.0.4 (/builddir/build/BUILD/suricata-6.0.4/rust)
/usr/lib/librustc_driver-f074454651f889f4.so(+0x4d3083)[0xf3c95083]
linux-gate.so.1(__kernel_sigreturn+0x0)[0xf7f9a570]
/usr/lib/libLLVM-13.so(+0xf564fe)[0xee3684fe]
/usr/lib/libLLVM-13.so(+0xf586ae)[0xee36a6ae]
/usr/lib/libLLVM-13.so(+0x104900f)[0xee45b00f]
/usr/lib/libLLVM-13.so(_ZN4llvm18ScheduleDAGSDNodes12EmitScheduleERNS_26MachineInstrBundleIteratorINS_12MachineInstrELb0EEE+0x382)[0xee45a1a2]
/usr/lib/libLLVM-13.so(_ZN4llvm16SelectionDAGISel17CodeGenAndEmitDAGEv+0xa2a)[0xee532fca]
/usr/lib/libLLVM-13.so(_ZN4llvm16SelectionDAGISel16SelectBasicBlockENS_14ilist_iteratorINS_12ilist_detail12node_optionsINS_11InstructionELb0ELb0EvEELb0ELb1EEES6_Rb+0x303)[0xee532543]
/usr/lib/libLLVM-13.so(_ZN4llvm16SelectionDAGISel20SelectAllBasicBlocksERKNS_8FunctionE+0x2204)[0xee531d14]
/usr/lib/libLLVM-13.so(_ZN4llvm16SelectionDAGISel20runOnMachineFunctionERNS_15MachineFunctionE+0xc22)[0xee52e932]
/usr/lib/libLLVM-13.so(+0x37b98e1)[0xf0bcb8e1]
/usr/lib/libLLVM-13.so(_ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE+0x14b)[0xedfddd0b]
/usr/lib/libLLVM-13.so(_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x598)[0xedd407d8]
/usr/lib/libLLVM-13.so(_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x48)[0xedd48148]
/usr/lib/libLLVM-13.so(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x43b)[0xedd40fdb]
/usr/lib/libLLVM-13.so(_ZN4llvm6legacy11PassManager3runERNS_6ModuleE+0x2b)[0xedd484fb]
/usr/lib/librustc_driver-f074454651f889f4.so(+0x5702ed)[0xf3d322ed]
/usr/lib/librustc_driver-f074454651f889f4.so(+0x8752aa)[0xf40372aa]
/usr/lib/librustc_driver-f074454651f889f4.so(+0x87aefe)[0xf403cefe]
/usr/lib/librustc_driver-f074454651f889f4.so(+0x893167)[0xf4055167]
/usr/lib/librustc_driver-f074454651f889f4.so(+0x88c6e4)[0xf404e6e4]
/usr/lib/librustc_driver-f074454651f889f4.so(+0x7a91a3)[0xf3f6b1a3]
/usr/lib/librustc_driver-f074454651f889f4.so(+0x820c27)[0xf3fe2c27]
/usr/lib/libstd-1c430345c3146024.so(rust_metadata_std_6938c2bdeba667b5+0x9d37b)[0xf36d537b]
/usr/lib/libc.so.6(+0x8baf1)[0xf34d9af1]
/usr/lib/libc.so.6(+0x1118cc)[0xf355f8cc]
error: could not compile `suricata`

kevin


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


Re: Self Introduction: Malcolm Inglis (mcinglis)

2022-01-17 Thread Kevin Fenzi
On Mon, Jan 10, 2022 at 10:47:13AM -0800, Kevin Fenzi wrote:
> On Mon, Jan 10, 2022 at 11:07:33AM +0100, Vít Ondruch wrote:
> > 
> > Just FTR, I don't think that as a sponsor, I can close the ticket and that
> > is a bit discouraging.
> 
> There's no way to tell pagure.io "everyone in the fedora packager group
> thats a manager is a admin here", so I have manually been adding any
> sponsor who replies to a ticket. 
> 
> I suppose if we wanted we could manually list everyone out and add them
> and then add new folks as they became sponsors. 
> 
> > > Additionally, I fear it would also leed to 'HI, make me a packager' type
> > > tickets (with no other info). We could of course close those or ask for
> > > more info, but then someone has to manage that.
> > 
> > 
> > You have already volunteered for providing the template, that should help to
> > solve this.
> 
> Hopefully. :)

ok. I have a first cut of a template there now. 

Open a new issue and you should see it. 

Happy to accept changes/additions/fixes via direct email or here. 

kevin


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


koji hubs and builders updated

2022-01-16 Thread Kevin Fenzi
Just thought I would share that (finally) we have completed upgrades on
the koji hubs and builders.

The hubs have been upgraded to Fedora 35 and
the latest koji version (1.17.1).

Builder hypervisors have been upgraded to RHEL8.5 and the latest
advanced virt stack. Builders have been upgraded/reimaged to Fedora 35
and the latest packages. 

On armv7 builders: As you all know due to 
https://bugzilla.redhat.com/show_bug.cgi?id=1920183
( Overeager OOM kills on 5.10 kernels on 32bit arm with lpae )
we had been running an old kernel on them, but after some testing in
staging it seemed that the upcoming 5.16 kernel worked pretty well. 
So, All of them are running that now. There have been some OOM kills
already, I'm playing around with options on them to try and get that
number to 0. Hopefully they will be ok for the mass rebuild. 

On s390x builders: We got some more resources, so the kvm builders now
have more memory and cpus. I've asked for some more disk space and once
we have that I plan to spread those resources out to have 2x as many
builders (ie, now: 4 cpus, 20gb mem x 10, after: 2 cpus, 10gb mem x 20)
I don't know if this will be done in time for the mass rebuild, but
hopefully so. 

On ppc64le: We have some more power9 hardware waiting to be put in
service, so we should be adding some builders here, and/or spreading out
resources. 

Thanks for everyone's patience with builds that have been taking a while
or restarting. Do continue to report them and we will do the best we can
to fix things. 

kevin


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


koji hubs and builders updated

2022-01-16 Thread Kevin Fenzi
Just thought I would share that (finally) we have completed upgrades on
the koji hubs and builders.

The hubs have been upgraded to Fedora 35 and
the latest koji version (1.17.1).

Builder hypervisors have been upgraded to RHEL8.5 and the latest
advanced virt stack. Builders have been upgraded/reimaged to Fedora 35
and the latest packages. 

On armv7 builders: As you all know due to 
https://bugzilla.redhat.com/show_bug.cgi?id=1920183
( Overeager OOM kills on 5.10 kernels on 32bit arm with lpae )
we had been running an old kernel on them, but after some testing in
staging it seemed that the upcoming 5.16 kernel worked pretty well. 
So, All of them are running that now. There have been some OOM kills
already, I'm playing around with options on them to try and get that
number to 0. Hopefully they will be ok for the mass rebuild. 

On s390x builders: We got some more resources, so the kvm builders now
have more memory and cpus. I've asked for some more disk space and once
we have that I plan to spread those resources out to have 2x as many
builders (ie, now: 4 cpus, 20gb mem x 10, after: 2 cpus, 10gb mem x 20)
I don't know if this will be done in time for the mass rebuild, but
hopefully so. 

On ppc64le: We have some more power9 hardware waiting to be put in
service, so we should be adding some builders here, and/or spreading out
resources. 

Thanks for everyone's patience with builds that have been taking a while
or restarting. Do continue to report them and we will do the best we can
to fix things. 

kevin


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


hiredis soname bump

2022-01-16 Thread Kevin Fenzi
Greetings. 

We currently have hiredis-0.13.3-16 in rawhide, I'd like to upgrade to
1.0.2, which includes a soname bump. 

I plan to make a side tag and build dependent packages the next few
days.

I've rebuilt everything in a copr:
https://copr.fedorainfracloud.org/coprs/kevin/hiredis/builds/

The two failures were rsyslog and opensips, but they both fail the same
way in rawhide. 

dependent packages are:

alexandria
ccache  
collectd
coturn  
gawk-redis  
gearmand
icecat  
idzebra 
minetest
minetestmapper  
opensips
php-phpiredis   
rsyslog 
sems
seqan3  
subtitleeditor  
suricata
syslog-ng   
tellico 
yaz 
zmap

kevin


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


Re: Workflow and other problems with the Fedora container infrastructure

2022-01-15 Thread Kevin Fenzi
On Thu, Jan 13, 2022 at 02:14:19PM -0500, Neal Gompa wrote:
> 
> One of the things that has recently happened in the Koji space is the
> addition of a kiwi-build task to build images using the KIWI tool[1].
> 
> KIWI supports building all kinds of operating system images, including
> OCI containers. The Fedora Cloud WG is poking at the idea of using
> KIWI for the cloud image to replace the unmaintained and brittle
> ImageFactory, and we could also look at doing container builds with
> KIWI to replace the OpenShift Atomic Reactor system. That would
> drastically simplify the architecture and make container image builds
> considerably more reasonable for the Container SIG and any other
> stakeholders.

Yeah, thats quite interesting. I would be happy to move to a pipeline
thats less fragile here. :) 

There's also talk about moving things to use ImageBuilder, but I don't
think it does containers. 

kevin


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


Re: Workflow and other problems with the Fedora container infrastructure

2022-01-13 Thread Kevin Fenzi
On Thu, Jan 13, 2022 at 02:43:50PM +0100, Honza Horak wrote:
> On Wed, Jan 12, 2022 at 5:51 AM Kevin Fenzi  wrote:
> 
> > On Tue, Jan 11, 2022 at 01:02:59PM +0100, Lumír Balhar wrote:
> > > If we migrate our container images to some other registry (e.g. a common
> > > fedora space on quay.io), we’ll be able to rebuild them after every
> > merged
> > > PR or every week, do chain rebuilds and push them to the registry
> > directly
> > > from Github CI. This will make our lives significantly easier, and in
> > turn
> > > our images better.
> >
> > We are looking into dropping out registry and moving to quay.io
> > ourselves. ;)
> >
> >
> Is this something more than a thought at this point? Something where we can
> follow the design and progress?


We have https://pagure.io/fedora-infrastructure/issue/10386
tracking it. It's definitely something we want to do, but not sure when
we will get to it. 

> > > Are there any benefits to using Fedora infrastructure and Fedora
> > containers
> > > registry which I don’t see that we should consider?
> >
> > I'm not sure... hopefully folks who know the pipeline will chime in
> > here.
> >
> 
> If you know who the folks are, we'd be glad for a gentle ping, so they
> comment here and we do not stop providing something that other would start
> to miss.

Perhaps the Fedora CoreOS folks would have some thoughts?

kevin


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


Re: Bugzilla email confirmation notices from FAS

2022-01-11 Thread Kevin Fenzi
On Tue, Jan 11, 2022 at 11:58:36AM -0500, Christopher wrote:
> Hi,
> 
> Today, I received an email from f...@fedoraproject.org with the subject
> line "Fedora Account System: please verify your Bugzilla email
> address". This email has a unique link to accounts.fedoraproject.org.
> 
> Based on the context, it seems legitimate. However, I noticed that
> clicking the link will take you to a sign-in page asking for
> credentials to your account. That seems strange to me, because it
> already has a unique link that's associated with the verification of a
> specific email in a specific FAS account, so asking for credentials
> should be completely unnecessary here. Asking for credentials makes
> this appear to be a phishing attempt, because that's how a phishing
> email would behave (appearance of legitimacy, requesting credentials
> when not needed).
> 
> I think the FAS developers should remove the requirement to sign-in
> for these verification emails, to reduce the appearance/behavior of
> phishing. The email itself says these emails are "To improve
> security". If that is a goal, then Fedora systems should avoid
> training users to supply credentials when not needed.

This was a one off thing, which I suggested we do to be nice and avoid
problems for people, but perhaps it was misguided and we shouldn't have
done it. 

We moved to a new account system last year, and it has a 'bugzilla'
field. Unfortunately, we didn't have cycles to start actually using that
field at the time we switched. Shortly after we started looking into
using it, but we realized that there was no validation for it. This
wouldn't be acceptable, so we implemented a verification setup on it
that was much like the one for the primary email address. 

However, 161 people had entered email addresses that were not their
primary ones. We were going to just clear them all out and announce that
folks with these should reenter and validate them, but I suggested we
could simply trigger a validation cycle on them. That would likely have
more folks see the email and validate it, where they might miss a
announcement. 

Anyhow, this was a one time script thing, it won't run again. 

kevin


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


Re: Workflow and other problems with the Fedora container infrastructure

2022-01-11 Thread Kevin Fenzi
On Tue, Jan 11, 2022 at 01:02:59PM +0100, Lumír Balhar wrote:
> Hello.
> 
> My name is Lumír and I maintain a few layered container images in
> Fedora/RHEL/upstream related to Python and S2I (source to image) platform -
> namely python3, s2i-core, and s2i-base.
> 
> TL;DR: We (maintainers of layered container images for languages, runtimes
> and databases) are considering migrating our images from Fedora
> infrastructure and Fedora containers registry somewhere else. Below are the
> reasons for that. If you think it’s a bad idea, let us know why. If you are
> a user of those images, let us know as well so we can stay in touch with
> you.
> 
> Forgive me for my wording but I’m really sad about the current situation.

yeah, it is sad. ;( 

> I have to honestly admit that I’m disappointed about the lack of attention
> containers in Fedora are getting. Maintaining them is painful,
> infrastructure is unstable and unreliable and there was literally no
> movement forward in recent years. Let me summarize it.
> 
> Container SIG is inactive. See important issues opened for years with no
> movement further: https://pagure.io/ContainerSIG/container-sig/issues
> 
> Even a simple task like merging rawhide branch to f35 for example is far
> from smooth because they are never the same, because manual changes are
> required for each branch:
> https://pagure.io/ContainerSIG/container-sig/issue/16 (3 years old, no
> reply)
> 
> S2I container images depend on each other (python3 -> s2i-base -> s2i-core)
> but there is no automation for chain rebuilds so if I want to update
> s2i-core image (to fix a CVE or something like that) and all dependant
> images, it takes weeks because I have to rebuild them one by one and let
> them one by one pass through Bodhi updates until I can rebuild next one in
> the queue. And it’s really frustrating given the insufficient stability of
> the infra. There seems to be a way how to make this faster, but nobody
> knows, how it works: https://pagure.io/ContainerSIG/container-sig/issue/52
> and https://github.com/containerbuildsystem/atomic-reactor/issues/1730
> 
> The same applies also if the fix is done on the RPM level because there are
> no freshmaker nor automated rebuilds.
> 
> The branching structure does not really fit container needs. I maintain the
> s2i Python container and I don’t really care whether it’s based on Fedora 34
> or 35 (both have Python 3.10 as the main one) so I’d ideally have one branch
> for Python 3.10, one for 3.9 etc. instead of two separated branches (f34,
> f35) where the Python is the same version.
> https://pagure.io/ContainerSIG/container-sig/issue/12 (3 years old)

Yeah, I think all the above is kind of a consequence of there not being
a active containers SIG. Infrastructure and releng doesn't really have
cycles or interest in driving containers forward, so it needs some other
folks attention. ;( 

> An example of unstable infrastructure: I’m not able to build an image for
> three weeks now and a response I got is to report the problem upstream:
> https://pagure.io/fedora-infrastructure/issue/10437
> I know that nothing is 100% reliable but if you take a look at these issues,
> there are a lot of them: 
> https://pagure.io/fedora-infrastructure/issues?search_pattern=container=Closed

Do note that that issue was filed on December 21st. 
Myself and much of the infrastructure team were off on holidays. 
I only got back yesterday and there's a ton of things to do, but I did
try and look into this some. 

The reason there's so many issues I think is because the entire pipeline
is just way overkill and complex for just building containers. Basically
we have to have koji, koji builders, and 2 openshift clusters (one for
x86 and one for aarch64) to build containers, they have all kinds of
fragile handoffs between each other as well. 

> And it seems that the packages in the infrastructure are outdated a lot: 
> https://github.com/containerbuildsystem/atomic-reactor/issues/1742#issuecomment-1009279161

To clarify, thats installed in the build container... so, _fedora_
packages are outdated. ;( I have seen atomic-reactor being old, but I've
been afraid to update it since I don't know the pipeline. 
Co-maintainers of those packages in Fedora would sure help out. 

> If we migrate our container images to some other registry (e.g. a common
> fedora space on quay.io), we’ll be able to rebuild them after every merged
> PR or every week, do chain rebuilds and push them to the registry directly
> from Github CI. This will make our lives significantly easier, and in turn
> our images better.

We are looking into dropping out registry and moving to quay.io
ourselves. ;) 

> Are there any benefits to using Fedora infrastructure and Fedora containers
> registry which I don’t see that we should consider?

I'm not sure... hopefully folks who know the pipeline will chime in
here. 

kevin


signature.asc
Description: PGP signature
___
devel 

Re: Self Introduction: Malcolm Inglis (mcinglis)

2022-01-10 Thread Kevin Fenzi
On Mon, Jan 10, 2022 at 11:07:33AM +0100, Vít Ondruch wrote:
> 
> Just FTR, I don't think that as a sponsor, I can close the ticket and that
> is a bit discouraging.

There's no way to tell pagure.io "everyone in the fedora packager group
thats a manager is a admin here", so I have manually been adding any
sponsor who replies to a ticket. 

I suppose if we wanted we could manually list everyone out and add them
and then add new folks as they became sponsors. 

> > Additionally, I fear it would also leed to 'HI, make me a packager' type
> > tickets (with no other info). We could of course close those or ask for
> > more info, but then someone has to manage that.
> 
> 
> You have already volunteered for providing the template, that should help to
> solve this.

Hopefully. :)

kevin


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


Re: Self Introduction: Malcolm Inglis (mcinglis)

2022-01-09 Thread Kevin Fenzi
On Sat, Jan 08, 2022 at 10:56:50PM +0200, Otto Urpelainen wrote:
> 
> Ok, I start to see this better now. I was under the impression that both
> FE-NEEDSPONSOR and the tracker were on equal footing and generally speakin,
> receive similar attention from the sponsors. But, if the reason for having
> the tracker is (or: originally was) just the co-maintainer requests, where
> the primary maintainer actually mentors the new packager, then it makes
> sense that just a couple of sponsors keep an eye on that tracker and accept
> the request on behalf of the primary maintainers.
> 
> > Additionally, I fear it would also leed to 'HI, make me a packager' type
> > tickets (with no other info). We could of course close those or ask for
> > more info, but then someone has to manage that.
> 
> One easy thing that can be done now is to add an issue template to the
> tracker repo.

Thats an excellent idea. I'll try and add one.
> 
> > > Apart from co-maintenance, the tracker is also important for the case 
> > > where
> > > somebody wants to become a pacakger to rescue an orphaned package.
> > 
> > Well, in the past we have asked such folks to file a review request and
> > get the orphaned package re-reviewed.
> 
> Interesting. Previously, there was no documented process for handling this
> case at all, so I wrote section "Adopting orphaned packages" [1] to How to
> Get Sponsored page. As you can see, that section currently points to the
> tracker. Do you think we should change that to ask for a re-review? The
> current wording is not just my invention, though. There was discussion on
> devel first, and the change went through a docs pull request.
> 
> In case a review is required, I would like to understand, why? My
> understanding was this: Orphaned packages are assumed to be is acceptable
> condition, because existing maintainers can adopt them without a review. The
> new packager are assumed to be equal to existing maintainers, because
> somebody has agreed to sponsor them and is available for mentoring as
> needed. Some caution is certainly needed, since some orphaned packages can
> be minefields, it just did not occur to me that package review would be the
> appropriate safeguard here.

I think the idea was that the person who wanted to take on the orphaned
package could suggest improvements to the existing package to prove that
they know guidelines, etc. At least it shows that they could show they
know the spec file and how to file a review, but I agree this is
somewhat 'make work'. 

kevin


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


Re: Unannounced soname bump of libre2

2022-01-08 Thread Kevin Fenzi
On Sat, Jan 08, 2022 at 11:56:04PM +0900, Mamoru TASAKA wrote:
> Miro Hrončok wrote on 2022/01/08 20:05:
> > On 08. 01. 22 11:39, Miro Hrončok wrote:
> > > The re2 package was updated today in Rawhide and bumped soname from 
> > > libre2.so.0a to libre2.so.9.
> > > 
> > > https://src.fedoraproject.org/rpms/re2/c/dafa514
> > > 
> > > Seven packages are broken:
> > > 
> > > dnsdist: https://bugzilla.redhat.com/show_bug.cgi?id=2038544
> > fails to build, not sure if re2 related
> 
> There is at least a fault on new re2, filed:
> https://bugzilla.redhat.com/show_bug.cgi?id=2038572
> 
> > > frr: https://bugzilla.redhat.com/show_bug.cgi?id=2038545
> > depends on grpc
> > 
> > > grpc: https://bugzilla.redhat.com/show_bug.cgi?id=2038546
> > fails to build due to another unrelated fails to install bug
> > 
> > > qt5-qtwebengine: https://bugzilla.redhat.com/show_bug.cgi?id=2038551
> > fails to build, re2 related

Just FYI, the qt5-qtwebengine breakage is breaking rawhide composes
starting today. ;( 

kevin


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


Re: Self Introduction: Malcolm Inglis (mcinglis)

2022-01-07 Thread Kevin Fenzi
On Fri, Jan 07, 2022 at 11:43:15PM +0200, Otto Urpelainen wrote:
> 
> I can give a couple of reasons why just using the packager-sponsors tracker
> always would be better. This is from the point of view of somebody who had
> to find a sponsor. I am not a sponsor myself, so I do not really know this
> looks from that side.
> 
> 1. The process is currently so complicated that newcomers are frequently
> confused and dissuaded by it. Having just a single way would make it
> simpler. Of these two options, the single way would have to be the tracker,
> because the FE-NEEDSPONSOR method only works for new package submissions.
> 
> 2. In the tracker, you can write your "letter of application" in the
> description, and add all the proof you have. So you can first evaluate
> yourself, gather more proof if you think it will be needed, and only submit
> an application when you feel you are ready. For FE-NEEDSPONSOR, it is not so
> clear. The same thing can be done in the review request comments, of course.
> But then the review request and the sponsorship request get mixed up, but
> actually they are two different things.
> 
> 3. It may be just my impression, but the system of adding the FE-NEEDSPONSOR
> link feels a bit like "don't call us, we'll call you". Saying that you can
> file an issue and it will be looked at feels more friendly and inviting.

Sure, I agree with all of that. However, If everyone who wanted to be
added to packager was told to file a issue, I am not at all sure we
can promise 'it would be looked at'. All the packager-sponsors tickets
go to everyone in the packager sponsors group, but I've only ever seen a
small fraction of them respond to any tickets. ;( I am not sure if thats
because they don't want to deal with sponsoring co-maintainers (the
current 'reason' to file a ticket there) or something else, but I worry
that it would just result in a big backlog of tickets there. :( 

Additionally, I fear it would also leed to 'HI, make me a packager' type
tickets (with no other info). We could of course close those or ask for
more info, but then someone has to manage that. 
> 
> Apart from co-maintenance, the tracker is also important for the case where
> somebody wants to become a pacakger to rescue an orphaned package.

Well, in the past we have asked such folks to file a review request and
get the orphaned package re-reviewed. 

To be clear, I'm happy to try and adjust things to make it simpiler as
long as we have buy in from sponsors that they would work with the new
process. :) 

Thanks for the feedback... hopefully we can come out of this with a
newer better process.

kevin


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


Re: Self Introduction: Malcolm Inglis (mcinglis)

2022-01-07 Thread Kevin Fenzi
On Thu, Jan 06, 2022 at 10:25:50PM +, Inglis, Malcolm via devel wrote:
> Well, turns out https://pagure.io/packager-sponsors isn't allowing PRs.
> 
> I've pushed to a branch here with updates and dead-link-fixes for the README: 
> https://pagure.io/fork/mcinglis/packager-sponsors/tree/pr-readme-update 
> 
> @Kevin Fenzi , you're welcome to pull that (or use it) into the repo if you 
> think it looks good. Aside link fixes, it conditionalizes the blurb about 
> "don't apply for sponsorship unless you have packages that have gone through 
> package review process", which I think is what deterred me here.

Thanks for the PR! Pushed. 

Perhaps we could make things more clear here (or in the how to get
sponsored document). The intent is not to use the packager-sponsors
tracked for everyone who wants to be sponsored (although I suppose we
could consider doing that). It was only established for the cases where
someone wanted to add a co-maintainer and wasn't able to sponsor them
themselves or someone has a approved / reviewed package and no sponsor
lined up. I guess it makes sense to try and use it for any of the corner
cases that are not 'I don't intend to submit a new package but want to
be sponsored to do other things'. 

If that all makes sense...

kevin
--
> 
> Cheers,
> Malcolm
> 
> On Thu, 6 Jan 2022 21:30:02 +, Malcolm Inglis  wrote:
> > Thanks, Fabio!
> >
> > I'm sorry I missed the process to cut a ticket in packager-sponsors.
> > I've done that now: https://pagure.io/packager-sponsors/issue/511
> >
> > That doc page was one of the few I was bouncing around until I opted
> > to email this list. That page linked to the repo's README, which then
> > linked "Procedure for new packagers" to
> > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
> > , which linked back to the original doc page. That page had a section
> > on "How to find a sponsor", which seemed to imply I'd need to find a
> > sponsor to volunteer *before* moving ahead. Meanwhile, I noticed that
> > several 'Self Introduction' emails on this list had sought and
> > received sponsorship, so I figured this was a way that would work.
> >
> > It may help if said doc page elaborated the process, perhaps by
> > describing an example request, and if the README on
> > `packager-sponsors` was also elaborated and updated to not link to
> > dead wikis. I can try to send some PRs to help out there.
> >
> > I understood why `packager` membership is required for various
> > infrastructure access; it makes perfect sense to avoid managing
> > effectively-free-world-writable storage :) I don't believe I raised
> > any contention there. The PR that Maxwell linked seems very appealing,
> > though. It would be great if PRs with new sources from
> > non-packager-members could pass CI without any action from
> > maintainers.
> >
> > The problem that Maxwell raised about sources updates is not one that
> > I've experienced. I've had a PR with new sources be accepted as-is
> > just fine (
> > https://src.fedoraproject.org/rpms/python-prompt-toolkit/pull-request/1
> > ).  It's just that the CI run was failing (as per state of my other
> > outstanding PRs) until the maintainer stepped in.
> >
> > Cheers, Malcolm
> >
> > P.S. my apologies for letting my corporate mailserver rules mess up
> > the thread subject by adding '[EXTERNAL]'. I'll try to catch that in
> > future.
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Rawhide / systemd 250: kernel-install may place kernels and config in the wrong place

2022-01-05 Thread Kevin Fenzi
On Wed, Jan 05, 2022 at 05:36:56PM -0800, Adam Williamson wrote:
... snip ...
> So, my question is...do other Rawhide users have this problem, or is my
> system an outlier for some reason? I have not been able to figure out
> *what* created the problematic directories on my system. An earlier
> systemd rc may have created /boot/efi/(machine_id) if
> /boot/efi/loader/entries existed, but I don't know what might have
> created /boot/efi/loader/entries . I'm pretty sure I didn't do it
> myself, though.

I don't have those here at all on 2 rawhide laptops... one installed in
aug 2020 and one aug 2021.

I wonder if it's something to do with when they were installed?

kevin


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


Re: glibc-2.34.9000-33.fc36 untagged causing lots of dependency breakage

2022-01-03 Thread Kevin Fenzi
On Mon, Jan 03, 2022 at 11:37:53AM +0100, Florian Weimer wrote:
> * Kevin Fenzi:
> 
> > On Tue, Dec 28, 2021 at 10:07:25PM +0100, Florian Weimer wrote:
> >> * Kevin Fenzi:
> >> 
> >> > On Tue, Dec 28, 2021 at 09:54:39AM +0900, Mamoru TASAKA wrote:
> >> >> Hello:
> >> >> 
> >> >> Looks like glibc-2.34.9000-33.fc36 was tagged into f36 buildroot on 
> >> >> 2021-12-18,
> >> >> but very recently untagged from f36 buildroot.
> >> >> Many binary rpms rebuilt recently have "Requires: glibc >= 
> >> >> 2.34.9000-33.fc36"
> >> >> ( for example firefox has: 
> >> >> https://koji.fedoraproject.org/koji/rpminfo?rpmID=28655956 )
> >> >> and not looks like lots of packages cause dependency breakage, e.g.
> >> >> 
> >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=80543777
> >> >> 
> >> >> Is this intentional?
> >> >
> >> > Yes, I untagged it. I am trying to get a rawhide comppose to work. ;( 
> >> >
> >> > I guess I can tag it back... that requires is... unfortunate. 
> >> 
> >> I've added it based on feedback that partial rawhide upgrades are
> >> supposed to work.  It's a conservative approximation because we do not
> >> have per-symbol RPM version information.
> >
> > Can you expand on how that works? 
> > Every new glibc makes everything built against it require that version
> > or newer?
> 
> No, we do a bit better than that.  We look at the built binaries.  If
> any of them use the symbol version under development (GLIBC_2.35 in case
> of current rawhide), we add a >= dependency on the glibc version used
> for building.  During the Fedora 36 cycle, fewer GLIBC_2.35 symbols have
> been added, so I don't expect many packages receiving this versioned
> dependency that makes downgrades harder.

ok. That seems completely reasonable. 

I can't seem to get dnf repoquery to show me this, but I'll poke around
with it. (ie, it either gets everything that is satisfied with the glibc
version by the >, or nothing at all). 

kevin


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


Re: How do we announce new packages?

2022-01-02 Thread Kevin Fenzi
On Sat, Jan 01, 2022 at 12:23:49PM +0100, Dan Čermák wrote:
> Fabio Valentini  writes:
> 
> > On Sun, Dec 26, 2021 at 9:09 PM Matthew Miller  
> > wrote:
> >>
> >> On Sat, Dec 25, 2021 at 09:15:38PM +0100, Fabio Valentini wrote:
> >> > So ... maybe we could have a mailing list for this?
> >> >
> >> > Maybe "awesome-announce" or "the-new-shinyness" (I'm kidding! I'm bad
> >> > with names!) at lists.fedoraproject.org, where all Fedora contributors
> >> > could post the fancy new thing that they just made? Because we
> >> > definitely don't have a good place for announcements like that right
> >> > now (the community blog might be the right place for some of those,
> >> > but it is a higher barrier to actually write a blog post that gets
> >> > edited etc. instead of writing an e-mail to a mailing list).
> >>
> >> Hmmm.
> >>
> >> The Community Blog should have a pretty low barrier to entry. Are
> >> people feeling blocked by that? We should try to adjust if so.
> >>
> >> As it is, the bar is basically "is this appropriate for this site" and "is
> >> the categorization right", with the editorial pass mostly being for
> >> egregious problems. In other words, I don't think it's actually much more
> >> heavyweight than a moderated announce mailing list would be.
> >>
> >> But I also am not sure Community Blog is the right audience — that's
> >> intended to be contributor-facing, and this seems like something aimed to e
> >> more user-facing.
> >
> > Those are exactly my thoughts. I don't think there's a way for Fedora
> > contributors to "market" the cool new thing they've been working on to
> > *users* (or tech publications)?
> >
> > I mean, submitting a Change Proposal results in things getting
> > announced pretty publicly, but that does not fit for smaller changes,
> > or changes that are not specific to the next Fedora release.
> >
> > I know that some tech news websites follow discussions on the devel
> > list (and probably the announcement lists), but those are mostly not
> > really of interest to *users*, and there's no mailing list for "here's
> > a cool new feature!" that they can subscribe to. That might skew
> > newsworthy items more towards the "negative news" side of things, like
> > "this package is orphaned / retired" / "Is this maintainer still
> > responsive" etc., having more *positive* news to report on would be
> > nice for Fedora.
> 
> So how about we just create such a list, make it moderated, ensure that
> every post gets at least *some* proofreading and see how it works out?

I'm game... but that brings us to the hardest problem in computers: 
what do we name it? :) 

new-tech? noteable-changes? new-features?

And... who will moderate? Perhaps we could/should file a infra ticket on
the list and have interested parties add their names there?

kevin


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


Re: Copr - look back at 2021

2022-01-02 Thread Kevin Fenzi
On Thu, Dec 30, 2021 at 03:33:05PM +0100, Miroslav Suchý wrote:
> Let me sum up what the Copr team did during 2021:

Thanks so much for all your work in the last year!

kevin


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


Re: Koji notifications arriving days late

2022-01-02 Thread Kevin Fenzi
On Fri, Dec 31, 2021 at 10:25:31AM +0100, Julian Sikorski wrote:
> Hello,
> 
> is it a known problem that koji notifications arrive way too late? For

yes.

> example, I got mame build notifications in the wee hours today (31.12)
> wheras the builds completed around noon on the 29th:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1871260
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1871254
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1871253
> This does not seem normal. Is anybody seeing this too?

Everyone. :( 

The problem here is our notification system ( fmn ) has a number of
issues: 

* The current version is still python2 and crashes from time to time for
difficult to debug reasons. So, sometimes it has crashed and takes a bit
to realize it's not processing and get restarted. :( We do have a
python3 port almost ready to swap in. Once thats in at least we can
hopefully debug any crashes. I hope that will happen in the first
quarter. 

* The current version has issues processing when 'large' amounts of
messages flood the bus. Examples of this include:
- When a beta or final release is 'go' releng tags all the packages to
  record they were part of the release, so ~23k messages in a few
  minutes.
- when copr rebuilds all rubygems
- mass rebuilds, thats ~23*N messages
- Most recently, when epel9 branching opened, because say 200 packages
  branched quicky and merged every commit from rawhide into the epel9
  branch and each commit is a message. 

So, anyhow, I hope the python3 version will help out some, but really we
need to do a re-write of the application to better handle lots of
messages. The current app is... difficult to use, but super flexible. 
If we made it easier to use, simpliler, but some less flexable it could
help processing speed. There has also been talk about seeing if we can
just use rabbitmq for the heavy lifting here (ie, have queues for people
who customize messages with those topics and have rabbitmq sort them for
us), that might work or help.  I hope we can work on this this year.

kevin


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


Re: glibc-2.34.9000-33.fc36 untagged causing lots of dependency breakage

2022-01-02 Thread Kevin Fenzi
On Tue, Dec 28, 2021 at 10:07:25PM +0100, Florian Weimer wrote:
> * Kevin Fenzi:
> 
> > On Tue, Dec 28, 2021 at 09:54:39AM +0900, Mamoru TASAKA wrote:
> >> Hello:
> >> 
> >> Looks like glibc-2.34.9000-33.fc36 was tagged into f36 buildroot on 
> >> 2021-12-18,
> >> but very recently untagged from f36 buildroot.
> >> Many binary rpms rebuilt recently have "Requires: glibc >= 
> >> 2.34.9000-33.fc36"
> >> ( for example firefox has: 
> >> https://koji.fedoraproject.org/koji/rpminfo?rpmID=28655956 )
> >> and not looks like lots of packages cause dependency breakage, e.g.
> >> 
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=80543777
> >> 
> >> Is this intentional?
> >
> > Yes, I untagged it. I am trying to get a rawhide comppose to work. ;( 
> >
> > I guess I can tag it back... that requires is... unfortunate. 
> 
> I've added it based on feedback that partial rawhide upgrades are
> supposed to work.  It's a conservative approximation because we do not
> have per-symbol RPM version information.

Can you expand on how that works? 
Every new glibc makes everything built against it require that version
or newer?

> I can remove it again, but it has cut down the amount of “why can't I
> build my package locally” reports significantly (but then there are also
> fewer glibc symbol changes this cycle).

Hum, yeah... 

Ideally if we see a problem we would untag pretty quickly. 
This time it was different because it wasn't very clear at all that it
was caused by glibc until a bunch of digging. ;) 

kevin


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


Re: Fedora rawhide compose report: 20211229.n.1 changes

2021-12-29 Thread Kevin Fenzi
On Thu, Dec 30, 2021 at 12:47:56AM +, Fedora Rawhide Report wrote:
> OLD: Fedora-Rawhide-20211217.n.1
> NEW: Fedora-Rawhide-20211229.n.1

So, FYI, breakage here in composes was: 

- A glibc update broke 'ldconfig -p' on armv7 on 2021-12-17.
https://bugzilla.redhat.com/show_bug.cgi?id=2034715
This caused pyudev to not be able to figure out where the udev library
was to load it, and anaconda calls that, so the armv7 images failed the
compose. The problem change has been reverted.

- In the mean time, a libzstd update broke systemd on armv7.
https://bugzilla.redhat.com/show_bug.cgi?id=2035802
A fix has been built, although i686 may still be broken.

- And finally systemd-250 broke booting on aarch64
https://bugzilla.redhat.com/show_bug.cgi?id=2036145
This cased the aarch64 cloud image to fail to boot. 
I have untagged 250-1 and 250-2 for now.

Many thanks to all the maintainers who checked bugs and landed fixes/new
builds over the holidays.

kevin


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


Re: glibc-2.34.9000-33.fc36 untagged causing lots of dependency breakage

2021-12-27 Thread Kevin Fenzi
On Tue, Dec 28, 2021 at 09:54:39AM +0900, Mamoru TASAKA wrote:
> Hello:
> 
> Looks like glibc-2.34.9000-33.fc36 was tagged into f36 buildroot on 
> 2021-12-18,
> but very recently untagged from f36 buildroot.
> Many binary rpms rebuilt recently have "Requires: glibc >= 2.34.9000-33.fc36"
> ( for example firefox has: 
> https://koji.fedoraproject.org/koji/rpminfo?rpmID=28655956 )
> and not looks like lots of packages cause dependency breakage, e.g.
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=80543777
> 
> Is this intentional?

Yes, I untagged it. I am trying to get a rawhide comppose to work. ;( 

I guess I can tag it back... that requires is... unfortunate. 

kevin


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


Re: Rawhide builds failing for a while now

2021-12-27 Thread Kevin Fenzi
On Mon, Dec 27, 2021 at 05:34:52AM -, Reon Beon via devel wrote:
> What exactly is wrong?
> 
> https://koji.fedoraproject.org/koji/builds?state=3=-build_id

Well, thats the list of all failed builds in koji. There's various
different reasons for each of them to have failed...

For example, the kf* ones at the top right now are due to a missing
kaccounts-integration-devel of the needed version. 

You have to look at each build and drill down to whatever error it hit
that caused it to fail.

If you mean the rawhide composes that are failing thats due to two bugs: 
https://bugzilla.redhat.com/show_bug.cgi?id=2034715
(anaconda dies with a traceback on 32bit arm) 

and 

https://bugzilla.redhat.com/show_bug.cgi?id=2035812
(systemd-journald fails to start on 32bit arm). 

I've untagged some packages and am running another compose right now to
see if that gets things going. 

kevin


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


Re: s390x funkiness? (No route to host)

2021-12-19 Thread Kevin Fenzi
On Sun, Dec 19, 2021 at 07:40:00AM -0600, Richard Shaw wrote:
> I tried building twice just in case it was a one-off issue but it failed
> the same way with the s390x unable to connect?
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=80185813
> 
> Looks like I'm not the only one either:
> 
> https://pagure.io/fedora-infrastructure/issue/10431

The hypervisor in our kvm lpar crashed early this morning. ;( 

We rebooted it, but the networking isn't working right on it now. 
We have a ticket into mainframe folks to look into it, but likely that
won't be until tomorrow. 

In the mean time I have setup a new cache proxy in the zvm lpar and
s390x builds should complete fine there for now. 

kevin


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


Re: Request for sponsorship in fedora-contributor group

2021-12-15 Thread Kevin Fenzi
On Wed, Dec 15, 2021 at 09:27:42AM +, Roberto Sassu via devel wrote:
> Hello everyone
> 
> I have done some work in the integrity subsystem, called
> Digest Lists Integrity Module (DIGLIM).
> 
> It simplifies the effort necessary to do IMA appraisal, by
> reusing the digests included in the header of existing
> RPM packages as reference values. It wouldn't require
> any change in the building infrastructure.
> 
> It also provides an alternative way of attesting systems,
> by keeping the TPM PCR extended with software
> measurements, stable and predictable. The main benefit
> is the ability to seal a TPM key to the desired software
> configuration, so that a TLS secure communication can
> be established when only software from installed RPMs
> is executed. It would be possible to integrate this solution
> in Keylime.
> 
> I have proposed this feature for upstream inclusion:
> 
> https://lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sa...@huawei.com/
> 
> I also rebuilt the Fedora kernel in copr, with DIGLIM:
> 
> https://copr.fedorainfracloud.org/coprs/robertosassu/DIGLIM/
> 
> You can find the instructions about how to use it here:
> 
> https://lore.kernel.org/linux-integrity/48cd737c504d45208377daa27d625...@huawei.com/
> 
> I would like to join one of your subgroups, for example
> fedora-contributor, so that I can propose a new feature
> for Fedora 36/37.

You don't need any particular group membership to propose changes. :) 
https://docs.fedoraproject.org/en-US/program_management/changes_policy/

Of course being a fedora packager is useful if your change involves
updates/changes to packages, but you could submit them as PR's and
convince existing maintainers to merge them. 

kevin


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


[EPEL-devel] Re: Requesting branches for epel9

2021-12-15 Thread Kevin Fenzi
On Wed, Dec 15, 2021 at 05:46:18PM +0100, Miroslav Suchý wrote:
> Dne 14. 12. 21 v 17:12 Matthew Miller napsal(a):
> > > > But it seems like "request an EPEL branch" should generally be either 
> > > > "Okay!
> > > > Doing that automatically now" or "Oh, this is in EL, sorry"*. What are 
> > > > the
> > > > other cases?
> > > As far as I know this isn't about requesting EPEL branches, as much as
> > > requesting any branches by hand. If I add something to Fedora rawhide
> > > and then ask for a F34 branch, the same issues can happen. Remember
> > > our build infrastructure is a pile of band-aids on top of duct tape on
> > > top of bungee cords. Lots of tools are written for a toolchain which
> > > existed years ago and have been hacked to make it work with whatever
> > > new initiative that comes into play. 'Unexpected' side effects and
> > > corner cases happen all the time and the fixing of them tends to add
> > > new ones.
> > Sure. But also, asking people to spend a lot of their time running
> > grunt-work tasks means that they have less time to fix when things break,
> > let alone re-engineer away some of that tech debt. It seems like we should
> > be able to automate the simple cases (adding F34 and F35 branches should be
> > even easier, since we don't have the "is it in EL?" question even).
> 
> *nod*
> 
> So ... the question is how can I help? Can you document the check-list? I 
> volunteer to start writing the script.

So, I suspect the epel-devel list isn't really the place to discuss this
(I would think devel list + direct engagement with releng folks). 

That said, fedscm-admin _does_ do a bunch of checks currently. 

For branch requests for existing packages it checks that the requestor
is a maintainer of that package and then just auto approves it. Those
requests could potentially be automated (we have talked about it in
releng land, but it's also a bit difficult due to all the perms you have
to have). 

For new packages it does a bunch of checks like 'is the reviewer in the
packager group', did the reviewer set 'fedora-review: +', are the
requested branches valid, etc, etc
https://pagure.io/fedscm-admin/blob/main/f/fedscm_admin/utils.py#_285

I can't speak for the current folks doing the processing, but I did this
for 3-4 years a long time ago. When I did it I looked for a lot of
things it was hard to automate checks for, like "Did this review check
list a bunch of things, or just say 'ok, approved'". I would typically
look closely at those and find things that were missed. I also recall
several reviews that I blocked due to legal reasons where the reviewer
didn't understand things correctly. 

That said, the volume of new packages is pretty high these days so I
don't know how much extra scrutiny they are really getting. Perhaps it's
time to just completely automate it and have better ways to clean up if
something bad gets in. 

kevin


signature.asc
Description: PGP 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: Builds for EPEL9

2021-12-13 Thread Kevin Fenzi
On Sat, Dec 11, 2021 at 08:58:15PM +1100, Frank Crawford wrote:
> Folks,
> 
> I'm looking at building a package that currently exists in EPEL8 for
> EPEL9.  I have a new branch epel9 branch for my package, but when I try
> to do a mock build or scratch build it fails with the error:
> 
> Error: Error downloading packages:
>   Status code: 404 for
> https://infrastructure.fedoraproject.org/repo/centos/centos-9-stream/x86_64/toplink/packages/basesystem/11/13.el9/noarch/basesystem-11-13.el9.noarch.rpm
> (IP: 38.145.60.16)
> 
> Am I doing anything wrong here, is it just that we can't currently
> build for EPEL9?

builds were broken for a short time. 

We started syncing the centos-9-stream 'release' repos, and it
accidentally deleted the existing centos-9-stream buildroot repos we
have been building against.

I resynced the buildroot repos and made sure it wasn't going to delete
them, so it should be all back to working. If you have the non working
repodata cached, you make need to do a mock --clean or the like. 

We still need to adjust koji to use the 'release' repos for epel9. 

kevin


signature.asc
Description: PGP 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


Re: Secure boot on rawhide messed up for anyone?

2021-12-11 Thread Kevin Fenzi
On Sat, Dec 11, 2021 at 09:48:32AM +, Ankur Sinha wrote:
> On Sat, Dec 11, 2021 06:32:56 +, Noah wrote:
> > Any background? This is the first I've seen this. I don't see any forwarded
> > email chains.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2030940

Yes, this was sadly broken my me. ;( 
I was upgrading builders to f35 and pushed a change out that affected
the secure boot builders in a why I didn't expect. ;( 

Anyhow, it's all corrected now and any new builds should be properly
signed. 

Sorry for the hassle. 

kevin


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


Re: Why CVEs are being filed for EPEL?

2021-12-08 Thread Kevin Fenzi
On Tue, Dec 07, 2021 at 02:13:46PM +0100, Ondřej Holý wrote:
> Hi all,
> 
> do you have any idea why CVE bugs are being filed for Fedora EPEL
> product in the case of the freerdp component
> (https://src.fedoraproject.org/rpms/freerdp) when there aren't any
> builds for epel7, or epel8? What needs to be done to avoid that, or is
> this a normal approach for other components as well? Should I close
> them as WONTFIX, or what is the expected workflow here?

Huh. Weird. 

I guess I'd say slow them WONTFIX and also mail whoever opened them
asking why there were epel bugs filed? Or you could mail secalert AT
redhat.com and ask them? I would expect no epel bugs in cases where
there are no epel branches. 

kevin


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


Re: Mock config for epel-next-9-x86_64, No march for argument: fedpkg-minimal

2021-12-06 Thread Kevin Fenzi
On Sun, Dec 05, 2021 at 01:30:38PM -0600, Richard Shaw wrote:
> Is this a known issue or is there a package I need to update? I'm on F35.

It's sadly expected... we need to get fedpkg-minimal pushed out into
epel9. There's a bug on it: 

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

Hopefully it will go through soon...

kevin 


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


[EPEL-devel] Re: EPEL 9 branch?

2021-12-04 Thread Kevin Fenzi
On Sun, Dec 05, 2021 at 03:27:49AM +, Gary Buhrmaster wrote:
> Now that CentOS Stream 9 is announced as
> available, is there a schedule for when EPEL-9
> branches can be made, and when one can
> (start to) ask others to build for EPEL-9

yes, yesterday. 

See the announcement: 
https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/5UJSW3FBGQMLXWWV7BGHWZTOFLH4NH3G/

> (it would be nice if a number of the EPEL-9
> packages were preliminarily ready at the time
> of the EL-9 formal release (just, perhaps,
> needing a (mass) rebuild to be sure)).

There's no longer any plans to mass rebuild, those packages that need a
rebuild for some reason can be rebuilt by their maintainer(s). 

kevin


signature.asc
Description: PGP 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


Re: EPEL 9 branch?

2021-12-04 Thread Kevin Fenzi
On Sun, Dec 05, 2021 at 03:27:49AM +, Gary Buhrmaster wrote:
> Now that CentOS Stream 9 is announced as
> available, is there a schedule for when EPEL-9
> branches can be made, and when one can
> (start to) ask others to build for EPEL-9

yes, yesterday. 

See the announcement: 
https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/5UJSW3FBGQMLXWWV7BGHWZTOFLH4NH3G/

> (it would be nice if a number of the EPEL-9
> packages were preliminarily ready at the time
> of the EL-9 formal release (just, perhaps,
> needing a (mass) rebuild to be sure)).

There's no longer any plans to mass rebuild, those packages that need a
rebuild for some reason can be rebuilt by their maintainer(s). 

kevin


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


Re: I'm assuming this is a temporary build failure?

2021-12-04 Thread Kevin Fenzi
On Sat, Dec 04, 2021 at 04:53:09PM -0500, Neal Becker wrote:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=79571245

Yes. I am not sure whats causing it. I updated and rebooted the
kojipkgs01/02 vm's (to pick up new kernel and also new host qemu). 

if you see it again or more often, feel free to file a infrastructure
ticket. 

kevin


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


Re: Is there a problem if we add ~4 thousand automatically generated obsoletes?

2021-12-03 Thread Kevin Fenzi
On Wed, Dec 01, 2021 at 02:06:41PM +0100, Miro Hrončok wrote:
> See 
> https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/2OCCFIKT7LZ7IPO3OKIEH3TDTGERSORM/
> 
> Would adding automatically generated obsoletes to 3624 Python packages have
> any observable negative impact (e.g. on the repodata size or time to resolve
> deps)?

I think that would increase the size of the primary repodata...

I guess by number * length of obsolete, so might not be that bad?

It would likely affect dnf processing time as well, but not sure how
much. 

It seems like something to try and avoid if possible.

kevin


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


Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

2021-12-02 Thread Kevin Fenzi
On Thu, Dec 02, 2021 at 02:36:51PM -0500, Ben Cotton wrote:
...snip...
> 
> In the context of rpm, there are two parts to this:
> * at build time, we compute the Merkle tree for the files within a
> package, then sign it and ship it as part of the rpm metadata;

This is some kind of seperate signing that happens at build time?

Or it's added to the rpm metadata and covered by the normal package
signing if/when the package is signed?

> * at run time, if the fsverity rpm plugin is enabled, rpm will install
> the fsverity signature key and enable fsverity on files that are
> installed.

Is this signature key the fedora rpm package signing key? 
Or some seperate fsverity key?

...snip...

> fs-verity works by using a Merkle tree to generate a checksum for
> every data block in the system, and reads will fail if a single data

every data block? or every packaged in rpms data block?

> block read fails it’s checksum. The signature of the the file is
> validated against a public key loaded into the kernel keyring. Because
> fsverity operates on block reads, its runtime cost is small (as it
> only needs to verify the block that is being accessed), and it can
> protect from alterations at any point in time.

Is this via dm_verity kernel module? Or thats a completely seperate
thing?

...snip...

> == Scope ==
> 
> * Proposal owners
> ** btrfs kernel enablement work
> ([https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=146054090b0859b28fc39015c7704ccc3c3a347f
> landed in 5.15]); see this
> [https://developers.facebook.com/blog/post/2021/10/19/fs-verity-support-in-btrfs/
> blog post] for more details

What does this mean for all the other filesystems? They would just be
slower since btrfs is computing the trees as part of it's normal
checksumming?

> ** koji integration: koji will need to add the fs-verity metadata to
> packages when signing them

Well, koji doesn't sign packages. robosignatory listens for messages on
the message bus for koji tagging and based on it's config, it asks sigul
to sign rpms and import the signatures into koji. 

There's support in robosignatory to ask to sign files (used for the
short lived IMA stuff), but I suspect it would need a new ability for
this. 

Finally who is going to write this? Change owners?
Or do you expect robosignatory maintainers to do so?

> * Other developers:
> ** deploy the koji integration changes to production
> * Release engineering: tbd
> * Policies and guidelines: N/A
> * Trademark approval: N/A
> 
> == Upgrade/compatibility impact ==
> 
> None
> 
> == How to test ==
> 
> Install the fs-verity RPM plugin to validate package contents:
> 
> $ sudo dnf install rpm-plugin-fsverity
> Note that this will only be useful if the packages being installed
> contain the appropriate fs-verity metadata (which, for Fedora upstream
> packages, requires Koji integration that is part of this Change).
> However, you should still be able to test this if you locally sign a
> package with rpmsign --addverity.
> 
> == User experience ==
> 
> This Change is fully transparent and there is no user impact by
> default. If the user chooses to enable the fs-verity RPM plugin, they
> can then leverage the additional verification features provided by
> fs-verity.
> 
> == Dependencies ==
> 
> * fs-verity support is available in RPM as of 4.17, which is available
> as of Fedora 35 and is already enabled in rpm-4.17.0-0.rc1.0.fc36
> * CONFIG_FS_VERITY in the kernel config; this is already enabled
> * fs-verity requires filesystem support; currently support for ext4
> and f2fs is already available; support for btrfs landed in 5.15

No xfs support?

Thanks in advance for answers. 

kevin


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


Re: Release 13.0.1-rc1 has been tagged

2021-11-30 Thread Kevin Fenzi
On Mon, Nov 29, 2021 at 10:07:52PM -0800, Tom Stellard wrote:
> Hi,
> 
> I've tagged 13.0.1-rc1.  Testers can begin testing and uploading binaries.
> 
> There is still time to submit fixes for the final 13.0.1.  I'll give more
> details about timelines and how to do this once the bugzilla migration is
> complete.  Currently, bugzilla is read-only, so we can't submit any fixes
> there.

I'm guessing this is llvm? 

kevin


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


[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed

2021-11-29 Thread Kevin Fenzi
On Mon, Nov 29, 2021 at 09:11:48AM -0500, Neal Gompa wrote:
> On Mon, Nov 29, 2021 at 9:04 AM Matthew Miller  
> wrote:
> >
> > On Mon, Nov 29, 2021 at 07:00:30AM -0500, Neal Gompa wrote:
> > > If Fedora and EPEL were to have older versions, we'd have to have a
> > > dedicated CDN endpoint for them, because mirrors would seriously have
> > > trouble taking it.
> >
> > How often would such packages be used? If we had a non-default repo
> > available but not enabled by default, it could be optional to mirror and
> > probably still be okay.

So, we actually do have this for fedora updates today. 
We had to set it up to solve an issue with the updates flow and CoreOS.

See the fedora-updates-archive subpackage of fedora-repos. 
This is hosted on amazon S3, behind cloudfront.

> I suspect it would be fairly heavily used. There are significant
> benefits to having those:
> 
> * DeltaRPM would be considerably more useful

In order to have deltarpms the packages would have to be available at
compose time and in the same repo.

> * "dnf history undo" would actually work
> 
> We could make it non-default and tell people that rollbacks require an
> --enablerepo= option, though.

This would work for Fedora now with the archive repo above.

I suppose we could look at setting up a similar setup with epel. 

kevin


signature.asc
Description: PGP 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


Re: [EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed

2021-11-29 Thread Kevin Fenzi
On Mon, Nov 29, 2021 at 09:11:48AM -0500, Neal Gompa wrote:
> On Mon, Nov 29, 2021 at 9:04 AM Matthew Miller  
> wrote:
> >
> > On Mon, Nov 29, 2021 at 07:00:30AM -0500, Neal Gompa wrote:
> > > If Fedora and EPEL were to have older versions, we'd have to have a
> > > dedicated CDN endpoint for them, because mirrors would seriously have
> > > trouble taking it.
> >
> > How often would such packages be used? If we had a non-default repo
> > available but not enabled by default, it could be optional to mirror and
> > probably still be okay.

So, we actually do have this for fedora updates today. 
We had to set it up to solve an issue with the updates flow and CoreOS.

See the fedora-updates-archive subpackage of fedora-repos. 
This is hosted on amazon S3, behind cloudfront.

> I suspect it would be fairly heavily used. There are significant
> benefits to having those:
> 
> * DeltaRPM would be considerably more useful

In order to have deltarpms the packages would have to be available at
compose time and in the same repo.

> * "dnf history undo" would actually work
> 
> We could make it non-default and tell people that rollbacks require an
> --enablerepo= option, though.

This would work for Fedora now with the archive repo above.

I suppose we could look at setting up a similar setup with epel. 

kevin


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


Re: Planned Outage - bodhi.fedoraproject.org - 2021-11-29 7:00 UTC

2021-11-27 Thread Kevin Fenzi
On Sat, Nov 27, 2021 at 04:52:08PM +, Maxwell G (@gotmax23) via devel wrote:
> 
> Nov 27, 2021 11:28:57 AM Adam Saleh :
> 
> > Please join #fedora-admin or #fedora-noc on irc.freenode.net
> > or add comments to the ticket for this outage above.
> 
> 
> Shouldn't this be changed to Libera Chat?

Yeah, and I did change the template. Adam must have copied from a
previous outage that used the old network?

kevin


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


Re: Strange s390x/x86_64 build failures

2021-11-23 Thread Kevin Fenzi
On Mon, Nov 22, 2021 at 12:50:06PM -0800, Kevin Fenzi wrote:
> I think there's something deeper going on. ;( 
> 
> That builder has in dmesg: 
> 
> [399371.168000] print_req_error: 2 callbacks suppressed
> [399371.168007] blk_update_request: I/O error, dev vda, sector 174077464 op 
> 0x1:(WRITE) flags 0x10 phys_seg 134 prio class 0
> [399371.168231] blk_update_request: I/O error, dev vda, sector 174079864 op 
> 0x1:(WRITE) flags 0x104000 phys_seg 106 prio class 0
> [399371.168268] blk_update_request: I/O error, dev vda, sector 174082424 op 
> 0x1:(WRITE) flags 0x104000 phys_seg 72 prio class 0
> [399371.168299] blk_update_request: I/O error, dev vda, sector 174084984 op 
> 0x1:(WRITE) flags 0x10 phys_seg 79 prio class 0
> [399371.168334] blk_update_request: I/O error, dev vda, sector 174087264 op 
> 0x1:(WRITE) flags 0x104000 phys_seg 246 prio class 0
> [399371.168364] blk_update_request: I/O error, dev vda, sector 174089824 op 
> 0x1:(WRITE) flags 0x10 phys_seg 11 prio class 0
> [399371.168394] blk_update_request: I/O error, dev vda, sector 174089984 op 
> 0x1:(WRITE) flags 0x104000 phys_seg 232 prio class 0
> [399371.168535] blk_update_request: I/O error, dev vda, sector 174092544 op 
> 0x1:(WRITE) flags 0x10 phys_seg 25 prio class 0
> [399371.168632] blk_update_request: I/O error, dev vda, sector 174092800 op 
> 0x1:(WRITE) flags 0x104000 phys_seg 217 prio class 0
> [399371.168661] blk_update_request: I/O error, dev vda, sector 174095360 op 
> 0x1:(WRITE) flags 0x10 phys_seg 40 prio class 0
> [399371.169478] vda6: writeback error on inode 204925378, offset 0, sector 
> 174074904
> [399371.196642] vda6: writeback error on inode 70353785, offset 0, sector 
> 72333240
> [399371.204462] vda6: writeback error on inode 70353792, offset 0, sector 
> 73328008
> [399371.206361] vda6: writeback error on inode 70353784, offset 0, sector 
> 72295304
> 
> It is running a old kernel tho (it was reinstalled recently).
> Along with 3 others. 
> 
> I have updated them all and rebooted them into the latest kernel. 
> If you see this again, please file a ticket on it and we can dig deeper. 
> 
> I'll also try and keep an eye out on them but I am on PTO this week

So, they all started showing the issues again... 

I have reinstalled them, this time with different (more conservative)
cache settings for the disk. Hopefully this will fix things and the new
mainframe is just more sensitive for i/o than the old one was. 

Will keep watching them.

There is also: 

https://pagure.io/fedora-infrastructure/issue/10362

to report seeing issues now. 

kevin


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


Re: qemu (was: Re: Orphaned packages looking for new maintainers​)

2021-11-22 Thread Kevin Fenzi
On Mon, Nov 22, 2021 at 12:12:03PM -0600, Chris Adams wrote:
> Once upon a time, Sérgio Basto  said:
> > and why ipmitool was orphaned ? it was built successfully , its
> > maintain upstream ... 
> 
> It also has mulitple co-maintainers... hopefully somebody can step up?

Yeah, I use ipmitool all the time. 

I went ahead and took it to make sure it's taken care of. 
If any of the current co-maintainers would prefer, I'm happy to give it
to them. 

kevin


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


Re: question on fedorapeople space

2021-11-22 Thread Kevin Fenzi
On Mon, Nov 22, 2021 at 08:58:06AM +, Ankur Sinha wrote:
> On Sat, Nov 20, 2021 04:35:20 +, Globe Trotter via devel wrote:
> > Thank you, your answer makes sense and clarifies to me what is on the 
> > instructions page. If I were editing the page, I would make sure that it 
> > says somewhere that we need to ssh in and then create the directories and 
> > permissions. the first part is not mentioned anywhere on that page.
> 
> It's a wiki page, so please do edit it to clarify the instructions as
> you think necessary.
> 
> https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org#Common_answers

I went ahead and added some notes about public_html and permissions. 

It's worth noting you also need to chmod 0755 your home directory.

kevin


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


Re: Strange s390x/x86_64 build failures

2021-11-22 Thread Kevin Fenzi
On Sun, Nov 21, 2021 at 07:51:58PM -0700, Orion Poplawski wrote:
> On 11/21/21 19:23, devel@lists.fedoraproject.org wrote:
> > Just noting that I had a strange one-time s390x and x86_64 build failure.
> 
> More:
> 
> s390x:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=79143231
> 
> libtool: link: /usr/bin/gcc-ranlib liboctave/array/.libs/libarray.a
> /usr/bin/ranlib: unable to copy file 'liboctave/array/.libs/libarray.a';
> reason: Input/output error
> make[2]: *** [Makefile:13394: liboctave/array/libarray.la] Error 1
> 
> i686:
> 
> virtual memory exhausted: Operation not permitted
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=79143237
> 
> (okay, this is probably your typical out of memory build issue)

I think there's something deeper going on. ;( 

That builder has in dmesg: 

[399371.168000] print_req_error: 2 callbacks suppressed
[399371.168007] blk_update_request: I/O error, dev vda, sector 174077464 op 
0x1:(WRITE) flags 0x10 phys_seg 134 prio class 0
[399371.168231] blk_update_request: I/O error, dev vda, sector 174079864 op 
0x1:(WRITE) flags 0x104000 phys_seg 106 prio class 0
[399371.168268] blk_update_request: I/O error, dev vda, sector 174082424 op 
0x1:(WRITE) flags 0x104000 phys_seg 72 prio class 0
[399371.168299] blk_update_request: I/O error, dev vda, sector 174084984 op 
0x1:(WRITE) flags 0x10 phys_seg 79 prio class 0
[399371.168334] blk_update_request: I/O error, dev vda, sector 174087264 op 
0x1:(WRITE) flags 0x104000 phys_seg 246 prio class 0
[399371.168364] blk_update_request: I/O error, dev vda, sector 174089824 op 
0x1:(WRITE) flags 0x10 phys_seg 11 prio class 0
[399371.168394] blk_update_request: I/O error, dev vda, sector 174089984 op 
0x1:(WRITE) flags 0x104000 phys_seg 232 prio class 0
[399371.168535] blk_update_request: I/O error, dev vda, sector 174092544 op 
0x1:(WRITE) flags 0x10 phys_seg 25 prio class 0
[399371.168632] blk_update_request: I/O error, dev vda, sector 174092800 op 
0x1:(WRITE) flags 0x104000 phys_seg 217 prio class 0
[399371.168661] blk_update_request: I/O error, dev vda, sector 174095360 op 
0x1:(WRITE) flags 0x10 phys_seg 40 prio class 0
[399371.169478] vda6: writeback error on inode 204925378, offset 0, sector 
174074904
[399371.196642] vda6: writeback error on inode 70353785, offset 0, sector 
72333240
[399371.204462] vda6: writeback error on inode 70353792, offset 0, sector 
73328008
[399371.206361] vda6: writeback error on inode 70353784, offset 0, sector 
72295304

It is running a old kernel tho (it was reinstalled recently).
Along with 3 others. 

I have updated them all and rebooted them into the latest kernel. 
If you see this again, please file a ticket on it and we can dig deeper. 

I'll also try and keep an eye out on them but I am on PTO this week

kevin


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


[EPEL-devel] Re: EPEL 9 Next Bodhi updates: Set lower days to stable limit?

2021-11-19 Thread Kevin Fenzi
On Fri, Nov 19, 2021 at 01:22:32PM -0500, Neal Gompa wrote:
> On Fri, Nov 19, 2021 at 1:15 PM Miro Hrončok  wrote:
> >
> > On 19. 11. 21 17:54, Troy Dawson wrote:
> > >
> > >
> > > On Fri, Nov 19, 2021 at 8:46 AM Stephen John Smoogen  > > > wrote:
> > >
> > > On Fri, 19 Nov 2021 at 11:42, Miro Hrončok  > > > wrote:
> > >  >
> > >  > Hello EPEL people,
> > >  >
> > >  > what do you think about setting the Bodhi days to stable limit to 
> > > 3 days for
> > >  > EPEL 9 Next (at least until RHEL 9 GA)?
> > >  >
> > >
> > > I think EPEL-9 Next being based off of Stream with its major changes
> > > should have a small stable limit. 3 days sounds about right.
> > >
> > >
> > > +1
> >
> > There seem to be a consensus, do I file a ticket at infra, or does the EPSCo
> > need to approve it a meeting?
> >
> 
> Please file a ticket with infra about it.

wow... consensus in 1.5 hours. :) 

Perhaps this should be discussed at the next meeting? To allow
interested parties to actually see it and comment?

Anyhow, I'm personally fine with it, but note that 3 days leaves very
little time for testing. One of those days is likely mirror sync/getting
the update, so interested testers would need to update at least every
day to make sure and not miss out. 

kevin


signature.asc
Description: PGP 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


Re: Add a game grou;p to https://src.fedoraproject.org/groups

2021-11-18 Thread Kevin Fenzi
On Thu, Nov 18, 2021 at 03:48:55AM -, Reon Beon via devel wrote:
> https://src.fedoraproject.org/groups
> 
> Thoughts?

If there is a active group of games packagers that would like to
coordinate, then sure. :) AFAIK, the games sig is pretty quiet these
days... but someone could revive them.

kevin


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


Re: F37 Change: RetireARMv7 (System-Wide Change proposal)

2021-11-18 Thread Kevin Fenzi
I still like Seth's system-autodeath, but it's been retired for a while
now. 

From the summary: 

system-autodeath is a cron job that runs daily, checking the current  
time versus a configured death date for the machine. Within one week
of this date the system will emit log notices to syslog.alert notifying
that the system will remove its default network route on a specific date. 
On the date the system will have its default route deleted. It 
will continue to do this every day until someone does something about it.

really anything we do though is going to be invasive and unwelcome to
some.

kevin


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


Re: rawhide build root broken by redhat-rpm-config clash

2021-11-18 Thread Kevin Fenzi
On Thu, Nov 18, 2021 at 05:56:01PM +, Daniel P. Berrangé wrote:
> The rawhide build root appears to be broken when installing the
> srpm-build group:
> 
> https://kojipkgs.fedoraproject.org//work/tasks/8923/79028923/root.log
> 
> DEBUG util.py:446:  Installing group/module packages:
> DEBUG util.py:446:   bash  s390x  5.1.8-3.fc36
>   build 1.6 M
> DEBUG util.py:446:   fedora-releasenoarch 36-0.9  
>   build  11 k
> DEBUG util.py:446:   fedpkg-minimalnoarch 1.2.0-4.fc36
>   build  17 k
> DEBUG util.py:446:   glibc-minimal-langpacks390x  2.34.9000-21.fc36   
>   build 146 k
> DEBUG util.py:446:   gnupg2s390x  2.3.3-1.fc36
>   build 2.4 M
> DEBUG util.py:446:   redhat-rpm-config noarch 204-1.fc36  
>   build  67 k
> DEBUG util.py:446:   rpm-build s390x  4.17.0-1.fc36.1 
>   build  60 k
> DEBUG util.py:446:   shadow-utils  s390x  2:4.9-7.fc36
>   build 1.1 M
> 
> snip...
> 
> DEBUG util.py:444:  Error: Transaction test error:
> DEBUG util.py:444:file /usr/lib/rpm/fileattrs/kmod.attr conflicts between 
> attempted installs of redhat-rpm-config-204-1.fc36.noarch and 
> kernel-srpm-macros-1.0-10.fc36.noarch
> 
> 
> kernel-srpm-macros was rebuilt today containing the kmod.attr file
> before redhat-rpm-config was modified to remove it. AFAICT, this
> means nothing more can be rebuilt until kernel-srpm-macros is
> untagged and then redhat-rpm-config needs to remove the file before
> kernel-srpm-macros re-adds it.
> 
> redhat-rpm-config bug: https://bugzilla.redhat.com/show_bug.cgi?id=2024696
> kernel-srpm-macros bug: https://bugzilla.redhat.com/show_bug.cgi?id=2024694

FYI, I have untagged kernel-srpm-macros-1.0-10.fc36 from f36 and eln. 

kevin


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


Re: RFC: Reduce number of packages that are built for i686

2021-11-17 Thread Kevin Fenzi
On Wed, Nov 17, 2021 at 05:58:43PM +, Peter Robinson wrote:
> 
> What else is there that people care about in Fedora that's only i686?

Well, wine? I don't know how much 32bit wine is used these days. 

And not 'in fedora', but people always bring up steam when these
disccussions happen. I wonder why they are sticking with 32bit?

kevin


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


Re: Long-running side tag for porting Fedora to C99 (no implicit decls)

2021-11-12 Thread Kevin Fenzi
On Wed, Nov 10, 2021 at 09:47:47AM +0100, Florian Weimer wrote:
> * Kevin Fenzi:
> 
> > On Tue, Nov 09, 2021 at 10:41:16AM +0100, Florian Weimer wrote:
> >> * Kevin Fenzi:
> >> 
> >> > Isn't this an ideal use case for copr?
> >> 
> >> I don't know.  I could piece together the Koji API fairly easily, and
> >> had hoped to reuse some of the script logic.
> >> 
> >> Or does COPR have direct support this?  Can I tell it directly to report
> >> rawhide in a special buildroot?  Is there a programmatic way to access
> >> the resulting log files?
> >> 
> >> (I won't need the built RPMs, which is why I would use scratch builds in
> >> Koji.)
> >
> > Yes, copr has a api also. 
> > https://python-copr.readthedocs.io/en/latest/ClientV3.html
> 
> Is there an overview similar to <https://koji.fedoraproject.org/koji/api>?
> It's hard to tell what the capbilities are.

I'm not sure and I was hoping one of the copr folks would chime in. ;) 

CCing praiskup

kevin


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


Re: Action required: Account system IRC pointer reset

2021-11-11 Thread Kevin Fenzi
On Thu, Nov 11, 2021 at 08:04:34PM +0100, Fabio Valentini wrote:
> On Wed, Nov 10, 2021 at 8:41 PM Kevin Fenzi  wrote:
> >
> > On Wed, Nov 10, 2021 at 08:40:32AM -0500, Stephen Gallagher wrote:
> > > On Tue, Nov 9, 2021 at 5:36 PM Kevin Fenzi  wrote:
> > > >
> > > > Greetings everyone.
> > > >
> > > > As you know, we migrated a while back from freenode.net to libera.chat 
> > > > for our IRC networks,
> > > > and we also migrated to a new account system. After these moves, we 
> > > > would like to clear any
> > > > IRC information that could be no longer correct and allow users to 
> > > > update their accounts
> > > > with the correct information.
> > > >
> > > > The old Fedora account system had a ‘irc nick’ field. The new Fedora 
> > > > account system has
> > > > a ‘Chat nicknames’ section. In that section you can put IRC nick(s) or 
> > > > Matrix Ids.
> > > > If you do not qualify them, they are assumed to be for the libera.chat 
> > > > (IRC) and fedora.im (matrix) networks.
> > > >
> > > > Groups in both the old and new account system have a details section 
> > > > often containing links to mailing list and irc channel.
> > > >
> > > > On 2021-11-10 we are going to remove from the account system all users 
> > > > ‘Chat nicknames’ values
> > > > and adjust all groups irc channel links from freenode.net to 
> > > > libera.chat. Users are encouraged
> > > > to login after this time and enter their current and correct Chat 
> > > > nicknames.
> > > >
> > >
> > > Will an additional announcement be going out once this change has been
> > > applied, so we know when to update our nicks?
> >
> > Yes. This change is applied. Please update at your leasure.
> 
> I wonder, which mailing list was your original / first message (the
> announcement, I think?) in this thread sent to? Is there a mailing
> list archive link for it?
> Because I seem to be missing the actual announcement mail with all the
> details from my mail inbox, only subsequent responses are here.

It went to annou...@lists.fedoraproject.org, but I guess I should have
also sent it to devel-announce? mattdm has suggested that we need
something like a 'contributor-announce' for things like this. 

https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org/thread/DK2DYBB3JZW4J3KUYREEEC42Z4D3IPP2/

kevin


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


Re: Action required: Account system IRC pointer reset

2021-11-10 Thread Kevin Fenzi
On Wed, Nov 10, 2021 at 12:56:33PM +0100, Kamil Paral wrote:
> On Tue, Nov 9, 2021 at 11:35 PM Kevin Fenzi  wrote:
> 
> > The old Fedora account system had a ‘irc nick’ field. The new Fedora
> > account system has
> > a ‘Chat nicknames’ section. In that section you can put IRC nick(s) or
> > Matrix Ids.
> > If you do not qualify them, they are assumed to be for the libera.chat
> > (IRC) and fedora.im (matrix) networks.
> >
> 
> Hi Kevin. I heard about Fedora getting its own Matrix server in the future,
> but never saw any announcement that it is here already. Is fedora.im
> production-ready? I'm happy to replace my old Matrix account with a Fedora
> one, if everything is ready.

Most everything is ready, we are just trying to finish writing some
documentation before announcing anything widely. 

You can use any matrix app that supports SOO or use
https://chat.fedoraproject.org/ to login via our account system and
create a YOUFASID:fedora.im account. 

Hopefully we will get docs sorted out soon. 

kevin


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


Re: Action required: Account system IRC pointer reset

2021-11-10 Thread Kevin Fenzi
On Wed, Nov 10, 2021 at 08:40:32AM -0500, Stephen Gallagher wrote:
> On Tue, Nov 9, 2021 at 5:36 PM Kevin Fenzi  wrote:
> >
> > Greetings everyone.
> >
> > As you know, we migrated a while back from freenode.net to libera.chat for 
> > our IRC networks,
> > and we also migrated to a new account system. After these moves, we would 
> > like to clear any
> > IRC information that could be no longer correct and allow users to update 
> > their accounts
> > with the correct information.
> >
> > The old Fedora account system had a ‘irc nick’ field. The new Fedora 
> > account system has
> > a ‘Chat nicknames’ section. In that section you can put IRC nick(s) or 
> > Matrix Ids.
> > If you do not qualify them, they are assumed to be for the libera.chat 
> > (IRC) and fedora.im (matrix) networks.
> >
> > Groups in both the old and new account system have a details section often 
> > containing links to mailing list and irc channel.
> >
> > On 2021-11-10 we are going to remove from the account system all users 
> > ‘Chat nicknames’ values
> > and adjust all groups irc channel links from freenode.net to libera.chat. 
> > Users are encouraged
> > to login after this time and enter their current and correct Chat nicknames.
> >
> 
> Will an additional announcement be going out once this change has been
> applied, so we know when to update our nicks?

Yes. This change is applied. Please update at your leasure. 

kevin


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


Re: Long-running side tag for porting Fedora to C99 (no implicit decls)

2021-11-09 Thread Kevin Fenzi
On Tue, Nov 09, 2021 at 10:41:16AM +0100, Florian Weimer wrote:
> * Kevin Fenzi:
> 
> > Isn't this an ideal use case for copr?
> 
> I don't know.  I could piece together the Koji API fairly easily, and
> had hoped to reuse some of the script logic.
> 
> Or does COPR have direct support this?  Can I tell it directly to report
> rawhide in a special buildroot?  Is there a programmatic way to access
> the resulting log files?
> 
> (I won't need the built RPMs, which is why I would use scratch builds in
> Koji.)

Yes, copr has a api also. 
https://python-copr.readthedocs.io/en/latest/ClientV3.html

> > Or is the lack of s390x (and non emulated armv7) there too much of a hurdle?
> 
> I would prefer to test on the real thing, true.

Yeah, thats the one reason I was wondering about suggesting copr, but
other than the arch issues I think it may be a better fit for this. 

kevin


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


Re: dnf "no match for group package" on upgrade...

2021-11-08 Thread Kevin Fenzi
On Mon, Nov 08, 2021 at 05:01:47PM -0500, Matthew Miller wrote:
> On Mon, Nov 08, 2021 at 09:55:42PM +0100, Dominik 'Rathann' Mierzejewski 
> wrote:
> > +1 to both.
> 
> https://github.com/rpm-software-management/dnf/pull/1795
> 
> https://pagure.io/releng/issue/10376

I'll add here that even though there's a number of PR's open against
fedora-comps, it's pretty reasonably maintained I think. Uncontroversial
changes are merged pretty quickly... it's just the messy ones where some
group can't come to consensus where they sit around for a long time. 

I guess I can just look at closing those and tell people to re-file when
they have made some decision. 

kevin


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


[EPEL-devel] ansible 2.9.x EOL - 2022-05-23

2021-11-08 Thread Kevin Fenzi
Greetings. 

Upstream ansible has announced that they intend to EOL ansible 2.9.x on
May 23rd, 2022. I intend to likewise retire the epel7 and epel8
ansible-2.9.x packages at that time. 

See the upstream announcement at:
https://groups.google.com/g/ansible-devel/c/rx-fnf1L5e8/m/r0_UumLMBgAJ

ansible-core will be available in centos stream 8/9 and rhel8/9 soon.

The ansible upstream distribution (ansible-core + many many collections)
will be available for Fedora soon (
https://fedoraproject.org/wiki/Changes/Ansible5 ). Once that packaging
work is done we will see about also adding it to epel8/9. 

Users using EL7 for a control host should look at moving to EL8 before
ansible 2.9 goes EOL. 

Thanks, 

kevin


signature.asc
Description: PGP 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


Re: deltarpm usefulness?

2021-11-08 Thread Kevin Fenzi
On Sun, Nov 07, 2021 at 10:43:33AM -0800, Gordon Messmer wrote:
> On 11/7/21 01:14, Rajeesh K V wrote:
> > Deltarpm did
> > reduce a lot of update download size for many years since 2007
> 
> 
> I remember seeing 60-70% reduction really often, and 90+ periodically.  I've
> read Kevin's explanation of why it's not working as well now, but I wonder
> what changed between the early implementation when results were very good
> and now, when they really aren't.

I think it's because you only see deltas from N to N+1 now and before
you saw deltas from N to N+X before. So, I think if we made it somehow
create older deltas, you would again see better savings. The issue
doesn't just cause there to be fewer deltas, but it also causes those
few be be against very recent changes, so less effective.


kevin


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


Re: Long-running side tag for porting Fedora to C99 (no implicit decls)

2021-11-08 Thread Kevin Fenzi
On Mon, Nov 08, 2021 at 02:06:43PM +0100, Florian Weimer wrote:
> I would like to create a long-running rawhide side tag for preparing
> Fedora for the removal of implicit function declarations from the GCC
> defaults.  This is a change that happened in the C99 version of the
> language, but GCC could not adopt at the time because too much software
> was broken by it.  Even today, there are build failures, and, arguably
> worse, successful builds with different feature sets.
> 
> The goal is to disable implicit function declarations in GCC 13, to be
> released in spring 2023 (not next year's GCC 12 version).  This plan was
> presented at this year's Cauldron, and was met with approval:
> 
>   Eliminating implicit function declarations
>   
> 
> I have some space to work on this during the coming months, for
> implementing the buildroot changes (in gcc and presumably
> redhat-rpm-config, built off branches in dist-git), for creating some
> HTML reports, and even for creating the package changes themselves.
> Changes will be submitted to upstream projects initially.  Eventually,
> we'll have to fix the Fedora packages if there's no upstream release
> with the fixes.  We'll need some way to coordinate the fixes between
> multiple developers, a way to find unapplied upstream fixes once we are
> heading towards Fedora 38, and ideally some way to share patches across
> distributions if the upstream project no longer exists/accepts patches.
> 
> If Fedora wants to support this, I'd need a long-running side tag in
> Koji, and a few dist-git branches (for gcc and redhat-rpm-config).  I
> can do the test builds as scratch builds, to conserve storage space and
> not to pollute Koji with uninteresting NVRs.
> 
> Thoughts?

Isn't this an ideal use case for copr? 
Or is the lack of s390x (and non emulated armv7) there too much of a hurdle?

kevin


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


Planned Outage - build systems ( koji, osbs, mbs, src, pdc, kojipkgs, odcs, registriy) - 2021-11-09 17:00 UTC

2021-11-05 Thread Kevin Fenzi
Planned Outage - build systems ( koji, osbs, mbs, src, pdc, kojipkgs, odcs, 
registriy) - 2021-11-09 17:00 UTC

There will be an outage starting at 2021-11-09 17:00 UTC,
which will last approximately 4 hours.

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

date -d '2021-11-09 17:00UTC'

Reason for outage:

We will be doing several maint tasks during this outage:

All the s390x builders will be moving from the current z13 maintframe to a 
z15 mainframe.

koji hub and builders will be updated from 1.25.1 to 1.26.1

Updates will be applied to all build servers and reboots done to the latest 
kernel.

Maintainers are advised to avoid starting builds before the outage that won't 
complete
before the outage is over. Some builds may restart or need to be resubmitted
if they are running during the maint window.

Affected Services:

koji (both hub and builders)
mbs - module build service
odcs - on demand compose service
osbs - openshift build service
pdc - product def center
src - dist-git/pagure
kojipkgs - pkgs stored on koji
registry - container registries

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/10302

Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.


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


Planned Outage - bodhi.fedoraproject.org - 2021-11-08 10:00 UTC

2021-11-05 Thread Kevin Fenzi
Planned Outage - bodhi.fedoraproject.org - 2021-11-08 10:00 UTC

There will be an outage starting on monday at 2021-11-08 10:00 UTC,
which will last approximately 2 hours.

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

date -d '2021-11-08 10:00UTC'

Reason for outage:

Bodhi will be upgraded to 5.7.1.

Affected Services:

bodhi / updates.fedoraproject.org may be down or unresponsive during the 
upgrade window

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/10310

Please join #fedora-admin or #fedora-noc on chat.libera.net
or add comments to the ticket for this outage above.


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


Planned Outage - build systems ( koji, osbs, mbs, src, pdc, kojipkgs, odcs, registriy) - 2021-11-09 17:00 UTC

2021-11-05 Thread Kevin Fenzi
Planned Outage - build systems ( koji, osbs, mbs, src, pdc, kojipkgs, odcs, 
registriy) - 2021-11-09 17:00 UTC

There will be an outage starting at 2021-11-09 17:00 UTC,
which will last approximately 4 hours.

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

date -d '2021-11-09 17:00UTC'

Reason for outage:

We will be doing several maint tasks during this outage:

All the s390x builders will be moving from the current z13 maintframe to a 
z15 mainframe.

koji hub and builders will be updated from 1.25.1 to 1.26.1

Updates will be applied to all build servers and reboots done to the latest 
kernel.

Maintainers are advised to avoid starting builds before the outage that won't 
complete
before the outage is over. Some builds may restart or need to be resubmitted
if they are running during the maint window.

Affected Services:

koji (both hub and builders)
mbs - module build service
odcs - on demand compose service
osbs - openshift build service
pdc - product def center
src - dist-git/pagure
kojipkgs - pkgs stored on koji
registry - container registries

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/10302

Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.


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


Planned Outage - bodhi.fedoraproject.org - 2021-11-08 10:00 UTC

2021-11-05 Thread Kevin Fenzi
Planned Outage - bodhi.fedoraproject.org - 2021-11-08 10:00 UTC

There will be an outage starting on monday at 2021-11-08 10:00 UTC,
which will last approximately 2 hours.

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

date -d '2021-11-08 10:00UTC'

Reason for outage:

Bodhi will be upgraded to 5.7.1.

Affected Services:

bodhi / updates.fedoraproject.org may be down or unresponsive during the 
upgrade window

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/10310

Please join #fedora-admin or #fedora-noc on chat.libera.net
or add comments to the ticket for this outage above.


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


Re: Fedora 35 security update of curl blocked for a month

2021-11-03 Thread Kevin Fenzi
On Wed, Nov 03, 2021 at 09:38:57AM -0700, Adam Williamson wrote:
...snip...
> 
> I'll send a patch to fix that. Of course, what we're *really* behind on
> here is getting datagrepper and FMN rewritten to use fedora-messaging
> and message schemas[0] instead of fedmsg and the fedmsg_meta stuff...
> 
> [0] https://fedora-messaging.readthedocs.io/en/latest/messages.html#schema

So, just FYI on this part... 

CPE folks actually worked on modernizing datanommer/datagrepper
recently:
https://pagure.io/cpe/initiatives-proposal/issue/8

The database is currently being migrated from just postgres to
timescaledb, but it's a gigantic db and it's taking a long time to do
so. Hopefully it will be finished by the end of the year... 

I really hope we get around to FMN soon... it's really ancient at this
point and has a lot of problems. ;( 

kevin


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


wiki talk pages editing disabled

2021-11-03 Thread Kevin Fenzi
Greetings everyone. 

I've disabled editing of our mediawiki "iDiscussion/Talk" pages. 

The idea is that people can use those talk pages to discuss
or ask questions about a page. However, while people do add
questions or ideas to these pages, very rarely will anyone respond to
them or see their feedback. 

This feature has thus been disabled. Please use lists, IRC/Matrix or
discussion discourse to ask questions about or discuss wiki pages. 

Thanks, 

kevin


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


wiki talk pages editing disabled

2021-11-03 Thread Kevin Fenzi
Greetings everyone. 

I've disabled editing of our mediawiki "iDiscussion/Talk" pages. 

The idea is that people can use those talk pages to discuss
or ask questions about a page. However, while people do add
questions or ideas to these pages, very rarely will anyone respond to
them or see their feedback. 

This feature has thus been disabled. Please use lists, IRC/Matrix or
discussion discourse to ask questions about or discuss wiki pages. 

Thanks, 

kevin


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


Re: SCM git pushes rejected?

2021-11-01 Thread Kevin Fenzi
On Mon, Nov 01, 2021 at 02:51:49PM -0500, Richard Shaw wrote:
> This has happened to me twice today, it gets rejected the first time and
> then works:
snip...
> 
> Anyone else seeing this?

One other report: https://pagure.io/fedora-infrastructure/issue/10301

Not sure whats going on there yet, but please do all your info to the
ticket if you can... another datapoint might help track it down.

kevin


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


[EPEL-devel] Re: Planning to add a "distribution" component to EPEL product in BZ

2021-10-28 Thread Kevin Fenzi
On Thu, Oct 28, 2021 at 03:10:38PM -0400, Ben Cotton wrote:
> Hi folks,
> 
> In a conversation with Carl George and Troy Dawson earlier this week,
> we discussed the possibility of creating a "distribution" component in
> the EPEL product in Bugzilla. The idea would be that they could use it
> as a place for tracking bugs and other not-tied-to-a-specific
> component bugs.
> 
> I wanted to share this more broadly for feedback and to get
> suggestions on who should be the default contact. Is there a BZ
> account for the EPEL SIG or should I have Carl and Troy arm wrestle
> for it? :-)

There's no epel bz account I am aware of, but of course we could make
one. Or not. It doesn't seem worth it to me, I'd just say whoever wants
to be point of contact can be. I'll probibly add myself to CC since I
enjoy redirecting the misfiled bugs that will definitely appear (I do
that for fedora/distribution a lot). 

kevin


signature.asc
Description: PGP 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


Re: Pipeware issue in KDE after F34->F35

2021-10-25 Thread Kevin Fenzi
On Sun, Oct 24, 2021 at 11:34:29PM -0700, Adam Williamson wrote:
...snip...
> 
> The correct configuration is for pipewire to be enabled in the system
> session and wireplumber or pipewire-media-session to be enable in the
> user session (wireplumber should be the default). Either of those not
> being the case is going to result in broken audio. Both are supposed to
> be handled on upgrade from F34 already, but it looks like Neal spotted
> a case where it can be missed.

pipewire is a user unit as well.

Can you expand on what you mean by system session?

kevin


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


Re: Stability of armv7hl builders

2021-10-20 Thread Kevin Fenzi
On Wed, Oct 20, 2021 at 03:06:21PM +0200, Jakub Jelinek wrote:
> Hi!
> 
> I've been trying to build gcc in rawhide and f35 for more than a week now,
> but haven't succeeded due to instability of the armv7hl builders.
> E.g. the
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77117620
> build succeeded on all but armv7hl in less than 22 hours (on aarch64
> even took less than 5 hours), but armv7hl kept rebooting or whatever
> (impossible to find out from the logs) 8 times, see
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77117797
> Buildroots list.

It's kojid being OOM killed. So, it restarts, sees that it's not running
the build it's supposed to be, starts it over, gets OOM killed, repeat.

> Eventually I've cancelled that build after 151 hours, disabled
> LTO on armv7hl (for GCC bootstrap) and am building now
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77518894
> https://koji.fedoraproject.org/koji/taskinfo?taskID=77518968
> but those again show total time of ~ 21 hours, but armv7hl task times
> of 1.5 and 10 hours, so the f35 build was retried already 2 times and f36
> once.
> 
> Any recent kernel changes on the boxes, or is there any way to find out
> what's going on with them, whether it oopses, OOMs or something else?

Its OOM. 

It's basically this bug: 
https://bugzilla.redhat.com/show_bug.cgi?id=1920183
It's much less common with the kernels we are running (
5.12.19-300.fc34.armv7hl+lpae ) but it still does hit some packages. :( 

Nothing has changed on the builders. We are in final freeze and the only
changes made on them are security updates, and none of those look like
they would affect builds (vim, libjpeg-turbo, libvirt, openssh, curl)

I can try f35 + latest kernel in stg and see if it's any better or this
bug magically got fixed. :( 

> In late August the package built just fine and took ~ 27 hours to build on
> armv7hl.

Things should be like they were in late Aug. :( 

kevin


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


Re: F37 Change: Ansible 5 (Self-Contained Change proposal)

2021-10-20 Thread Kevin Fenzi
On Wed, Oct 20, 2021 at 06:24:21AM +, Zbigniew Jędrzejewski-Szmek wrote:
> FWIW, I think the upstream renaming of ansible and ansible-core is something
> that we just have to accept. But we have some flexibility in how this is
> packaged in Fedora.
...snip...
> 
> The Change proposal is not very clear in this regard… Please correct me
> if I'm wrong, but my understanding is that there's a giant SRPM which
> produces a giant 'ansible' binary package. In addition there's a second
> small SRPM which produces the 'ansible-core' binary package.

Right: 

https://files.pythonhosted.org/packages/9b/ed/5a6149a7e0314bfb99fd496781f84a96328e0eb0a85f5cb845c25fcb909a/ansible-4.7.0.tar.gz
(36MB)
https://files.pythonhosted.org/packages/be/1a/f40e97f4c400eec75813bc492f1d6226cd413bf03f88d5f00070a1e699a3/ansible-core-2.11.6.tar.gz
(7MB)

> When I'm reading Richard's proposal, I understand it as a giant SRPM
> package + ~95 binary packages. In your answer, you are clearly discussing
> ~95 SRPM packages with ~95 binary packages.
> 
> I agree that ~95 separate *source* packages is not a good approach:
> - the obvious reason is the packaging overhead you mention
> - but a more subtle reason is that upstream will test those 95 packages
>   in the versions listed in 'ansible' pypi package, so we want them in
>   the exact versions specified in the 'ansible' pypi package, and not
>   in the latest version each of those upstreams may have released.

Right. 

> But the approach with 1 SRPM and many *binary* packages seems pretty
> attractive:
> - it will be possible to install specific subset of the collection
>   as rpm packages. [Nico, does that answer you complaint about installation
>   size?]

Only if the seperately packaged collections are named differently, which
is another level of confusion I don't think we want.

ie, think if ansible 5.0 ships with ansible-collection-community-mysql
version 2.3.1 and fedora has a seperately packaged
ansible-collection-community-mysql 2.5.0. 

Users would get the updated version and not match the tested with
ansible 5.0 version.

>   To some extent this will match the split of *binary* packages of texlive.
>   is very useful when one knows the few specific subpackages that
>   one needs through the 'tex(foo.sty)' and 'tex(bar.tfm)' virtual provides.
> 
> - it is still possible to have an 'ansible' metapackage that pulls in
>   those binary packages or some subset.

It would need to pull in all those binary packages of exactly those
versions in order to match upstream, but it couldn't where collections
overlap seperately provided ones of different versions (unless named
differently). 

kevin


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


Re: Should I wait to push updates to F35?

2021-10-17 Thread Kevin Fenzi
On Sun, Oct 17, 2021 at 12:13:04PM -0500, Richard Shaw wrote:
> Since I've been a packager for more than 10 years I should know this but
> TBH, I've never really paid a whole lot of attention to the infra side of
> things.
> 
> So with the F35 beta process ongoing, would it be best to not build
> packages for <= f35?

No. You should build them for f35 if you are building for stable
releases in addition to rawhide.

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#final-freeze
> 
> Depending on how long the freeze lasts it's possible that an update to f34
> will go to stable before the f35 update even makes it into testing.

Yep. Thats ok. As soon as f35 is 'go' those f35 updates will go into a
f35-updates repo. 

kevin


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


Re: F37 Change: Ansible 5 (Self-Contained Change proposal)

2021-10-16 Thread Kevin Fenzi
On Sat, Oct 16, 2021 at 08:51:46PM -0500, Maxwell G via devel wrote:
> 
> Hi everyone,
> 
> I have a couple comments/questions about this change.
> 
> How will this effect EPEL? Is the plan to keep Ansible 2.9 there for
> now?

For now yes, but 2.9 will go EOL at the end of the year (last I heard). 

> Could we also consider making Ansible a modular package on both Fedora
> and EPEL? Then, it would be possible to install any of the currently
> supported versions of the Ansible core/engine (ansible 2.9, ansible-
> base 2.10, and ansible-core 2.11).

No thanks. It would be a ton of effort, and those will all EOL soon
or already have...

(from the ansible 4.7.0 release announcement: 

"* Except for ansible-2.9.x, older versions of ansible are no longer
seeing maintenance releases."

> Will the new `ansible` package have virtual provides for the
> collections it provides? While there is not a good reason to, it will
> still be possible to install both the new `ansible` package and any of
> the ansible-collection-* packages, right?

I don't think we will do provides, that would cause problems installing
the stand alone collections. So, yeah, we want to be able to install the
stand alone collections along with or in addition to the bundle.
 
> Also, I would be happy to help with Ansible packaging in Fedora;
> however, I am not yet part of the packager group and still need a
> sponsor.

Thanks. I appreciate the PR's... :) 

kevin


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


Re: F37 Change: Ansible 5 (Self-Contained Change proposal)

2021-10-16 Thread Kevin Fenzi
On Sat, Oct 16, 2021 at 10:02:38AM -0400, Nico Kadel-Garcia wrote:
> 
> it could have made good sense, and still would, for the "ansible"
> package to be what is now being colloquially referred to as
> "ansible-core", but for which the published upstream git repo is still
> https://github.com/ansible/ansible, and which is and will remain
> accessible as a github release tarball with the old numbering. The
> pypi.org published "ansible-core" is a republication of that repo with
> a new name duck-taped on it. Fragmenting out the bulky and potentially
> dynamic set of tools that are now in the "galaxy collections" suite
> makes some sense, but the result is that to get any of the core
> modules like "ansible.posix"  we wind up including 573 Megabytes of
> unneeded and unwelcome debris in
> /usr/lib/python3.6/site-packages/ansible_collections. Very few of us
> need more than 10% of the list

If you don't need more, don't install 'ansible'. Just install
ansible-core and use galaxy or seperate packaged collections to install
just what you need. 

> There is no specific source repository for the "ansible_collections"
> tarball, as best I can tell. The list of modules selected from the
> galaxy collection is very large, but incomplete and I've not seen any
> criteria for what goes in that tarball and what does not. Have you
> seen any?

Yes, but I can't seem to find it now. ;( 
Basically it was agreeing to use symantic versioning and agreeing to
release on the same schedule as the rest, etc. I don't know if there's
further requirements now. I'll find that doc and post it, but kinda
weekending now. ;) 

...snip...

kevin


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


Re: F37 Change: Ansible 5 (Self-Contained Change proposal)

2021-10-16 Thread Kevin Fenzi
On Sat, Oct 16, 2021 at 05:45:47PM -0400, Nico Kadel-Garcia wrote:
> 
> They *can* physically, but doing both together would get very silly.
> I'd meant "do one or the other". The current model of "install
> ansible, get a few Megabytes of material you actually use that is
> almost entirely in ansible-core and 576 Megabytes of bulky material,
> more than 90% of which you will never use" is awkward, and I'd much
> rather see the galaxy collection packages published, and remain,
> distinct. Discard the "ansible" package as an unwelcome approach, it's
> too big and too confusing.

Then don't install it? For others it's comforting and welcome. 
"Hey, I can install all this stuff and it will be available if I want to
use it, great!"

...snip...

> What, then, about the existing
> ansible-collection-ansible-netcommon-2.2.0-1.fc35.src.rpm and the
> like? Would those be swept up as part of the "ansible" package? I'd

no.

> dislike that, and if we or the current maintainers can keep them
> separate, it presrves the groundwork for a much more modular and much,
> much smaller ansible deployment.

collections can be packaged seperately. If you install 'ansible' and
some seperate collections thats just fine. The seperate collections will
be the version that gets used. So you can even up/downgrade from the
version in 'ansible' if you want. 

If you want to install ansible-core and seperate specific collections
you need, great, do that. 

...snip...

kevin


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


Re: F37 Change: Ansible 5 (Self-Contained Change proposal)

2021-10-15 Thread Kevin Fenzi
On Fri, Oct 15, 2021 at 07:44:12PM -0400, Nico Kadel-Garcia wrote:
> On Fri, Oct 15, 2021 at 7:29 PM Nico Kadel-Garcia  wrote:
> >
> > On Fri, Oct 15, 2021 at 4:32 PM Ben Cotton  wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/Ansible5
> > >
> > > == Summary ==
> > >
> > > The ansible project has re-organized how they release and distribute
> > > ansible. This change moves Fedora to be in sync with those changes and
> > > retires the old 'ansible classic/2.9.x' package in favor of a
> > > 'ansible' package that pulls in ansible-core (the engine) and includes
> > > all the collections in upstream ansible releases.
> >
> > I wrote to the various upstream bugtrackers about this already. The
> > re-org upstream is confusing and unwelcome, and creates a stack of
> > problems.

Yeah, it's been confusing to people for sure, but it does also help out
a lot with other problems. :( 

> > I would publish ansible-core as just that, with a "Provides: ansible
> > %{version{-%{release}" and even "Obsoletes: ansible >= %{version}".

That would radically diverge from upstream and cause _more_ confusion. 

It's unfortunate that the 'ansible' name meaning has changed, but
ignoring it or overriding the upstream name isn't going to help matters.

> > The new pypi.org tarball published as "ansible" isn't. It's a tarball
> > of components from the Ansible galaxy collection, and it is
> > unnecessary for the basic ansible-core operation, which are much
> > bulkier than the previous "ansible" and contains approximately 145
> > distinct software licenses. That is a sign of a packaging problem
> > that I've discussed on the pypi.org issues pages, at
> 
> I realize I was unclear. The new "ansible" tarball from pypi.org has
> 145 distinct software licenses, and many distinct galaxy collection
> published ansible modules. The new "ansible-core" tarball is much
> smaller, even smaller than the old "ansible" package due to some bulky
> modules being transferred to the galaxy collection.

Right.
 
> Splitting off the variety of add-on modules makes sense. Replacing the
> core package with the add-on modules and moving aside the core seems
> exactly backwards.

Well, I think the thought was that people would find ansible-core too
bare bones after having used ansible-2.9/classic with all it's included
modules.

If you don't want the collections, just install ansible-core.

kevin


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


Re: Ipsilon broken?

2021-10-13 Thread Kevin Fenzi
On Wed, Oct 13, 2021 at 04:23:46PM -0500, Richard Shaw wrote:
> I'm trying to log into COPR but when I press submit it just stays at the
> login page and doesn't forward me back to COPR.

This email looks a few hours old? What exact time were you seeing the
problems?

It's very likely it was during a short outage we had eariler today...

Anyhow, please try again, if it's still happening file a infra ticket
and we can track it down. (or mail ad...@fedoraproject.org if you can't
login to file a ticket).

Thanks,

kevin


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


Re: Self Introduction: Maxwell G (@gotmax23)

2021-10-12 Thread Kevin Fenzi
On Mon, Oct 11, 2021 at 10:44:14PM -0500, Maxwell G via devel wrote:
> Hi everyone,
> 
> I am Maxwell G or @gotmax23 on FAS and Github. I am relatively new to
> Linux but after trying different distros, I settled on Fedora. I don't
> have a lot of time between school and having chronic pain, but I'd like
> to give back and contribute as much as I can.
> 
> I created a package for yt-dlp, a fork of youtube-dl with extra fixes
> and features, and submitted a [review request][1] on Bugzilla. I still
> need a sponsor and someone to review my submission.
> 
> I am a big Ansible user and would be happy help with Fedora's Ansible
> packages. I already maintain `ansible-collection-community-general`on
> the AUR, so it would be non-trivial for me to maintain it in Fedora. I
> have identified some other areas I could help with, but I don't want to
> bite off more than I can chew. Either way, I will [continue][2]
> submitting PRs to fix issues or update versions for the packages that I
> use.

Thanks for the PR's! :) 

kevin


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


Re: Reasons to subscribe to the package-announce list?

2021-10-11 Thread Kevin Fenzi
On Mon, Oct 11, 2021 at 09:45:59PM +0300, Otto Urpelainen wrote:
> 
> Sure, making people aware of all the tooling that is available is good. But
> the volume of messages in those lists is so large that I cannot believe it
> is a good idea to subscribe, unless some kind of automatic processing is
> implemented.

Yeah, I don't personally see much use for package-announce anymore. It
was started back in the day before rss feeds and other tools. 
scm-commits I think is still valuable as it's a record of all commits,
so anyone interested can see and it's distributed so after the commits
there's no way to rewite the emails. :) That said, subscribing to it by
a human isn't too great now... the volume is just too much to even skim. 
Back in the old days I used to read they all the commits (and caught
some fun bugs too), but its just not possible anymore. 

> So, I am no thinking of keeping the list of important mailing lists really
> short, but the modify the "Find software you wish to package/maintain for
> Fedora" a bit. It now starts from the assumption that each new maintainer is
> going to add their very own package. Since it is also useful to help out
> with the existing ones, that section could also explain how to get
> notifications from interesting packages. There, both the Watch setting at
> Package Sources and these mailing lists can be discussed.

Yeah, that makes perfect sense. 

kevin


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


Re: Fedora rawhide compose report: 20211010.n.0 changes

2021-10-11 Thread Kevin Fenzi
On Mon, Oct 11, 2021 at 11:37:41PM +0900, Mamoru TASAKA wrote:
> Jerry James wrote on 2021/10/11 23:26:
> > On Sun, Oct 10, 2021 at 7:26 AM Fedora Rawhide Report
> >  wrote:
> > > = DOWNGRADED PACKAGES =
> > > Package:  python-pip-21.2.3-2.fc36
> > > Old package:  python-pip-21.2.3-4.fc36
> > > Summary:  A tool for installing and managing Python packages
> > > RPMs: python-pip-doc python-pip-wheel python3-pip
> > > Size: 3.56 MiB
> > > Size change:  290.52 KiB
> > 
> > What happened here?  The 21.2.3-2 build is from August 16.
> > 
> 
> $ koji list-history --build python-pip-21.2.3-4.fc36
> Thu Oct  7 05:24:37 2021 python-pip-21.2.3-4.fc36 tagged into 
> f36-updates-candidate by cstratak
> Thu Oct  7 05:24:42 2021 python-pip-21.2.3-4.fc36 tagged into 
> f36-signing-pending by bodhi
> Thu Oct  7 05:36:03 2021 python-pip-21.2.3-4.fc36 untagged from 
> f36-signing-pending by autopen
> Thu Oct  7 05:36:03 2021 python-pip-21.2.3-4.fc36 tagged into 
> f36-updates-testing-pending by autopen
> Thu Oct  7 05:37:00 2021 python-pip-21.2.3-4.fc36 tagged into f36 by bodhi
> Thu Oct  7 05:37:04 2021 python-pip-21.2.3-4.fc36 tagged into eln by 
> distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org [still active]
> Thu Oct  7 05:37:06 2021 python-pip-21.2.3-4.fc36 untagged from 
> f36-updates-testing-pending by bodhi
> Thu Oct  7 05:37:07 2021 python-pip-21.2.3-4.fc36 untagged from 
> f36-updates-candidate by bodhi
> Sun Oct 10 10:57:01 2021 python-pip-21.2.3-4.fc36 untagged from f36 by kevin
> 
> So python-pip-21.2.3-4.fc36 is untagged (I don't know the reason) and
> the latest package for python-pip is now 21.2.3-2.fc36

Yeah, I was asked to untag that after untagging the latest python3.10
package. 

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

This is what failed rawhide composes from 20211006 to 20211009.

kevin


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


Re: Reasons to subscribe to the package-announce list?

2021-10-10 Thread Kevin Fenzi
On Sun, Oct 10, 2021 at 02:14:06PM +0300, Otto Urpelainen wrote:
> Hello,
> 
> Package Maintainer Docs currently recommend joining the package-announce
> mailing list in two places [1,2], describing it as follows:
> 
> > You should also consider joining the package-announce mailing list — 
> > The commits mailing list gets notifications on all commits in any
> > package in the Fedora repository. This is a very high traffic mailing
> > list. The Fedora package database sends commit mails for packages you
> > (co-)maintain.

Odd. thats... not the right description. Thats the description for the
scm-commits list? 

package-announce gets updates announcements of all the packages going to
stable updates through bodhi. 
 
> I wonder, would it be better to drop this recommendation? Instead, it could
> be recommended to go to Package Sources and adjust the Watch setting for
> individual packages as needed? The paragraph quoted above is already kind of
> recommending that approach in the last sentence.
> 
> What are the use cases where subscribing to the package-announce mailing
> list is better than watching individual packages? Are the use cases common
> enough that the mailing list deserves to be called "important" and be
> recommended for everybody interested in Fedora packaging?

Yes, I think it might be worth mentioning these lists, but not
reccomending subscribing unless interested. Something like: 

There are some completely optional lists that contain posts about all
packages: scm-commits, which has the commits for every package in fedora
posted to it, and package-announce, which has every stable update notice
posted to it as packages are pushed stable. Both of these are very high
traffic mailing lists and are only suggested if you have the time and
energy to watch all the changes going on in fedora packages. 

Or something like that. 

kevin


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


Re: Onboarding package

2021-10-04 Thread Kevin Fenzi
On Mon, Oct 04, 2021 at 02:42:58PM -0400, Matthew Miller wrote:
> On Mon, Oct 04, 2021 at 05:52:33PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > I like the idea! 
> > > We can block such a package from ever appearing in a compose in pungi. 
> > Is this really necessary? The package will not be open to anyone,
> > but only for approved contributors. Malicious behaviour is not more
> > likely then in any other package (and would be immediately caught).
> > I think we're thinking up technical solutions to something that is
> > not a problem.
> 
> Yeah, I think making it a real package is a good idea. Maybe even a little
> packaged script that runs
> 
>   xdg-open https://docs.fedoraproject.org/en-US/fedora-join/
> 
> ?
> 
> The package itself can even be a gateway to onboarding for the curious, but
> more importantly, it'd act more like a real package.

True. As long as there's a group of experenced folks watching it, that
should be ok. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
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-04 Thread Kevin Fenzi
On Mon, Oct 04, 2021 at 01:03:27PM -0400, 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).

We have avoided using emulation in the past because we would be chasing
bugs in our emulation that aren't in real hardware and vice versa. 
How good is the emulation support? Do we know/have people who can fix
things in it when we hit them? Tools folks: is emulation an option here?
Or do we still forbid it?

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

Well, one big thing is that it's been a while since we had any secondary
arches and it's unclear how they would work today. In the distant past
secondary arches had their own koji and builders and composes and
releases and used koji-shadow to try and match up with primary koji.
This was basically more than a full time job for someone and I am sure
koji-shadow has atrophied in recent years, but perhaps at least some
subset could be made to work again. 

On the other hand we could just add it into primary koji, but then it
really really has to keep up or it's going to block everything else. 

So, probibly a 'secondary' koji and builders to start with to bootstrap
and to gather info on how hard it is to keep up and good emulation is
would be worthwhile, but it's gonna need some dedicated work.

Perhaps we could get a up to date status report from folks working on
this, answering such questions as:

* How good is emulation support
* What would it take to keep up with the other arches? Is that possible?
* What device(s) would we want to target and could we get sufficent
numbers of them for QA and devel folks to debug problems and test?
* Are there folks who can bootstrap/shepard the koji shadowing process?

I think RISC-V is pretty exciting, and I am happy to help as much as I
can with adding it in. I think there's likely to be a lot of
interest/growth in coming years for it.

kevin


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


Re: Onboarding package

2021-10-04 Thread Kevin Fenzi
On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote:
> Thoughts?

I like the idea! 

We can block such a package from ever appearing in a compose in pungi. 

So, perhaps we seperate it into: 


open a bug, submit a pr, do a scratch build, look at ci 


get added as commit to onboarding package
create pr, merge pr, do official build, submit update, etc

Another possible way we could do this is have this setup in our staging
env. ie, they do the same things, but it's in staging (which we never
compose anyhow). That has the danger of something being broken in stg
without us realizing it, or them diverging. 

Great idea tho, I like it. 

kevin


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


Re: Git-multimail, are we going to miss it?

2021-10-01 Thread Kevin Fenzi
On Wed, Sep 29, 2021 at 06:54:32PM +0200, Miroslav Suchý wrote:
> Dne 29. 09. 21 v 14:10 Ondrej Pohorelsky napsal(a):
> > Hi,
> > 
> > In the latest git release (2.33.0), upstream stopped shipping
> > git-multimail. We are currently shipping it in Fedora with git-2.32.0,
> > but not as a standalone package.
> > 
> > The reason for removing git-multimail from contrib/ is that it might
> > attract more attention as a standalone project and to prevent it from
> > being stale.
> 
> Fedora infrastructure uses it for sending mails to a group when somebody 
> commits for fedora-infrastructure's git.

We do have a fork of it in our ansible repo (as modified by gnome folks
before us). I think we only use it for 2 internal repos at this point.
:) 

So, I don't think this is going to be too much problem. 

kevin


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


Re: Max age of side tags?

2021-09-28 Thread Kevin Fenzi
On Mon, Sep 27, 2021 at 05:25:33PM +0100, Richard W.M. Jones wrote:
> On Mon, Sep 27, 2021 at 08:40:08AM -0700, Kevin Fenzi wrote:
> > On Mon, Sep 27, 2021 at 11:58:44AM +0100, Richard W.M. Jones wrote:
> > > OCaml 4.13 has just come out and we'll be rebuilding all the OCaml
> > > packages in Rawhide into a side tag.  Jerry James - who maintains some
> > > of these packages - is not going to be available this week.  That
> > > means if I starts the builds now, we might need to keep the side tag
> > > open for 2 or 3 weeks, whereas normally we'd complete everything in a
> > > few days.
> > > 
> > > Is this a problem?  I vaguely recall that side tags had a short
> > > maximum age (2 weeks?) but I cannot find anything about that in the
> > > docs now.
> > > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/
> > > 
> > > If it's a problem then I can start doing the builds next week instead.
> > 
> > It's currently set to clean up/remove side tags that are over 30days
> > old, or over 14 days with nothing tagged into them. 
> > 
> > There was an announcement email, but yeah, should also be in docs. 
> > Any thoughts on where best to put it?
> 
> I guess it's good that I wasn't imagining it!  In the page
> linked above probably.

https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/34

kevin


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


Re: Using YubiKey for accounts.fedoraproject.org OTP?

2021-09-27 Thread Kevin Fenzi
On Mon, Sep 27, 2021 at 04:28:03PM +0200, Miro Hrončok wrote:
> On 27. 09. 21 16:07, Pierre-Yves Chibon wrote:
> > On Mon, Sep 27, 2021 at 03:27:43PM +0200, Miro Hrončok wrote:
> > > Hello,
> > > 
> > > I've been trying to add the OPT token from accounts.fedoraproject.org to 
> > > my
> > > yubikey. I get a QR code and a otpauth://totp/username?secret=xxx URI.
> > > 
> > > I copypasted the xxx secret (56 characters: digits and uppercase letters)
> > > and tried to add it via YubiKey Manager GUI via Applications/OTP as
> > > OATH-HOTP (6 digits).
> > > 
> > > I get "Failed to configure Long Touch (Slot 2). undefined" error.
> > > 
> > > When I tried to use the CLI:
> > > 
> > >  $ ykman otp hotp -d 6 -c 0 2 xxx
> > > 
> > > I get "Error: key lengths >20 bytes not supported".
> > > 
> > > Is there a way to use YubiKey for accounts.fedoraproject.org OTP, or is 
> > > the
> > > device not compatible?
> > 
> > You may want to check: https://github.com/fedora-infra/noggin/issues/202
> 
> Thanks. From that ticket I am not quite sure what the status actually is and
> what are the next step. Should I post my failed experiment there?

My understanding: IPA supports yubikey HOTP, but noggin (the web
frontend) does not. So, it's not supported currently. You must use TOTP. 
:( 

I'll poke that ticket and see if we can move forward tho. 

kevin


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


Re: Max age of side tags?

2021-09-27 Thread Kevin Fenzi
On Mon, Sep 27, 2021 at 11:58:44AM +0100, Richard W.M. Jones wrote:
> OCaml 4.13 has just come out and we'll be rebuilding all the OCaml
> packages in Rawhide into a side tag.  Jerry James - who maintains some
> of these packages - is not going to be available this week.  That
> means if I starts the builds now, we might need to keep the side tag
> open for 2 or 3 weeks, whereas normally we'd complete everything in a
> few days.
> 
> Is this a problem?  I vaguely recall that side tags had a short
> maximum age (2 weeks?) but I cannot find anything about that in the
> docs now.
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/
> 
> If it's a problem then I can start doing the builds next week instead.

It's currently set to clean up/remove side tags that are over 30days
old, or over 14 days with nothing tagged into them. 

There was an announcement email, but yeah, should also be in docs. 
Any thoughts on where best to put it?

kevin


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


  1   2   3   4   5   6   7   8   9   10   >