date:20201204

No missing expected images.

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

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

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

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] 389 DS nightly 2020-12-05 - 94% PASS

2020-12-04 Thread vashirov

https://fedorapeople.org/groups/389ds/ci/nightly/2020/12/05/report-389-ds-base-2.0.1-20201205gitdec149b.fc33.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Bug 1904632] New: perl-File-Edit-Portable-1.25 is available

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

Bug ID: 1904632
   Summary: perl-File-Edit-Portable-1.25 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-File-Edit-Portable
  Keywords: FutureFeature, Triaged
  Assignee: de...@fateyev.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.25
Current version/release in rawhide: 1.24-15.fc33
URL: http://search.cpan.org/dist/File-Edit-Portable/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/9325/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1904632] perl-File-Edit-Portable-1.25 is available

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1736592
  --> https://bugzilla.redhat.com/attachment.cgi?id=1736592=edit
[patch] Update to 1.25 (#1904632)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1903541] perl-Encode-3.08 is available

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



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1903541] perl-Encode-3.08 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Reducing noise on devel list

2020-12-04 Thread Adam Williamson

On Fri, 2020-12-04 at 15:43 -0600, Dennis Gilmore wrote:
> Hi all,
> 
> I filed https://pagure.io/fesco/issue/2512 asking FESCo to move all
> automated emails to a separate list where people who want to follow
> can, while I was part of the proliferation of compose reports coming
> here, there is now a great deal of them, and they no longer seem to
> trigger any conversation. I think that devel list would benefit from
> having all automated reports sent to a reports-list and letting people
> bring reports over when there is something to discuss. I was asked to
> bring the request to the list for people to weigh in.

As someone who generates half these reports, I'd be fine with that,
though it does make them somewhat less discoverable. I'd suggest we
should look for places people find devel@ and link to the new reports@
or whatever from those places too.

If anyone winds up trying to find out where we decide where to mail
"compose check reports", this is it:

https://pagure.io/fedora-infra/ansible/blob/master/f/inventory/group_vars/checkcompose

checkcompose_emailto would be the thing to change.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


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

Re: Orphaned packages looking for new maintainers


On 12/4/20 11:14 PM, Robert-André Mauchin wrote:

On 11/30/20 12:12 PM, Miro Hrončok wrote:

golang-github-casbin  go-sig, orphan   0 weeks ago
golang-k8s-kubernetes go-sig, orphan   1 weeks ago


I don't get why these were orphaned, I fixed them back in August.


The FTBFS bugzillas were in NEW when they were orphaned via 
https://pagure.io/releng/issue/9860


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

(I know this is not ideal, improvements of the process are more than welcome.)

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

2020-12-04 Thread pboy



> Am 04.12.2020 um 23:16 schrieb Japheth Cleaver :
> 
> On 12/4/2020 12:35 PM, Stephen John Smoogen wrote:
>> 
>> ... 
>> 
>> For the people who were using it as servers, it was split between getting 
>> ready for the next RHEL/CentOS they would be deploying, they needed packages 
>> which were not in EPEL, or things like python/nodejs/etc was new enough for 
>> what they needed to run but wasn't in EL8.
>> 
> It would be interesting to consider how Fedora Server use cases change over 
> time during an EL release cycle.
> 
> For many server use cases where the box is NOT ephemeral, when CentOS and 
> Fedora are similar, it's likely that CentOS is going to be a 
> better-engineered and tested option. But as time goes on and the next EL 
> release isn't either isn't announced or isn't stable enough to rely on, 
> Fedora Server probably sees more use as a quasi-stable release base.. This 
> fills a real need when your users are absolutely clamoring for things that 
> aren't likely to be   backported into the stable EL release and you don't 
> want to have to send them into Ubuntu/Debian land (or have them grab an 
> un-administered container off the shelf).

Fedora has advantages not only when RHELx / CentOSx is matured, but in some 
cases already at release time, when some important components are already 
„behind“, e.g. postfix / dovecot with CentOS 8 regarding SNI and submission 
(which are quite important features in a containerised world). And with the 
current rapid development, even small version differences can be important.

> In fact, Fedora Server as a "not EL, but better than nothing as a temporarily 
> stable platform" during these later periods could be a useful niche to fill. 
> Bonus points for some of those extended support duration/stable discussions 
> from a few years ago.


I see advantages sui generis in Fedora Server over CentOS, not "just" an 
interim solution or workaround until the next CentOS version is released. You 
get (almost) all the positive features that make CentOS /RHEL stand out (well 
thought-out architecture and workflows, security, systematic tools, etc.) and 
additionally
- more up-to-date application software, which often enables a better response 
to current developments and changing requirements
- easier administration due to a greater variety of available packages
- shorter release jumps, which are therefore less disruptive 
- easier (quasi rolling) updates (dnf update), which save a lot of time
- Freedom from strict RH feature management (example BTRFS, XEN some years ago)
- greater backwards hardware compatibility (e.g. exclusion of drivers in el 8, 
which make some older hardware unusable or only very difficult to use)

The list can easily be extended.


--
Dr. Peter Boy
p...@boy-digital.de
p...@uni-bremen.de



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

Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

2020-12-04 Thread pboy

> Am 04.12.2020 um 20:33 schrieb Matthew Miller :
> 
> On Fri, Dec 04, 2020 at 07:53:12PM +0100, p...@uni-bremen.de wrote:
>> Just in case it is indeed considered useful and desirable I could
>> contribute various Fedora Server related/specific documentations and
>> how-to's, e.g. an annotated step-by-step guide to setup a basic server
>> which can get extended for various purposes, how to set up a Postgres
>> server on top of a basic server, an infrastructure for vm’s and containers
>> (including scripts and ansible templates), troubleshooting guides, and
>> other topics like that (mostly practical but always together with
>> preliminary strategic considerations). Just let me know.
> 
> 
> Absolutely! A functioning Working Group needs people interested in and doing
> these kinds of things too, not just package maintenance. So if you're
> interested, you'd absolutely be welcome in a re-constituted Fedora Server
> WG.

OK, I would like to participate and contribute to the documentary side.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]

2020-12-04 Thread Samuel Sieb


On 12/3/20 1:01 PM, Miroslav Suchý wrote:

Dne 03. 12. 20 v 20:02 Matthew Miller napsal(a):

Mostly the latter. I don't even really care if they end up keeping the
distinct os-release and etc.


Is this backed by some numbers and analysis?

My personal usage is that I create **hundred thousands** VM from Fedora cloud 
image per year.
And I use one or two netinstall images to deploy new home server for me or 
friend.
And one or two runnable images when I persuade someone to try Fedora.

Cloud image clearly wins the number by orders of magnitude. But without the 
later we do not get the penetration and new
users. And no one willing to use cloud images.


I think you snipped too much and misunderstood the meaning.  My 
understanding is that Matthew is suggesting to merge the cloud and 
server editions into one thing and there doesn't need to be a distinct 
os-release for both of them.  e.g. the "cloud" has the "server" 
os-release and is just a differently packaged version of the server 
edition.  He's not saying that one or the other will go away.  There 
just needs to be different marketing of the cloud packaged server edition.

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

[Bug 1904607] perl-DateTime-1.54 is available

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



--- Comment #1 from Upstream Release Monitoring 
 ---
An HTTP error occurred downloading the package's new Source URLs: Getting
https://cpan.metacpan.org/modules/by-module/DateTime/DateTime-1.54.tar.gz to
./DateTime-1.54.tar.gz


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1904607] New: perl-DateTime-1.54 is available

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

Bug ID: 1904607
   Summary: perl-DateTime-1.54 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DateTime
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.54
Current version/release in rawhide: 1.53-1.fc34
URL: http://search.cpan.org/dist/DateTime/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/2787/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

On Fri, Dec 4, 2020 at 4:39 PM Gary Buhrmaster
 wrote:
>
> On Fri, Dec 4, 2020 at 9:24 PM DJ Delorie  wrote:
>
> > But fedoras aren't made of sheets of main, they're made from sheets of
> > rawhide...
>
> Actually, fedoras can be made from many different
> source materials (straw, cotton, hemp, etc.) in
> addition to rawhide.
>

I'm pretty sure ours is made from Cotton. :)



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

Re: Reducing noise on devel list

On Fri, Dec 04, 2020 at 03:43:04PM -0600, Dennis Gilmore wrote:
> I filed https://pagure.io/fesco/issue/2512 asking FESCo to move all
> automated emails to a separate list where people who want to follow
> can, while I was part of the proliferation of compose reports coming
> here, there is now a great deal of them, and they no longer seem to
> trigger any conversation. I think that devel list would benefit from
> having all automated reports sent to a reports-list and letting people
> bring reports over when there is something to discuss. I was asked to
> bring the request to the list for people to weigh in.

I feel like I requested this several years ago and was widely shot down. But
perhaps times have changed. :)


-- 
Matthew Miller

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

Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

On Fri, Dec 04, 2020 at 02:16:23PM -0800, Japheth Cleaver wrote:
> be a better-engineered and tested option. But as time goes on and
> the next EL release isn't either isn't announced or isn't stable
> enough to rely on, Fedora Server probably sees more use as a
> quasi-stable release base.. This fills a real need when your users
> are absolutely clamoring for things that aren't likely to be
> backported into the stable EL release and you don't want to have to
> send them into Ubuntu/Debian land (or have them grab an
> un-administered container off the shelf).

Yeah, we may have an opportunity to do this better with CentOS Stream.
Starting with RHEL 8, there's no more "next EL isn't announced" -- instead,
they're every three years. So, we know when Fedora ELN is going to flow into
CentOS Stream and from there to RHEL. We could actually position and label
each Fedora Server release by where it fits on the wave of that cadence.




-- 
Matthew Miller

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

Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

2020-12-04 Thread Japheth Cleaver


On 12/4/2020 12:35 PM, Stephen John Smoogen wrote:


Anecdata which is as 'useful' as any other.

Most of the people I have dealt with in the last 4 years with Server 
have been using it mainly as a replacement for the Everything DVD and 
because it was the most 'un-opinionated' release of Fedora. It wasn't 
actually being used in any more of a server release as much as a 'get 
out of my way' while still using Fedora.


For the people who were using it as servers, it was split between 
getting ready for the next RHEL/CentOS they would be deploying, they 
needed packages which were not in EPEL, or things like 
python/nodejs/etc was new enough for what they needed to run but 
wasn't in EL8.


It would be interesting to consider how Fedora Server use cases change 
over time during an EL release cycle.


For many server use cases where the box is NOT ephemeral, when CentOS 
and Fedora are similar, it's likely that CentOS is going to be a 
better-engineered and tested option. But as time goes on and the next EL 
release isn't either isn't announced or isn't stable enough to rely on, 
Fedora Server probably sees more use as a quasi-stable release base.. 
This fills a real need when your users are absolutely clamoring for 
things that aren't likely to be backported into the stable EL release 
and you don't want to have to send them into Ubuntu/Debian land (or have 
them grab an un-administered container off the shelf).


In fact, Fedora Server as a "not EL, but better than nothing as a 
temporarily stable platform" during these later periods could be a 
useful niche to fill. Bonus points for some of those extended support 
duration/stable discussions from a few years ago.


Ultimately, however, I feel like the use case of Fedora Server is 
inexorably tied to the RHEL/CentOS (or CentOS Stream) discussions. And a 
Fedora WG that tries to do long-term planning and positioning needs to 
be part of those overall discussions for the greater good of the RedHat 
ecosystem. Short term marketing is fine, but the different sides of 
RedHat need to be on the same page about this all.


-jc

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

Re: Reducing noise on devel list

2020-12-04 Thread Petr Šabata

On Fri, Dec 4, 2020 at 10:46 PM Dennis Gilmore  wrote:
> Hi all,
>
> I filed https://pagure.io/fesco/issue/2512 asking FESCo to move all
> automated emails to a separate list where people who want to follow
> can, while I was part of the proliferation of compose reports coming
> here, there is now a great deal of them, and they no longer seem to
> trigger any conversation. I think that devel list would benefit from
> having all automated reports sent to a reports-list and letting people
> bring reports over when there is something to discuss. I was asked to
> bring the request to the list for people to weigh in.

+1, thank you.

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

Re: Orphaned packages looking for new maintainers

2020-12-04 Thread Robert-André Mauchin


On 11/30/20 12:12 PM, Miro Hrončok wrote:
golang-github-casbin  go-sig, orphan   0 
weeks ago
golang-k8s-kubernetes go-sig, orphan   1 
weeks ago


I don't get why these were orphaned, I fixed them back in August.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Reducing noise on devel list

2020-12-04 Thread Dennis Gilmore

Hi all,

I filed https://pagure.io/fesco/issue/2512 asking FESCo to move all
automated emails to a separate list where people who want to follow
can, while I was part of the proliferation of compose reports coming
here, there is now a great deal of them, and they no longer seem to
trigger any conversation. I think that devel list would benefit from
having all automated reports sent to a reports-list and letting people
bring reports over when there is something to discuss. I was asked to
bring the request to the list for people to weigh in.

Thanks

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

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

2020-12-04 Thread Gary Buhrmaster

On Fri, Dec 4, 2020 at 9:24 PM DJ Delorie  wrote:

> But fedoras aren't made of sheets of main, they're made from sheets of
> rawhide...

Actually, fedoras can be made from many different
source materials (straw, cotton, hemp, etc.) in
addition to rawhide.

There are some workflows such that I have
occasionally wished rawhide was just another
branch off of the primary (main/master) repo
just like the F33 branch.  But we can all adapt.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

2020-12-04 Thread Felix Schwarz



Am 04.12.20 um 21:35 schrieb Stephen John Smoogen:

Anecdata which is as 'useful' as any other.


just some additional experience from my side:
- Fedora provides a recent PHP (unlike RHEL 7) but also ships the full PHP stack
  required to run popular PHP applications like WordPress/NextCloud/...
  AFAIK due to modularity and build-only RPMs it is still quite hard (on RHEL 8)
  to get PHP-related rpms required to deploy these PHP applications.
  With Fedora it works like a breeze.

- Fedora works well, no breaking updates in our server use

- also a lot of recent tech available: wireguard, systemd daemons

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

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

2020-12-04 Thread DJ Delorie

Daniel P. Berrangé  writes:
> Perhaps this is heresy, but we could stop calling our main development
> stream "rawhide", and instead call it "main", then it will be trivially
> aligned with the "main" git branch name :-)

But fedoras aren't made of sheets of main, they're made from sheets of
rawhide...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

2020-12-04 Thread Petr Šabata

On Fri, Dec 4, 2020 at 8:48 PM Kevin Fenzi  wrote:
>
> On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote:
> > Also a couple of notes on modularity here:
> >
> > # By default, module stream name is derived from the branch name
> > If we have any "master" modules, those will get unexpectedly renamed
> > as soon as they get rebuilt. This might impact tagging or updates and
> > cause confusion in general. We should check if there are any like that
> > and decide on further steps.
>
> Good thing to check yes. I can try and do so.

Thanks.

> > # Modules might be pulling components from their master branches to
> > build Rawhide artifacts
> > There are various use cases for this, too long to list. If the master
> > ref is no longer available, these will not build. Modulemd files that
> > pull components from master need to be updated after Phase 2.
>
> Yep. +1

Great, will you do that, too?

> > # The modulemd component ref is optional and defaults to master
> > Unless this got changed later, if the ref field is omitted, the value
> > defaults to "master". This is part of the specification and is handled
> > by libmodulemd. Not sure how to proceed here.
>
> Can we change the default?

According to Vít that's already happened (for completely unrelated
reasons), so we're good here.

> > And besides modularity:
> >
> > There are people and teams who use bots to autobuild their upstream
> > projects in Rawhide. If they have a bot account (and I hope they do),
> > they should be notified to update their tooling.
>
> We don't have much tracking on bot accounts. People make them and sign
> up for fas for them, etc.
>
> We can try and find things that are obvious, but we are likely to miss
> some. We can definitely help people who notice breakage tho.

Ah, I kinda expected these accounts to be clearly marked as being
non-human. Oh well.

Anyway, besides the magical module stream renames, all of this should
continue to work fine if we get the symbolic refs, I think?

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

Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

2020-12-04 Thread Dominik 'Rathann' Mierzejewski

On Friday, 04 December 2020 at 20:51, Josh Boyer wrote:
[...]
> For those using it for traditional server use cases, why?  What about
> it do you find better than something like CentOS?

Here are my reasons, in no particular order:
1. Because that's what I use on my desktops.
2. Because latest software versions.
3. Because I don't have to maintain all the packages I'm interested in
for EPEL, too.
4. Because it works so well.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

2020-12-04 Thread Stephen John Smoogen

On Fri, 4 Dec 2020 at 15:17, Matthew Miller 
wrote:

> On Fri, Dec 04, 2020 at 02:51:45PM -0500, Josh Boyer wrote:
> > It would be interesting if we had a set of use cases Fedora Server
> > actually solves.  So far in this thread we've seen people use it, but
> > it reads to me like they use it to get a boiled down installation of
> > Fedora.  So is Fedora Server just a convenient way to get a quick and
> > simple Fedora installation (e.g. you're using it because it's
> > *Fedora*), or do people actually use it for traditional server use
> > cases.
> >
> > For those using it for traditional server use cases, why?  What about
> > it do you find better than something like CentOS?
>
> Yeah, this is absolutely another valuable idea. The Use Cases and Personas
> at
> https://fedoraproject.org/wiki/Server/Product_Requirements_Document#User_Profiles.2C_Primary_Use_Cases_and_Goals
> were created *seven* years ago and reflect aspiration, not nessarily
> reality. So it would be very valuable for interested people to update that
> to reflect both actual current use and the current aspirations.
>
>
>
Anecdata which is as 'useful' as any other.

Most of the people I have dealt with in the last 4 years with Server have
been using it mainly as a replacement for the Everything DVD and because it
was the most 'un-opinionated' release of Fedora. It wasn't actually being
used in any more of a server release as much as a 'get out of my way' while
still using Fedora.

For the people who were using it as servers, it was split between getting
ready for the next RHEL/CentOS they would be deploying, they needed
packages which were not in EPEL, or things like python/nodejs/etc was new
enough for what they needed to run but wasn't in EL8.


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


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

Re: summary of matrix/element chat discussion

On Fri, Dec 04, 2020 at 07:29:41PM +0100, Vitaly Zaitsev via devel wrote:
> Most public services (GitHub, GitLab, etc.) use separate domains for
> the user content.

I looked into this a little bit, and it appears that the primary concern is
cross-site scripting attacks, not a legal separation. See
https://developer.github.com/changes/2014-04-25-user-content-security/

I am not a lawyer, but it's my understanding that having a different domain
name doesn't actually provide any particularly strong legal shield. But, my
amateur lawyer-opining on the devel list isn't really very valuable -- if
you have a concern, please bring it directly to le...@fedoraproject.org and
feel free to CC me. Thanks.

-- 
Matthew Miller

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

Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

On Fri, Dec 04, 2020 at 02:51:45PM -0500, Josh Boyer wrote:
> It would be interesting if we had a set of use cases Fedora Server
> actually solves.  So far in this thread we've seen people use it, but
> it reads to me like they use it to get a boiled down installation of
> Fedora.  So is Fedora Server just a convenient way to get a quick and
> simple Fedora installation (e.g. you're using it because it's
> *Fedora*), or do people actually use it for traditional server use
> cases.
> 
> For those using it for traditional server use cases, why?  What about
> it do you find better than something like CentOS?

Yeah, this is absolutely another valuable idea. The Use Cases and Personas
at 
https://fedoraproject.org/wiki/Server/Product_Requirements_Document#User_Profiles.2C_Primary_Use_Cases_and_Goals
were created *seven* years ago and reflect aspiration, not nessarily
reality. So it would be very valuable for interested people to update that
to reflect both actual current use and the current aspirations.


-- 
Matthew Miller

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

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

On Fri, Dec 04, 2020 at 11:09:01AM -0800, Kevin Fenzi wrote:
> I always thought it could be something better like 'headwaters' or
> something. But that gets us into a big long bikeshed. :( 

I thought we'd all already settled on Primordial Soup. :)

-- 
Matthew Miller

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

Re: summary of matrix/element chat discussion

On Fri, Dec 04, 2020 at 07:29:41PM +0100, Vitaly Zaitsev via devel wrote:
> fedoraproject.org is the main Matrix server with all user content.

Or whatever we decide to call it. I am super-unclear on what you're saying
about using a different domain here and what that would buy us. I note that
if I go to https://chat.mozilla.org/#/welcome, it says:

  Homeserver:   https://mozilla.modular.im
  Identity server:  https://vector.im


> >Can you also clarify "can always be viewed"?
> Matrix is similar to Git. When you join any room, all events and
> content will be copied to your homeserver.
> 
> For example #foobar:example.org contains pirated content. When you
> join it from your fedoraproject.org account, most of its contents
> will be copied to this server and can be viewed by direct hyperlinks
> (until the cache is purged).

We will be getting this service as SaaS with active administration from the
Element team. Red Hat will have a standard contract for services. I am
confident that this can all be handled in a way that is acceptable.


-- 
Matthew Miller

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

Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

2020-12-04 Thread Josh Boyer

On Fri, Dec 4, 2020 at 2:33 PM Matthew Miller  wrote:
>
> On Fri, Dec 04, 2020 at 07:53:12PM +0100, p...@uni-bremen.de wrote:
> > I’m not a maintainer but I use Fedora Server for a lot of our university
> > research institutions infrastructure (and I’m a dormant member of Fedora
> > docs).
> >
> > Just in case it is indeed considered useful and desirable I could
> > contribute various Fedora Server related/specific documentations and
> > how-to's, e.g. an annotated step-by-step guide to setup a basic server
> > which can get extended for various purposes, how to set up a Postgres
> > server on top of a basic server, an infrastructure for vm’s and containers
> > (including scripts and ansible templates), troubleshooting guides, and
> > other topics like that (mostly practical but always together with
> > preliminary strategic considerations). Just let me know.
>
>
> Absolutely! A functioning Working Group needs people interested in and doing
> these kinds of things too, not just package maintenance. So if you're
> interested, you'd absolutely be welcome in a re-constituted Fedora Server
> WG.

It would be interesting if we had a set of use cases Fedora Server
actually solves.  So far in this thread we've seen people use it, but
it reads to me like they use it to get a boiled down installation of
Fedora.  So is Fedora Server just a convenient way to get a quick and
simple Fedora installation (e.g. you're using it because it's
*Fedora*), or do people actually use it for traditional server use
cases.

For those using it for traditional server use cases, why?  What about
it do you find better than something like CentOS?

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

[Bug 1744419] Replace /etc/rc.d/init.d/httpd by systemctl

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|w3c-markup-validator-1.3-19 |w3c-markup-validator-1.3-19
   |.fc32   |.fc32
   ||w3c-markup-validator-1.3-20
   ||.fc33



--- Comment #10 from Fedora Update System  ---
FEDORA-2020-be46672d5f has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora TPM1.2 Support

2020-12-04 Thread Andrew Lutomirski

On Wed, Dec 2, 2020 at 12:08 PM Jerry Snitselaar 
wrote:

>
> We are looking to no longer support TPM1.2 in RHEL9. Than raised the
> question with regards to opencryptoki-tpmtok if it should be changed in
> Fedora as well, so I thought I'd see what everyone thinks about future
> TPM1.2 support in Fedora. I know at one point in the last year or so
> trousers almost dropped from Fedora due to being orphaned for quite a
> while. From what I could find the following packages have dependencies:
>
> ecryptfs-utils  - --disable-tspi
> openconnect - looks like it will only build support if trousers-devel is
>   there, and makes use of tpm2-tss as well.
> strongswan  - --enable-tss-tss2 instead of --enable-tss-trousers?
> tboot   - the trousers dependency was just in a policy tool that has
> now
>   been deprecated upstream.
> opencryptoki-tpmtok - --disable-tpmtok
>
> tpm-quote-tools, tpm-tools, and trousers are all tpm1.2 specific
> packages.
>
> Another thing is that in the kernel there currently is no way to build
> with just tpm1.2 or tpm2.0 support so the kernel support for tpm1.2
> would still be there.
>
> I don't think Fedora needs to drop the tpm1.2 support if people want to
> continue supporting it, but wanted to put the question out there and see
> how everyone felt.
>
>

How much support is needed?  I've written some TPM1.2 code that no one
uses, so I don't personally care, but I'm pretty sure there are quite a few
systems around that use TPM 1.2  For example, until I manually did the
magic incantation to switch my laptop from its TPM 1.2 default to TPM 2
mode, it had TPM 1.2.  It's not even particularly old.

I think we should at least keep TPM 1.2 kernel support, but basic user
support where it's not too inconvenient seems reasonable.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote:
> Also a couple of notes on modularity here:
> 
> # By default, module stream name is derived from the branch name
> If we have any "master" modules, those will get unexpectedly renamed
> as soon as they get rebuilt. This might impact tagging or updates and
> cause confusion in general. We should check if there are any like that
> and decide on further steps.

Good thing to check yes. I can try and do so. 

> # Modules might be pulling components from their master branches to
> build Rawhide artifacts
> There are various use cases for this, too long to list. If the master
> ref is no longer available, these will not build. Modulemd files that
> pull components from master need to be updated after Phase 2.

Yep. +1

> # The modulemd component ref is optional and defaults to master
> Unless this got changed later, if the ref field is omitted, the value
> defaults to "master". This is part of the specification and is handled
> by libmodulemd. Not sure how to proceed here.

Can we change the default? 

> And besides modularity:
> 
> There are people and teams who use bots to autobuild their upstream
> projects in Rawhide. If they have a bot account (and I hope they do),
> they should be notified to update their tooling.

We don't have much tracking on bot accounts. People make them and sign
up for fas for them, etc. 

We can try and find things that are obvious, but we are likely to miss
some. We can definitely help people who notice breakage 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

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

On Fri, Dec 04, 2020 at 12:45:03AM +0100, Miro Hrončok wrote:
> On 12/3/20 4:39 PM, Petr Šabata wrote:
> > On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves Chibon  
> > wrote:
> > > On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
> > > > Since I don't see those on the list, does this impact
> > > > 
> > > > * rpkg (fedpkg)?
> > > Wrapper to git, should not be impacted. The only thing I could think of 
> > > was:
> > > when we fedpkg clone an empty git repo, have fedpkg do the "git branch -M 
> > > main"
> > > directly. That being said, I'm not 100% sure when we creating a project on
> > > dist-git today we create them empty.
> 
> Optionally, they can be empty.
> 
>   $ fedpkg request-repo ... --no-initial-commit

This could be anoying if someone then pushes as master branch back up,
but I guess we can take those on a case by case basis. 

kevin


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

Re: summary of matrix/element chat discussion

On Fri, Dec 04, 2020 at 07:29:41PM +0100, Vitaly Zaitsev via devel wrote:
> On 04.12.2020 19:14, Matthew Miller wrote:
> > It doesn't seem possible that you mean literally copied from
> > https://chat.fedoraproject.org  tohttps://fedoraproject.org/; that's not the
> > way things work. Can you clarify the problem you're concerned about?
> 
> chat.fedoraproject.org is the hosted web version of the Element Matrix
> client. Users can use any other to login. This is completely optional.
> 
> fedoraproject.org is the main Matrix server with all user content.

Well, no. I would say 'matrix.fedoraproject.org' is the matrix server
run by element on our behaf? Or matrix.fedorapeople.org ?

> > Can you also clarify "can always be viewed"?
> 
> Matrix is similar to Git. When you join any room, all events and content
> will be copied to your homeserver.
> 
> For example #foobar:example.org contains pirated content. When you join it
> from your fedoraproject.org account, most of its contents will be copied to
> this server and can be viewed by direct hyperlinks (until the cache is
> purged).
> 
> The links will look like this:
> https://fedoraproject.org/_matrix/media/r0/download/example.org/kJsInSvRQWlSZIvpibVwMJki
> 
> > How would this help?
> 
> Most public services (GitHub, GitLab, etc.) use separate domains for the
> user content.
> 
> We need to discuss these potential legal issues with at least the Fedora
> Legal Team.

Yeah, we need to clarify some legal issues around it for sure. 

We could call it whatever makes the most sense, but I would expect this
to be user content with element handling issues like takedowns, etc.

kevin


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

Re: Rawhide Repo needs downgradeable packages

On Fri, Dec 04, 2020 at 04:11:05PM +0100, Marius Schwarz wrote:
> 
> Hi,
> 
> as you may have heared, Fedora is now running on Pinephone and other
> devices, that need bleeding edge versions to function.
> 
> Status of Fedora Pine as of 15:15 CET
> 
> Cams now working, but app needs rework
> Mobile INET working
> WIFI working
> Touch working
> SMS working
> GPS working
> Calls partly, "calls app" does not connect to pulseaudio.
> Headphones ( sort of )
> Mali400 GPU support working ( MPV rulez )

Do note that this is a Fedora remix right? Since it's using a non fedora
kernel + packages not in fedora. :) 

But we will get to a fedora spin someday. 

> 
> and with Gnome(38) instead of Phosh..  no window problems! Big Thanks to
> nikhiljha and his copr repo.
> 
> O== my request
> 
> In the last 3 days alone several updates ( i.e. bind-libs, gnome-shell
> 40~alpha ) caused a lot of bugs and needed to be downgraded directly from
> koji,
> by first finding & downloading them with wget ( because of the slow wifi and
> dependency checks, direct http links work ofcourse ), and later downgraded
> with
> dnf, which is so to speak, a pain in the ass. Of course, the best way to
> handle it would be, if the os compenents came from stable repos, so that
> these problems do not happen. But as i said, bleeding edge is needed atm.
> 
> Is it possible to keep at least the last version of a package around in
> rawhide repo, to make dnf downgrade work? That would ease a lot of this
> pain.

This has been a long time request. It's been shot down in the past due
to the massive size increase (keeping 2x as many packages), and the
issue of keeping around old packages that may have security issues. 

The last time this came up I think someone suggested perhaps that we
keep old updates only for like a week, then drop them. That would give
most people who update frequently a downgrade for a week, then (we hope)
the thing is pretty stable. 

Of course Adam is right that we probibly don't want to spend too much
time on this. I might file a pungi RFR on it tho.

> I know that there is a native koji tool to handle rawhide, but i must say,
> that won't work in most cases. Let me explain:
> 
> Pine has announced to open stores in the US and Canada, because of the huge
> amount of requests for a pinephone. As it looks, this phone, as cheap as it
> compontants are, fills a gap of some kind. Therefor we will have much more
> user using it, and (i hope i can help with it) will use Fedora with
> Gnome-Shell.
> Phosh is more like Android, it has it charm, but tbh I, and people I showned
> it to,  love they way gnome-shell handles stuff.
> 
> We "may" get them to downgrade stuff with dnf, but that needs to be as
> simple as it could.

Hopefully before too long we can get things working with 100% fedora and
then move to stable releases. 

kevin


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

Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

On Fri, Dec 04, 2020 at 07:53:12PM +0100, p...@uni-bremen.de wrote:
> I’m not a maintainer but I use Fedora Server for a lot of our university
> research institutions infrastructure (and I’m a dormant member of Fedora
> docs).
> 
> Just in case it is indeed considered useful and desirable I could
> contribute various Fedora Server related/specific documentations and
> how-to's, e.g. an annotated step-by-step guide to setup a basic server
> which can get extended for various purposes, how to set up a Postgres
> server on top of a basic server, an infrastructure for vm’s and containers
> (including scripts and ansible templates), troubleshooting guides, and
> other topics like that (mostly practical but always together with
> preliminary strategic considerations). Just let me know.


Absolutely! A functioning Working Group needs people interested in and doing
these kinds of things too, not just package maintenance. So if you're
interested, you'd absolutely be welcome in a re-constituted Fedora Server
WG.

-- 
Matthew Miller

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

Re: Fedora 34 Change proposal: Xwayland as a standalone package (System-Wide Change)

On Fri, Dec 04, 2020 at 01:18:35PM +0100, Fabio Valentini wrote:
> On Wed, Dec 2, 2020 at 11:34 AM Olivier Fourdan  wrote:
> > This is a twofold question, a possible xserver 1.21 version and a separate 
> > release of Xwayland upstream.
> >
> > Regarding a possible xserver 1.21 release, I guess that would be up to 
> > someone upstream to step up and coordinate such a release upstream (and 
> > that wouldn't even need to be a last, final release, as long as people are 
> > willing to work on it upstream).
> 
> I understand. I assume that it's not possible for just anybody to step
> up to do that? Not that I really want to volunteer, the X code base is
> scary :)

My understanding is to do another release is a lot of coordinating work
and getting testing results. ie, it's really fragile and has tons and
tons of weird niche users all or many of which need to test and confirm
everything is good for them. But thats just what I have read, I have no
direct connection 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

Re: Fedora TPM1.2 Support

2020-12-04 Thread Jerry Snitselaar


Jerry Snitselaar @ 2020-12-04 11:59 MST:

> Simo Sorce @ 2020-12-04 07:32 MST:
>
>> On Fri, 2020-12-04 at 14:08 +, Peter Robinson wrote:
>>> On Fri, Dec 4, 2020 at 2:04 PM Simo Sorce  wrote:
>>> > On Thu, 2020-12-03 at 21:25 +, Peter Robinson wrote:
>>> > > > We are looking to no longer support TPM1.2 in RHEL9. Than raised the
>>> > > > question with regards to opencryptoki-tpmtok if it should be changed 
>>> > > > in
>>> > > > Fedora as well, so I thought I'd see what everyone thinks about future
>>> > > > TPM1.2 support in Fedora. I know at one point in the last year or so
>>> > > > trousers almost dropped from Fedora due to being orphaned for quite a
>>> > > > while. From what I could find the following packages have 
>>> > > > dependencies:
>>> > > > 
>>> > > > ecryptfs-utils  - --disable-tspi
>>> > > > openconnect - looks like it will only build support if trousers-devel 
>>> > > > is
>>> > > >   there, and makes use of tpm2-tss as well.
>>> > > > strongswan  - --enable-tss-tss2 instead of --enable-tss-trousers?
>>> > > > tboot   - the trousers dependency was just in a policy tool that 
>>> > > > has now
>>> > > >   been deprecated upstream.
>>> > > > opencryptoki-tpmtok - --disable-tpmtok
>>> > > > 
>>> > > > tpm-quote-tools, tpm-tools, and trousers are all tpm1.2 specific
>>> > > > packages.
>>> > > > 
>>> > > > Another thing is that in the kernel there currently is no way to build
>>> > > > with just tpm1.2 or tpm2.0 support so the kernel support for tpm1.2
>>> > > > would still be there.
>>> > > > 
>>> > > > I don't think Fedora needs to drop the tpm1.2 support if people want 
>>> > > > to
>>> > > > continue supporting it, but wanted to put the question out there and 
>>> > > > see
>>> > > > how everyone felt.
>>> > > 
>>> > > I think it should be dropped, tpm2 has been shipped in hardware for 5+
>>> > > years and tpm1 has security issues, so I think the time is now to drop
>>> > > it. Please do a Fedora Change proposal to ensure it's communicated
>>> > > properly.
>>> > 
>>> > Won't that hurt people that have keys trapped in a TPM 1.2 device ?
>>> 
>>> Won't it hurt RHEL users in similar ways?
>>
>> It may, but that is RHEL, and this Fedora, no ?
>>
>>> What is the likelihood of
>>> those users actively upgrading anyway?
>>
>> Upgrades in RHEL are a much bigger deal, and usually better researched
>> (also rare, usually people reinstall there).
>>
>> In Fedora distro-upgrading w/o looking too hard at release notes is
>> common.
>>
>> Of course the amount of people that uses TPM 1.2 in Fedora is probably
>> very small, so this change may be ok, but I just wanted to raise the
>> issue.
>>
>> Is there a way, after update to still use TPM 1.2 at all (even if it
>> requires installing copr/other repo packages)? Or will people need to
>> roll back their system to access those secrets at all ?
>>
>> Simo.
>
> Yes, the kernel support in the driver would still be there. Currently
> the driver code can't be compiled for just tpm1.2 or tpm2.0. So it
> would be a matter of getting userspace tools to talk to it.

I think the plan will be in RHEL to tell people that if you need to use
TPM1.2 keep using RHEL8 since it will be supported for a number of years
still. TPM1.2 was already marked as deprecated in the RHEL8 Release Notes,
so hopefully it won't generate too much unhappiness.

I know Fedora is a different beast though, and sticking with an older
release isn't really an option for users.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

On Fri, Dec 04, 2020 at 06:11:40AM -0500, Pavel Valena wrote:
> - Original Message -
> > From: "Till Maas" 
> > To: "Development discussions related to Fedora" 
> > 
> > Sent: Friday, December 4, 2020 11:09:27 AM
> > Subject: Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained 
> > Change)
> > 
> > On Thu, Dec 03, 2020 at 08:52:13PM +0100, Pierre-Yves Chibon wrote:
> > 
> > > After looking at the infra and releng issue trackers Kevin managed to 
> > > found
> > > back
> > > the ticket I was thinking about.
> > > You have my apologies, the namespace that was asking to a different 
> > > default
> > > branch and for that branch to not be named "rawhide" was flatpaks.
> > > They wanted the default branch to be "stable", which would not apply to
> > > most
> > > other namespaces. Thus the proposal to go with "main" which works for all
> > > namespaces and seems to be on its way to become the industry standard.
> > 
> > The flatpak namespace considering "main" to be the stable branch but
> > rpms considering "main" to be the development branch, is IMHO an
> > argument why we flatpack should use "stable" and rpms "rawhide". This
> > will make it more clear for everyone what the branch is actually about.
> 
> I agree. "main" is still quite ambiguous - is it stable? is it devel?

It's the main branch where things take place. ;) 

> And "rawhide" would correspond with the repo... Is there any show-stopper 
> that I've missed?

I don't think you can make branches completely descripive by themselves,
unless possibly you make them really long. 

flatpak_branch_where_stable_flatpaks_are_made_from

rawhide_its_the_branch_for_the_development_version_of_fedora_called_rawhide

So, IMHO, we are overcomplicating it, and we should just use main. 

I suppose it's ok to make 'rawhide' a symref to main, or 'stable' in the
flatpak case... 

kevin


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

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

On Fri, Dec 04, 2020 at 10:01:04AM +, Daniel P. Berrangé wrote:
> On Thu, Dec 03, 2020 at 01:50:24PM -0500, Matthew Miller wrote:
> > On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
> > > Is there a reason why "main" is proposed instead of "rawhide" on src.fp.o?
> > > For all non-dist-git repositories I am fine with "main", but if we are
> > > changing this anyway, "rawhide" would actually make more sense for
> > > dist-git repos.
> > > This would make the branch name actually match the "releasever".
> > 
> > I'm definitely in favor of this. I still have dreams of having Fedora and
> > CentOS Stream branches sharing space in the repository, and having
> > everything explicity named with what branch it is rather than fighting over
> > who owns "main" would be nice.
> 
> Perhaps this is heresy, but we could stop calling our main development
> stream "rawhide", and instead call it "main", then it will be trivially
> aligned with the "main" git branch name :-)
> 
> I've never felt "rawhide" was a particularly good name. Unless you're
> already familiar with Fedora, it is something whose meaning in the context
> of Fedora has to be explained each time. The common meaning of the word
> rawhide doesn't have especially positive associations either IMHO.

Yeah, I am not a super fan of the name rawhide (Although I am a super
fan of the thing we make called rawhide). :) 

I always thought it could be something better like 'headwaters' or
something. But that gets us into a big long bikeshed. :( 

kevin


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

Re: Fedora TPM1.2 Support

On Fri, 2020-12-04 at 11:59 -0700, Jerry Snitselaar wrote:
> Simo Sorce @ 2020-12-04 07:32 MST:
> 
> > On Fri, 2020-12-04 at 14:08 +, Peter Robinson wrote:
> > > On Fri, Dec 4, 2020 at 2:04 PM Simo Sorce  wrote:
> > > > On Thu, 2020-12-03 at 21:25 +, Peter Robinson wrote:
> > > > > > We are looking to no longer support TPM1.2 in RHEL9. Than raised the
> > > > > > question with regards to opencryptoki-tpmtok if it should be 
> > > > > > changed in
> > > > > > Fedora as well, so I thought I'd see what everyone thinks about 
> > > > > > future
> > > > > > TPM1.2 support in Fedora. I know at one point in the last year or so
> > > > > > trousers almost dropped from Fedora due to being orphaned for quite 
> > > > > > a
> > > > > > while. From what I could find the following packages have 
> > > > > > dependencies:
> > > > > > 
> > > > > > ecryptfs-utils  - --disable-tspi
> > > > > > openconnect - looks like it will only build support if 
> > > > > > trousers-devel is
> > > > > >   there, and makes use of tpm2-tss as well.
> > > > > > strongswan  - --enable-tss-tss2 instead of --enable-tss-trousers?
> > > > > > tboot   - the trousers dependency was just in a policy tool 
> > > > > > that has now
> > > > > >   been deprecated upstream.
> > > > > > opencryptoki-tpmtok - --disable-tpmtok
> > > > > > 
> > > > > > tpm-quote-tools, tpm-tools, and trousers are all tpm1.2 specific
> > > > > > packages.
> > > > > > 
> > > > > > Another thing is that in the kernel there currently is no way to 
> > > > > > build
> > > > > > with just tpm1.2 or tpm2.0 support so the kernel support for tpm1.2
> > > > > > would still be there.
> > > > > > 
> > > > > > I don't think Fedora needs to drop the tpm1.2 support if people 
> > > > > > want to
> > > > > > continue supporting it, but wanted to put the question out there 
> > > > > > and see
> > > > > > how everyone felt.
> > > > > 
> > > > > I think it should be dropped, tpm2 has been shipped in hardware for 5+
> > > > > years and tpm1 has security issues, so I think the time is now to drop
> > > > > it. Please do a Fedora Change proposal to ensure it's communicated
> > > > > properly.
> > > > 
> > > > Won't that hurt people that have keys trapped in a TPM 1.2 device ?
> > > 
> > > Won't it hurt RHEL users in similar ways?
> > 
> > It may, but that is RHEL, and this Fedora, no ?
> > 
> > > What is the likelihood of
> > > those users actively upgrading anyway?
> > 
> > Upgrades in RHEL are a much bigger deal, and usually better researched
> > (also rare, usually people reinstall there).
> > 
> > In Fedora distro-upgrading w/o looking too hard at release notes is
> > common.
> > 
> > Of course the amount of people that uses TPM 1.2 in Fedora is probably
> > very small, so this change may be ok, but I just wanted to raise the
> > issue.
> > 
> > Is there a way, after update to still use TPM 1.2 at all (even if it
> > requires installing copr/other repo packages)? Or will people need to
> > roll back their system to access those secrets at all ?
> > 
> > Simo.
> 
> Yes, the kernel support in the driver would still be there. Currently
> the driver code can't be compiled for just tpm1.2 or tpm2.0. So it
> would be a matter of getting userspace tools to talk to it.

So a container with a previous fedora version+tools would be a way to
"deal" with it at least temporarily? (for example to decrypt data and
transition to TPM2.0 to re-encrypt it or similr...)

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

Re: Fedora TPM1.2 Support

2020-12-04 Thread Jerry Snitselaar


Simo Sorce @ 2020-12-04 07:32 MST:

> On Fri, 2020-12-04 at 14:08 +, Peter Robinson wrote:
>> On Fri, Dec 4, 2020 at 2:04 PM Simo Sorce  wrote:
>> > On Thu, 2020-12-03 at 21:25 +, Peter Robinson wrote:
>> > > > We are looking to no longer support TPM1.2 in RHEL9. Than raised the
>> > > > question with regards to opencryptoki-tpmtok if it should be changed in
>> > > > Fedora as well, so I thought I'd see what everyone thinks about future
>> > > > TPM1.2 support in Fedora. I know at one point in the last year or so
>> > > > trousers almost dropped from Fedora due to being orphaned for quite a
>> > > > while. From what I could find the following packages have dependencies:
>> > > > 
>> > > > ecryptfs-utils  - --disable-tspi
>> > > > openconnect - looks like it will only build support if trousers-devel 
>> > > > is
>> > > >   there, and makes use of tpm2-tss as well.
>> > > > strongswan  - --enable-tss-tss2 instead of --enable-tss-trousers?
>> > > > tboot   - the trousers dependency was just in a policy tool that 
>> > > > has now
>> > > >   been deprecated upstream.
>> > > > opencryptoki-tpmtok - --disable-tpmtok
>> > > > 
>> > > > tpm-quote-tools, tpm-tools, and trousers are all tpm1.2 specific
>> > > > packages.
>> > > > 
>> > > > Another thing is that in the kernel there currently is no way to build
>> > > > with just tpm1.2 or tpm2.0 support so the kernel support for tpm1.2
>> > > > would still be there.
>> > > > 
>> > > > I don't think Fedora needs to drop the tpm1.2 support if people want to
>> > > > continue supporting it, but wanted to put the question out there and 
>> > > > see
>> > > > how everyone felt.
>> > > 
>> > > I think it should be dropped, tpm2 has been shipped in hardware for 5+
>> > > years and tpm1 has security issues, so I think the time is now to drop
>> > > it. Please do a Fedora Change proposal to ensure it's communicated
>> > > properly.
>> > 
>> > Won't that hurt people that have keys trapped in a TPM 1.2 device ?
>> 
>> Won't it hurt RHEL users in similar ways?
>
> It may, but that is RHEL, and this Fedora, no ?
>
>> What is the likelihood of
>> those users actively upgrading anyway?
>
> Upgrades in RHEL are a much bigger deal, and usually better researched
> (also rare, usually people reinstall there).
>
> In Fedora distro-upgrading w/o looking too hard at release notes is
> common.
>
> Of course the amount of people that uses TPM 1.2 in Fedora is probably
> very small, so this change may be ok, but I just wanted to raise the
> issue.
>
> Is there a way, after update to still use TPM 1.2 at all (even if it
> requires installing copr/other repo packages)? Or will people need to
> roll back their system to access those secrets at all ?
>
> Simo.

Yes, the kernel support in the driver would still be there. Currently
the driver code can't be compiled for just tpm1.2 or tpm2.0. So it
would be a matter of getting userspace tools to talk to it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

2020-12-04 Thread pboy



> Am 04.12.2020 um 19:08 schrieb Matthew Miller :
> 
> It's not a matter of making changes for change's own sake, but I would hope
> that we'd have some level of innovation and experimentation in Fedora
> Server. There are also just normal things like marketing materials,
> promotion, blog posts, docs, etc., that can use ongoing work.
> 

I’m not a maintainer but I use Fedora Server for a lot of our university 
research institutions infrastructure (and I’m a dormant member of Fedora docs).

Just in case it is indeed considered useful and desirable I could contribute 
various Fedora Server related/specific documentations and how-to's, e.g. an 
annotated step-by-step guide to setup a basic server which can get extended for 
various purposes, how to set up a Postgres server on top of a basic server, an 
infrastructure for vm’s and containers  (including scripts and ansible 
templates), troubleshooting guides, and other topics like that (mostly 
practical but always together with preliminary strategic considerations). Just 
let me know.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: summary of matrix/element chat discussion

2020-12-04 Thread Vitaly Zaitsev via devel


On 04.12.2020 19:14, Matthew Miller wrote:

It doesn't seem possible that you mean literally copied from
https://chat.fedoraproject.org  tohttps://fedoraproject.org/; that's not the
way things work. Can you clarify the problem you're concerned about?


chat.fedoraproject.org is the hosted web version of the Element Matrix 
client. Users can use any other to login. This is completely optional.


fedoraproject.org is the main Matrix server with all user content.


Can you also clarify "can always be viewed"?


Matrix is similar to Git. When you join any room, all events and content 
will be copied to your homeserver.


For example #foobar:example.org contains pirated content. When you join 
it from your fedoraproject.org account, most of its contents will be 
copied to this server and can be viewed by direct hyperlinks (until the 
cache is purged).


The links will look like this:
https://fedoraproject.org/_matrix/media/r0/download/example.org/kJsInSvRQWlSZIvpibVwMJki


How would this help?


Most public services (GitHub, GitLab, etc.) use separate domains for the 
user content.


We need to discuss these potential legal issues with at least the Fedora 
Legal Team.


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

Re: summary of matrix/element chat discussion

On Fri, Dec 04, 2020 at 07:07:56PM +0100, Vitaly Zaitsev via devel wrote:
> >We’ll have own hosted server athttps://chat.fedoraproject.org/
> Hosting the Matrix server on the main domain would be very
> dangerous, because someone can join a room with pornographic or
> pirated content, and this content will be copied to the
> fedoraproject.org server and can always be viewed via direct links.

It doesn't seem possible that you mean literally copied from
https://chat.fedoraproject.org to https://fedoraproject.org/; that's not the
way things work. Can you clarify the problem you're concerned about?

Can you also clarify "can always be viewed"?

> I suggest using fedorahosted.org or fedorainfracloud.org for example.

How would this help?

-- 
Matthew Miller

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

Re: summary of matrix/element chat discussion

2020-12-04 Thread Vitaly Zaitsev via devel


On 04.12.2020 18:18, Matthew Miller wrote:

Log in will be through FAS, and we’ll also federate the server so you can
come in with a different identity.


Only nheko and Element support SSO, btw.

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

Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

On Fri, Dec 04, 2020 at 11:59:17AM -0500, Neal Gompa wrote:
> > No one is talking about making it go away, just de-editioning it. I'd
> > definitely prefer it to remain an edition, but we need it to be more active
> > for that to work.
> Having an active team is one thing, but making changes just because is
> quite another. I don't feel it's worth demoting Fedora Server (just
> like I didn't like what happened to Fedora Cloud way back when with
> Atomic). But if you need me to be there to keep the WG going so it
> doesn't get demoted, I'm happy to help shepherd it.

It's not a matter of making changes for change's own sake, but I would hope
that we'd have some level of innovation and experimentation in Fedora
Server. There are also just normal things like marketing materials,
promotion, blog posts, docs, etc., that can use ongoing work.

-- 
Matthew Miller

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

Re: summary of matrix/element chat discussion

2020-12-04 Thread Vitaly Zaitsev via devel


On 04.12.2020 18:18, Matthew Miller wrote:

We’ll have own hosted server athttps://chat.fedoraproject.org/


Hosting the Matrix server on the main domain would be very dangerous, 
because someone can join a room with pornographic or pirated content, 
and this content will be copied to the fedoraproject.org server and can 
always be viewed via direct links.


I suggest using fedorahosted.org or fedorainfracloud.org for example.

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

Re: summary of matrix/element chat discussion

On Fri, Dec 04, 2020 at 01:02:49PM -0500, Robbie Harwood wrote:
> I don't think that's right.  I'm a happy weechat user, but as far as I'm
> aware, it only supports IRC natively.  There exists a matrix script (
> https://github.com/poljar/weechat-matrix , linked from
> https://matrix.org/docs/projects/client/weechat-matrix ) - matrix marks
> it as "beta", and the github repo marks it as "maintenance mode" while
> they work on a Rust plugin ( https://github.com/poljar/weechat-matrix-rs
> ) which is "a work in progress and doesn't do much yet".

I got my information on this from an offhand comment by one of the Element
folks. I did mean a plugin speaking the protocol natively rather than
bridged, not native support in the core, to be clear. But maybe they were
over-stating the current state of that plugin.

(I'm a happy weechat user too, fwiw.)


-- 
Matthew Miller

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

Re: summary of matrix/element chat discussion

2020-12-04 Thread Robbie Harwood

Matthew Miller  writes:

> * On a slightly more controversial note: we know that the bridge can be
>   somewhat annoying when Matrix decides it wants to send a URL rather than a
>   long message, and that things like reactions just don’t get bridged. Our
>   plan here, assuming the trial is successful, is to try and minimize these
>   inconveniences but ultimately steer people to using Matrix natively. Many
>   popular messaging clients (including weechat, for old-school folks)
>   support Matrix directly now.

I don't think that's right.  I'm a happy weechat user, but as far as I'm
aware, it only supports IRC natively.  There exists a matrix script (
https://github.com/poljar/weechat-matrix , linked from
https://matrix.org/docs/projects/client/weechat-matrix ) - matrix marks
it as "beta", and the github repo marks it as "maintenance mode" while
they work on a Rust plugin ( https://github.com/poljar/weechat-matrix-rs
) which is "a work in progress and doesn't do much yet".

Thanks,
--Robbie

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

Re: Mass spec file change: Adding BuildRequires: make


On 12/4/20 5:51 PM, Tom Stellard wrote:

On 12/4/20 4:55 AM, Miro Hrončok wrote:

On 12/3/20 6:27 PM, Tom Stellard wrote:
However, in the discussion on the mailing list for this change, not everyone 
agreed that cmake should Require make and this point was never resolved.  So, 
since there is still ambiguity here, I am planning to do the safest option, 
which is to add BuildRequires: make even for packages 
that use %cmake_build and do not invoke make directly.


For what's it worth I think that packages that only use make via cmake should 
not have an explcit dependency on make. Packages that use make directly should 
have an explicit dependency on make (even if they already BR cmake).




OK, so is it safe to assume then that the cmake package will always Require 
either make or ninja?


No. But it's safe to assume it will always require either make or ninja as long 
as it invokes make or ninja.



Packages only running "cmake" -> assume all cmake deps are present and don't 
think whether it is make or not.


Packages running "cmake" and "make" -> declare make as BR and don't assume it 
will be required by cmake forever.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

2020-12-04 Thread Eduard Lucena

I'm not part of the server WG, but a super interested user. Count me in to
help if needed.

Br,

El vie, 4 dic 2020 a las 14:00, Neal Gompa () escribió:

> On Fri, Dec 4, 2020 at 11:49 AM Matthew Miller 
> wrote:
> >
> > On Fri, Dec 04, 2020 at 10:03:24AM +0100, Fabio Valentini wrote:
> > > I agree, sign me up! I've been using Fedora Server for years for my
> > > own projects and it's been 99.9% flawless, so I would be sad if it
> > > went away.
> >
> > No one is talking about making it go away, just de-editioning it. I'd
> > definitely prefer it to remain an edition, but we need it to be more
> active
> > for that to work.
> >
>
> Having an active team is one thing, but making changes just because is
> quite another. I don't feel it's worth demoting Fedora Server (just
> like I didn't like what happened to Fedora Cloud way back when with
> Atomic). But if you need me to be there to keep the WG going so it
> doesn't get demoted, I'm happy to help shepherd it.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
Eduard Lucena
Móvil: +56962318010
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

summary of matrix/element chat discussion

As promised, a summary of our video call for those who couldn't attend:

Highlights

* Red Hat’s Open Source Program Office is interested in this experiment and
will fund hosted Element out of non-Fedora budget. That makes going ahead
with a practical trial basically a no-brainer.

* We’ll have own hosted server at https://chat.fedoraproject.org/, and
Element will provide a 1-day admin SLA at the level we’re getting. So, it
won’t require ongoing CPE or volunteer resources at the sysadmin level.
We’ll still need moderators and active admins of course.

* Log in will be through FAS, and we’ll also federate the server so you can
come in with a different identity.

* Mozilla has seen a 4× increase in engagement since switching from IRC to
Matrix (also hosted by Element). Also successful for KDE and SUSE. In
progress at GNOME. :)

* IRC isn’t going anywhere. Many people still like it, and Freenode is still
an important hub for free and open source software development. So, we
will provide bridges.

* These bridges will be set up in a way that avoids some of the problems the
GNOME project shared with their deployment.

* I had a concern that Zodbot would need to be ported immediately because of
problems I’d heard about logged meetings, but we’re assured that those
might be non-issues or at least easily fixed, which is nice for a
soft-launch / experiment with no big infrastructure changes right off.

* On a slightly more controversial note: we know that the bridge can be
somewhat annoying when Matrix decides it wants to send a URL rather than a
long message, and that things like reactions just don’t get bridged. Our
plan here, assuming the trial is successful, is to try and minimize these
inconveniences but ultimately steer people to using Matrix natively. Many
popular messaging clients (including weechat, for old-school folks)
support Matrix directly now.

* When will this start? Basically as soon as the money is worked out.

Full notes at:

https://discussion.fedoraproject.org/t/the-future-of-real-time-chat-discussion-for-the-fedora-council/24628/27?u=mattdm
--
Matthew Miller

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

[EPEL-devel] Re: openblas updates

2020-12-04 Thread Troy Dawson

On Fri, Dec 4, 2020 at 8:08 AM Antonio T. sagitter
 wrote:
>
> Hi all.
>
> Why openblas-0.3.5 is waiting for stable branch since 2 years? [1]
>
> Is it reasonable, taking into account the rebuilds of dependent
> packages, to rebuild openblas on epel7 by using a more recent GCC
> version like GCC-8 or GCC-9 ?
>
>
> [1] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-abb5b76382
> --

This is a very good question.
I thought I had already gone through all the old open bodhi issues.
But it looks like my search wasn't good enough.
If I do a
  bodhi updates query --status testing --submitted-before 2019
There are 152 EPEL7 and EPEL8 packages. :(
Actually, now that I look at it ... I did that cleanup about a year
and a half ago and it looks like things have grown since then.

Sorry, I'm not helping with openblas.  That is up to the maintainer.
It looks like it will install.
My opinion is to move it to stable, and if you want a rebuild, rebuild
it and have a seperate update.

I'll probably do another round of cleanup, but that will be a
different email, different subject.
Troy
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Rawhide Repo needs downgradeable packages


Am 04.12.20 um 17:34 schrieb Adam Williamson:

I don't think there's an easy way to do this, because of how we build
stuff. The Rawhide and Branched trees are rsynced over top of the
previous content from the most recent successful compose, with metadata
pre-built at the compose level. The old thing is thrown away and
replaced with the new thing, which is a very simple process.



keeping the old packages locally as Vít Ondruch suggested, will fix this 
problem.


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

Re: Rawhide Repo needs downgradeable packages


Am 04.12.20 um 16:37 schrieb Vít Ondruch:
As a workaround, if you use `keepcache=True` in dnf.conf, you'd have 
copies of everything you previously installed on your system.

Thats even better :) thx, didn't know this.

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

Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

On Fri, Dec 4, 2020 at 11:49 AM Matthew Miller  wrote:
>
> On Fri, Dec 04, 2020 at 10:03:24AM +0100, Fabio Valentini wrote:
> > I agree, sign me up! I've been using Fedora Server for years for my
> > own projects and it's been 99.9% flawless, so I would be sad if it
> > went away.
>
> No one is talking about making it go away, just de-editioning it. I'd
> definitely prefer it to remain an edition, but we need it to be more active
> for that to work.
>

Having an active team is one thing, but making changes just because is
quite another. I don't feel it's worth demoting Fedora Server (just
like I didn't like what happened to Fedora Cloud way back when with
Atomic). But if you need me to be there to keep the WG going so it
doesn't get demoted, I'm happy to help shepherd it.



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

[EPEL-devel] Re: %generate_buildrequires

2020-12-04 Thread Andrew C Aitchison


On Fri, 4 Dec 2020, Miro Hrončok wrote:


On 12/3/20 10:06 PM, Andrew C Aitchison wrote:

Is %generate_buildrequires suppose to work for packages
which do not used python ?


Yes, see https://fedoraproject.org/wiki/Changes/DynamicBuildRequires


Thanks. Now that I read that, this looks like a good plean.


(I am also confused/suspicious of the point of a macro to automate
  build requires, except as a step on a path to somewhere else.
  If build requirements need to be stated explicitly,
  then automating their statement is a good way of hiding an issue
  that needs to be reviewed whenever changes are made.
)


Indeed, things are less explicit when reading the spec file.
OTOH When upstream requirements change, one does not need to update them 
manually.


Certainly a very good step in this direction.
Is there anything to save an upstream devel from having to know that, say,
what Ubuntu calls "libX11-dev", CentOS calls libX11-devel ?


No more obsolete buildrequires (they tend to happen, really).

Yes; I have seen that.

Thanks for the pointer to
  https://fedoraproject.org/wiki/Changes/DynamicBuildRequires

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Mass spec file change: Adding BuildRequires: make

2020-12-04 Thread Tom Stellard


On 12/4/20 4:55 AM, Miro Hrončok wrote:

On 12/3/20 6:27 PM, Tom Stellard wrote:
However, in the discussion on the mailing list for this change, not 
everyone agreed that cmake should Require make and this point was 
never resolved.  So, since there is still ambiguity here, I am 
planning to do the safest option, which is to add BuildRequires: make 
even for packages that use %cmake_build and do not invoke make directly.


For what's it worth I think that packages that only use make via cmake 
should not have an explcit dependency on make. Packages that use make 
directly should have an explicit dependency on make (even if they 
already BR cmake).




OK, so is it safe to assume then that the cmake package will always 
Require either make or ninja?


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

Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

On Fri, Dec 04, 2020 at 10:03:24AM +0100, Fabio Valentini wrote:
> I agree, sign me up! I've been using Fedora Server for years for my
> own projects and it's been 99.9% flawless, so I would be sad if it
> went away.

No one is talking about making it go away, just de-editioning it. I'd
definitely prefer it to remain an edition, but we need it to be more active
for that to work.

-- 
Matthew Miller

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

Fedora-IoT-34-20201204.0 compose check report

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Failed openQA tests: 6/15 (aarch64), 3/16 (x86_64)

New failures (same test not failed in Fedora-IoT-34-20201203.0):

ID: 735852  Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/735852

Old failures (same test failed in Fedora-IoT-34-20201203.0):

ID: 735835  Test: x86_64 IoT-dvd_ostree-iso podman
URL: https://openqa.fedoraproject.org/tests/735835
ID: 735836  Test: x86_64 IoT-dvd_ostree-iso podman_client
URL: https://openqa.fedoraproject.org/tests/735836
ID: 735837  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/735837
ID: 735844  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/735844
ID: 735849  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/735849
ID: 735850  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/735850
ID: 735851  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/735851
ID: 735854  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/735854

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

New soft failures (same test not soft failed in Fedora-IoT-34-20201203.0):

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

Passed openQA tests: 9/15 (aarch64), 12/16 (x86_64)

New passes (same test not passed in Fedora-IoT-34-20201203.0):

ID: 735857  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/735857
ID: 735858  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/735858
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Rawhide Repo needs downgradeable packages

2020-12-04 Thread Adam Williamson

On Fri, 2020-12-04 at 16:11 +0100, Marius Schwarz wrote:
> Hi,
> 
> as you may have heared, Fedora is now running on Pinephone and other 
> devices, that need bleeding edge versions to function.
> 
> Status of Fedora Pine as of 15:15 CET
> 
> Cams now working, but app needs rework
> Mobile INET working
> WIFI working
> Touch working
> SMS working
> GPS working
> Calls partly, "calls app" does not connect to pulseaudio.
> Headphones ( sort of )
> Mali400 GPU support working ( MPV rulez )
> 
> and with Gnome(38) instead of Phosh..  no window problems! Big Thanks to 
> nikhiljha and his copr repo.
> 
> O== my request
> 
> In the last 3 days alone several updates ( i.e. bind-libs, gnome-shell 
> 40~alpha ) caused a lot of bugs and needed to be downgraded directly 
> from koji,
> by first finding & downloading them with wget ( because of the slow wifi 
> and dependency checks, direct http links work ofcourse ), and later 
> downgraded with
> dnf, which is so to speak, a pain in the ass. Of course, the best way to 
> handle it would be, if the os compenents came from stable repos, so that 
> these problems do not happen. But as i said, bleeding edge is needed atm.
> 
> Is it possible to keep at least the last version of a package around in 
> rawhide repo, to make dnf downgrade work? That would ease a lot of this 
> pain.
> 
> I know that there is a native koji tool to handle rawhide, but i must 
> say, that won't work in most cases. Let me explain:
> 
> Pine has announced to open stores in the US and Canada, because of the 
> huge amount of requests for a pinephone. As it looks, this phone, as 
> cheap as it compontants are, fills a gap of some kind. Therefor we will 
> have much more user using it, and (i hope i can help with it) will use 
> Fedora with Gnome-Shell.
> Phosh is more like Android, it has it charm, but tbh I, and people I 
> showned it to,  love they way gnome-shell handles stuff.
> 
> We "may" get them to downgrade stuff with dnf, but that needs to be as 
> simple as it could.

I don't think there's an easy way to do this, because of how we build
stuff. The Rawhide and Branched trees are rsynced over top of the
previous content from the most recent successful compose, with metadata
pre-built at the compose level. The old thing is thrown away and
replaced with the new thing, which is a very simple process.

If you want to keep old stuff around it suddenly gets a ton more
complex, because now you have to keep track of what is "old stuff" and
when to get rid of it, and you have to add a step to the process that
(re-)generates the repo metadata after the new stuff has been added to
the old stuff.

Limited downgrading possibilities exist for stable releases because we
freeze those and add updates repos alongside the frozen stable release,
but that's not how we build development releases.

I don't really think it makes sense to do a ton of engineering to
support an explicitly non-recommended use case. Rawhide is not for
running on your phone.

Having said that, there are more efficient ways to do what you're
doing. You don't need to download with wget; you can use the 'koji' CLI
tool directly (koji download-build --arch=XX --arch=noarch NVR). You
can also find the older Rawhide content in older composes, at
https://kojipkgs.fedoraproject.org/compose/rawhide/ - you can configure
the Everything repo from any of those as a local repo and its content
will be available for downgrading. Of course, that server doesn't
expect heavy traffic, so if lots of pinephone people start trying to do
it at once, it might start choking.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


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

Re: Mass spec file change: Adding BuildRequires: make

2020-12-04 Thread Ian McInerney

On Fri, Dec 4, 2020 at 4:21 PM Gary Buhrmaster 
wrote:

> On Fri, Dec 4, 2020 at 12:55 PM Miro Hrončok  wrote:
>
> > For what's it worth I think that packages that only use make via cmake
> should
> > not have an explcit dependency on make. Packages that use make directly
> should
> > have an explicit dependency on make (even if they already BR cmake).
>
> Does that mean that if the requires: make that is currently
> in the cmake package that was added due to rhbz#1862014
> is removed (as has been proposed since ninja is a valid
> alternative) that you are fine with packagers having to go
> fix their packages?  Or would you expect another pass
> across all packages to add a BR: make to be done?  If
> the later, it makes sense to me to do it once (when
> someone is willing to do the work) to prepare for any
> cmake cleanup(s).
>

I think the CMake package should always provide at least one build system
as a dependency, otherwise someone could install cmake and not be able to
fully use it. This is a case where we can be "opinionated" in the CMake
package and set a default build system for cmake in the package since it is
trivial for the user to change the generator at runtime with the -G option.

Then any consumers of the %cmake_* macros should rely on the choice of the
CMake package for the system unless they want to override it themselves.

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

Re: Mass spec file change: Adding BuildRequires: make

2020-12-04 Thread Dominik 'Rathann' Mierzejewski

On Friday, 04 December 2020 at 17:20, Gary Buhrmaster wrote:
> On Fri, Dec 4, 2020 at 12:55 PM Miro Hrončok  wrote:
> 
> > For what's it worth I think that packages that only use make via cmake 
> > should
> > not have an explcit dependency on make. Packages that use make directly 
> > should
> > have an explicit dependency on make (even if they already BR cmake).
> 
> Does that mean that if the requires: make that is currently
> in the cmake package that was added due to rhbz#1862014
> is removed (as has been proposed since ninja is a valid
> alternative) that you are fine with packagers having to go
> fix their packages?  Or would you expect another pass
> across all packages to add a BR: make to be done?  If
> the later, it makes sense to me to do it once (when
> someone is willing to do the work) to prepare for any
> cmake cleanup(s).

Wouldn't this work for cmake?

Requires: (make or ninja)
Suggests: make

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Mass spec file change: Adding BuildRequires: make

2020-12-04 Thread Richard Shaw

On Thu, Dec 3, 2020 at 10:22 AM Gary Buhrmaster 
wrote:

> On Thu, Dec 3, 2020 at 3:39 PM Fabio Valentini 
> wrote:
>
> > I still think a lot of those are "false positives".
> > CMake has a hard Requires on make, so if I BuildRequires cmake, adding
> > "BuildRequires: make" is just redundant.
> > https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185
>
> I think this was discussed previously, but
> while cmake may have a requires on make
> today, cmake can now use ninja rather
> than make in at least some cases, so one
> should certainly not presume cmake will
> always require make.  If the build requires
> make, it should call it out explicitly.
>

I think here is a RARE instance we disagree :)

Presumably everyone is using the %cmake / %cmake_build / %cmake_install
macros. If so and the current default for cmake is to use make, and cmake
has a hard dep on make, then why add the extra BR?

If the *default* is changed to ninja at some point I would expect for cmake
to have a hard dep on ninja.

If you're not using the macros or overriding the default then you're
already on your own and should BR make or ninja (or whatever) anyway.

Thanks,
Richard

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

Re: Mass spec file change: Adding BuildRequires: make

2020-12-04 Thread Gary Buhrmaster

On Fri, Dec 4, 2020 at 12:55 PM Miro Hrončok  wrote:

> For what's it worth I think that packages that only use make via cmake should
> not have an explcit dependency on make. Packages that use make directly should
> have an explicit dependency on make (even if they already BR cmake).

Does that mean that if the requires: make that is currently
in the cmake package that was added due to rhbz#1862014
is removed (as has been proposed since ninja is a valid
alternative) that you are fine with packagers having to go
fix their packages?  Or would you expect another pass
across all packages to add a BR: make to be done?  If
the later, it makes sense to me to do it once (when
someone is willing to do the work) to prepare for any
cmake cleanup(s).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

2020-12-04 Thread Miroslav Suchý

Dne 04. 12. 20 v 15:25 Kevin Kofler via devel napsal(a):
> +1 for "rawhide" as the branch name.
> 
> I have always seen the inconsistency between "rawhide" and "master" as a 
> result of "master" being a default name in git. If we are going to change it 
> anyway, we should change it to the real name ("rawhide"), and not to a third 
> (!) name for the same thing ("main").

+1

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] openblas updates

2020-12-04 Thread Antonio T. sagitter


Hi all.

Why openblas-0.3.5 is waiting for stable branch since 2 years? [1]

Is it reasonable, taking into account the rebuilds of dependent 
packages, to rebuild openblas on epel7 by using a more recent GCC 
version like GCC-8 or GCC-9 ?



[1] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-abb5b76382
--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Rawhide Repo needs downgradeable packages

2020-12-04 Thread Vít Ondruch


I definitely support this.

As a workaround, if you use `keepcache=True` in dnf.conf, you'd have 
copies of everything you previously installed on your system.


Now if there was some dnf plugin, which would make repository from the 
cache, that would be super helpful. I have never found time to 
materialize this :/



Vít


Dne 04. 12. 20 v 16:11 Marius Schwarz napsal(a):


Hi,

as you may have heared, Fedora is now running on Pinephone and other 
devices, that need bleeding edge versions to function.


Status of Fedora Pine as of 15:15 CET

Cams now working, but app needs rework
Mobile INET working
WIFI working
Touch working
SMS working
GPS working
Calls partly, "calls app" does not connect to pulseaudio.
Headphones ( sort of )
Mali400 GPU support working ( MPV rulez )

and with Gnome(38) instead of Phosh..  no window problems! Big Thanks 
to nikhiljha and his copr repo.


O== my request

In the last 3 days alone several updates ( i.e. bind-libs, gnome-shell 
40~alpha ) caused a lot of bugs and needed to be downgraded directly 
from koji,
by first finding & downloading them with wget ( because of the slow 
wifi and dependency checks, direct http links work ofcourse ), and 
later downgraded with
dnf, which is so to speak, a pain in the ass. Of course, the best way 
to handle it would be, if the os compenents came from stable repos, so 
that these problems do not happen. But as i said, bleeding edge is 
needed atm.


Is it possible to keep at least the last version of a package around 
in rawhide repo, to make dnf downgrade work? That would ease a lot of 
this pain.


I know that there is a native koji tool to handle rawhide, but i must 
say, that won't work in most cases. Let me explain:


Pine has announced to open stores in the US and Canada, because of the 
huge amount of requests for a pinephone. As it looks, this phone, as 
cheap as it compontants are, fills a gap of some kind. Therefor we 
will have much more user using it, and (i hope i can help with it) 
will use Fedora with Gnome-Shell.
Phosh is more like Android, it has it charm, but tbh I, and people I 
showned it to,  love they way gnome-shell handles stuff.


We "may" get them to downgrade stuff with dnf, but that needs to be as 
simple as it could.


best regards,
Marius Schwarz



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


OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys


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

Re: updating nbconvert

2020-12-04 Thread Victor Stinner

Hi José,

On Fri, Dec 4, 2020 at 1:17 PM José Abílio Matos  wrote:
> Probably the build was erased, another place where it can be found is:
> https://copr-be.cloud.fedoraproject.org/results/nonamedotc/nbconvert-6.0.7/fedora-rawhide-x86_64/01795144-python-nbconvert/

I cannot find "xelatex" nor "OSError" pattern in build.log.gz. The RPM
was built successfully, but there are some warnings.

=== warnings summary ===
nbconvert/exporters/tests/test_latex.py::TestLatexExporter::test_prompt_number_color_ipython
  /usr/lib/python3.9/site-packages/jinja2/lexer.py:646:
DeprecationWarning: invalid escape sequence '\c'
self._normalize_newlines(value[1:-1])
nbconvert/exporters/tests/test_templateexporter.py::TestExporter::test_exclude_markdown
  /usr/lib/python3.9/site-packages/IPython/core/inputsplitter.py:21:
DeprecationWarning: IPython.core.inputsplitter is deprecated since
IPython 7 in favor of `IPython.core.inputtransformer2`
warn('IPython.core.inputsplitter is deprecated since IPython 7 in
favor of `IPython.core.inputtransformer2`',
nbconvert/filters/tests/test_datatypefilter.py::TestDataTypeFilter::test_junk_types
  /builddir/build/BUILD/nbconvert-6.0.7/nbconvert/filters/datatypefilter.py:39:
UserWarning: Your element with mimetype(s) dict_keys(['hair', 'water',
'rock']) is not able to be represented.
warn("Your element with mimetype(s) {mimetypes}"
nbconvert/filters/tests/test_datatypefilter.py::TestDataTypeFilter::test_null
  /builddir/build/BUILD/nbconvert-6.0.7/nbconvert/filters/datatypefilter.py:39:
UserWarning: Your element with mimetype(s) dict_keys([]) is not able
to be represented.
warn("Your element with mimetype(s) {mimetypes}"
nbconvert/preprocessors/tests/test_sanitize.py: 18 warnings
  /usr/lib/python3.9/site-packages/html5lib/filters/sanitizer.py:771:
DeprecationWarning: html5lib's sanitizer is deprecated; see
https://github.com/html5lib/html5lib-python/issues/443 and please let
us know if Bleach is unsuitable for your needs
warnings.warn(_deprecation_msg, DeprecationWarning)
-- Docs: https://docs.pytest.org/en/stable/warnings.html
=== 231 passed, 54 deselected, 22 warnings in 53.03s ===

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

Fedora-IoT-33-20201204.0 compose check report

No missing expected images.

Failed openQA tests: 1/15 (aarch64)

Old failures (same test failed in Fedora-IoT-33-20201203.0):

ID: 735790  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/735790

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

Old soft failures (same test soft failed in Fedora-IoT-33-20201203.0):

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

Passed openQA tests: 15/16 (x86_64), 14/15 (aarch64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.17 to 0.06
Previous test data: https://openqa.fedoraproject.org/tests/735016#downloads
Current test data: https://openqa.fedoraproject.org/tests/735776#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Rawhide Repo needs downgradeable packages



Hi,

as you may have heared, Fedora is now running on Pinephone and other 
devices, that need bleeding edge versions to function.


Status of Fedora Pine as of 15:15 CET

Cams now working, but app needs rework
Mobile INET working
WIFI working
Touch working
SMS working
GPS working
Calls partly, "calls app" does not connect to pulseaudio.
Headphones ( sort of )
Mali400 GPU support working ( MPV rulez )

and with Gnome(38) instead of Phosh..  no window problems! Big Thanks to 
nikhiljha and his copr repo.


O== my request

In the last 3 days alone several updates ( i.e. bind-libs, gnome-shell 
40~alpha ) caused a lot of bugs and needed to be downgraded directly 
from koji,
by first finding & downloading them with wget ( because of the slow wifi 
and dependency checks, direct http links work ofcourse ), and later 
downgraded with
dnf, which is so to speak, a pain in the ass. Of course, the best way to 
handle it would be, if the os compenents came from stable repos, so that 
these problems do not happen. But as i said, bleeding edge is needed atm.


Is it possible to keep at least the last version of a package around in 
rawhide repo, to make dnf downgrade work? That would ease a lot of this 
pain.


I know that there is a native koji tool to handle rawhide, but i must 
say, that won't work in most cases. Let me explain:


Pine has announced to open stores in the US and Canada, because of the 
huge amount of requests for a pinephone. As it looks, this phone, as 
cheap as it compontants are, fills a gap of some kind. Therefor we will 
have much more user using it, and (i hope i can help with it) will use 
Fedora with Gnome-Shell.
Phosh is more like Android, it has it charm, but tbh I, and people I 
showned it to,  love they way gnome-shell handles stuff.


We "may" get them to downgrade stuff with dnf, but that needs to be as 
simple as it could.


best regards,
Marius Schwarz


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

Fedora 33 election results

2020-12-04 Thread Ben Cotton

Greetings, all!

The Fedora 33 elections have completed.

## Fedora Council

Tom Callaway is elected to the Fedora Council.

## Fedora Engineering Steering Committee (FESCo)

The following candidates are elected to FESCo:

* Miro Hrončok
* Kevin Fenzi
* Zbigniew Jędrzejewski-Szmek
* Fabio Valentini
* David Cantrell

## Fedora Mindshare Committee

Till Maas is elected to the Fedora Mindshare Committee.

For more details, visit the Community Blog post:
https://communityblog.fedoraproject.org/fedora-33-elections-results/

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 33 election results

2020-12-04 Thread Ben Cotton

Greetings, all!

The Fedora 33 elections have completed.

## Fedora Council

Tom Callaway is elected to the Fedora Council.

## Fedora Engineering Steering Committee (FESCo)

The following candidates are elected to FESCo:

* Miro Hrončok
* Kevin Fenzi
* Zbigniew Jędrzejewski-Szmek
* Fabio Valentini
* David Cantrell

## Fedora Mindshare Committee

Till Maas is elected to the Fedora Mindshare Committee.

For more details, visit the Community Blog post:
https://communityblog.fedoraproject.org/fedora-33-elections-results/

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
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

Re: Fedora TPM1.2 Support

2020-12-04 Thread Peter Robinson

On Fri, Dec 4, 2020 at 2:32 PM Simo Sorce  wrote:
>
> On Fri, 2020-12-04 at 14:08 +, Peter Robinson wrote:
> > On Fri, Dec 4, 2020 at 2:04 PM Simo Sorce  wrote:
> > > On Thu, 2020-12-03 at 21:25 +, Peter Robinson wrote:
> > > > > We are looking to no longer support TPM1.2 in RHEL9. Than raised the
> > > > > question with regards to opencryptoki-tpmtok if it should be changed 
> > > > > in
> > > > > Fedora as well, so I thought I'd see what everyone thinks about future
> > > > > TPM1.2 support in Fedora. I know at one point in the last year or so
> > > > > trousers almost dropped from Fedora due to being orphaned for quite a
> > > > > while. From what I could find the following packages have 
> > > > > dependencies:
> > > > >
> > > > > ecryptfs-utils  - --disable-tspi
> > > > > openconnect - looks like it will only build support if trousers-devel 
> > > > > is
> > > > >   there, and makes use of tpm2-tss as well.
> > > > > strongswan  - --enable-tss-tss2 instead of --enable-tss-trousers?
> > > > > tboot   - the trousers dependency was just in a policy tool that 
> > > > > has now
> > > > >   been deprecated upstream.
> > > > > opencryptoki-tpmtok - --disable-tpmtok
> > > > >
> > > > > tpm-quote-tools, tpm-tools, and trousers are all tpm1.2 specific
> > > > > packages.
> > > > >
> > > > > Another thing is that in the kernel there currently is no way to build
> > > > > with just tpm1.2 or tpm2.0 support so the kernel support for tpm1.2
> > > > > would still be there.
> > > > >
> > > > > I don't think Fedora needs to drop the tpm1.2 support if people want 
> > > > > to
> > > > > continue supporting it, but wanted to put the question out there and 
> > > > > see
> > > > > how everyone felt.
> > > >
> > > > I think it should be dropped, tpm2 has been shipped in hardware for 5+
> > > > years and tpm1 has security issues, so I think the time is now to drop
> > > > it. Please do a Fedora Change proposal to ensure it's communicated
> > > > properly.
> > >
> > > Won't that hurt people that have keys trapped in a TPM 1.2 device ?
> >
> > Won't it hurt RHEL users in similar ways?
>
> It may, but that is RHEL, and this Fedora, no ?
>
> > What is the likelihood of
> > those users actively upgrading anyway?
>
> Upgrades in RHEL are a much bigger deal, and usually better researched
> (also rare, usually people reinstall there).

Really? I did a number of years in RH Consulting and I'd like to see
where you get that data from. It varies a LOT.

> In Fedora distro-upgrading w/o looking too hard at release notes is
> common.
>
> Of course the amount of people that uses TPM 1.2 in Fedora is probably
> very small, so this change may be ok, but I just wanted to raise the
> issue.

Sure, and I don't disagree with both those assessments

> Is there a way, after update to still use TPM 1.2 at all (even if it
> requires installing copr/other repo packages)? Or will people need to
> roll back their system to access those secrets at all ?

I haven't looked that far. Ultimately we never supported it for things
like disk encryption particularly well and in any easy manner without
jumping through hoops, eg it's not supported through things like
clevis, there was some support in some VPN related bits but not well
via the standard tools for VPN like NetworkManager so I suspect the
actual use of tpm1 was little.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora TPM1.2 Support

On Fri, 2020-12-04 at 14:08 +, Peter Robinson wrote:
> On Fri, Dec 4, 2020 at 2:04 PM Simo Sorce  wrote:
> > On Thu, 2020-12-03 at 21:25 +, Peter Robinson wrote:
> > > > We are looking to no longer support TPM1.2 in RHEL9. Than raised the
> > > > question with regards to opencryptoki-tpmtok if it should be changed in
> > > > Fedora as well, so I thought I'd see what everyone thinks about future
> > > > TPM1.2 support in Fedora. I know at one point in the last year or so
> > > > trousers almost dropped from Fedora due to being orphaned for quite a
> > > > while. From what I could find the following packages have dependencies:
> > > > 
> > > > ecryptfs-utils  - --disable-tspi
> > > > openconnect - looks like it will only build support if trousers-devel is
> > > >   there, and makes use of tpm2-tss as well.
> > > > strongswan  - --enable-tss-tss2 instead of --enable-tss-trousers?
> > > > tboot   - the trousers dependency was just in a policy tool that 
> > > > has now
> > > >   been deprecated upstream.
> > > > opencryptoki-tpmtok - --disable-tpmtok
> > > > 
> > > > tpm-quote-tools, tpm-tools, and trousers are all tpm1.2 specific
> > > > packages.
> > > > 
> > > > Another thing is that in the kernel there currently is no way to build
> > > > with just tpm1.2 or tpm2.0 support so the kernel support for tpm1.2
> > > > would still be there.
> > > > 
> > > > I don't think Fedora needs to drop the tpm1.2 support if people want to
> > > > continue supporting it, but wanted to put the question out there and see
> > > > how everyone felt.
> > > 
> > > I think it should be dropped, tpm2 has been shipped in hardware for 5+
> > > years and tpm1 has security issues, so I think the time is now to drop
> > > it. Please do a Fedora Change proposal to ensure it's communicated
> > > properly.
> > 
> > Won't that hurt people that have keys trapped in a TPM 1.2 device ?
> 
> Won't it hurt RHEL users in similar ways?

It may, but that is RHEL, and this Fedora, no ?

> What is the likelihood of
> those users actively upgrading anyway?

Upgrades in RHEL are a much bigger deal, and usually better researched
(also rare, usually people reinstall there).

In Fedora distro-upgrading w/o looking too hard at release notes is
common.

Of course the amount of people that uses TPM 1.2 in Fedora is probably
very small, so this change may be ok, but I just wanted to raise the
issue.

Is there a way, after update to still use TPM 1.2 at all (even if it
requires installing copr/other repo packages)? Or will people need to
roll back their system to access those secrets at all ?

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

2020-12-04 Thread Kevin Kofler via devel

Fabio Valentini wrote:
> Is there a reason why "main" is proposed instead of "rawhide" on src.fp.o?
> For all non-dist-git repositories I am fine with "main", but if we are
> changing this anyway, "rawhide" would actually make more sense for
> dist-git repos.
> This would make the branch name actually match the "releasever".

+1 for "rawhide" as the branch name.

I have always seen the inconsistency between "rawhide" and "master" as a 
result of "master" being a default name in git. If we are going to change it 
anyway, we should change it to the real name ("rawhide"), and not to a third 
(!) name for the same thing ("main").

I also agree that for the non-dist-git repositories, "main" is fine. I 
initially (when this discussion started a few months ago) found it pretty 
surprising that "master" is seen as an issue in this context considering 
that there is no "slave" branch, but since the consensus in the community 
appears to be that it is indeed an issue, using a name like "main" that 
hopefully does not offend anyone makes sense. But dist-git should change to 
"rawhide" rather than "main".

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

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

On Fri, Dec 4, 2020 at 9:03 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Dec 03, 2020 at 12:24:32PM -0800, Kevin Fenzi wrote:
> > On Thu, Dec 03, 2020 at 03:25:20PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Thu, Dec 03, 2020 at 04:15:24PM +0100, Pierre-Yves Chibon wrote:
> > > > On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
> > > > > On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton  wrote:
> > > > > >
> > > > > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> > > > > >
> > > > > > == Summary ==
> > > > > >
> > > > > > This Change will move Fedora git repositories to use "main" as the
> > > > > > default git branch instead of "master". Specific repositories will 
> > > > > > be
> > > > > > manually moved and default git branch for new projects will be set 
> > > > > > to
> > > > > > use "main".
> > > > >
> > > > > Is there a reason why "main" is proposed instead of "rawhide" on 
> > > > > src.fp.o?
> > > > > For all non-dist-git repositories I am fine with "main", but if we are
> > > > > changing this anyway, "rawhide" would actually make more sense for
> > > > > dist-git repos.
> > > >
> > > > One of the argument was that not every namespace on dist-git has a 
> > > > rawhide
> > > > version, for example containers do not have/use rawhide.
> > > > And having different default branches on different namespaces is not 
> > > > very
> > > > appealing.
> > >
> > > I second the request to use "rawhide" for rawhide branches.
> > >
> > > The way that branches in dist-git are used is very different from how
> > > branches are used in the usual git repo, so I find the argument that
> > > the same rules as in other repos should be used convincing. If we rename
> >
> > Not convincing? :)
>
> Yeah, sorry. That sentence was clearly too long.
>
> > > it to rawhide, we have the simple rule that "branch of a given name is
> > > used to build for that Fedora release", without any further explanation
> > > about one exception necessary.
> >
> > Thats nice I guess, but it's still going to be more confusing for new
> > users that would expect a main branch (after more things move to that
> > around the world).
> >
> > I suppose we could split the difference and make main a ref to rawhide
> > or vice versa?
>
> That'd work for me.
>

I've filed an RFE for supporting this use-case:
https://pagure.io/pagure/issue/5061



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

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

Missing expected images:

Xfce raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
3 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 14/180 (x86_64), 23/117 (aarch64)

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

ID: 735547  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/735547
ID: 735589  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/735589
ID: 735604  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/735604
ID: 735615  Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/735615
ID: 735734  Test: aarch64 universal support_server@uefi
URL: https://openqa.fedoraproject.org/tests/735734
ID: 735751  Test: aarch64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/735751
ID: 735765  Test: aarch64 universal install_european_language@uefi
URL: https://openqa.fedoraproject.org/tests/735765
ID: 735766  Test: aarch64 universal install_iscsi@uefi
URL: https://openqa.fedoraproject.org/tests/735766
ID: 735770  Test: aarch64 universal install_kickstart_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/735770

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

ID: 735503  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/735503
ID: 735504  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/735504
ID: 735507  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/735507
ID: 735510  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/735510
ID: 735511  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/735511
ID: 735518  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/735518
ID: 735519  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/735519
ID: 735528  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/735528
ID: 735531  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/735531
ID: 73  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/73
ID: 735592  Test: aarch64 Server-dvd-iso 
install_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/735592
ID: 735593  Test: aarch64 Server-dvd-iso install_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/735593
ID: 735607  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/735607
ID: 735610  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/735610
ID: 735616  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/735616
ID: 735620  Test: aarch64 Server-dvd-iso server_cockpit_default@uefi
URL: https://openqa.fedoraproject.org/tests/735620
ID: 735624  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/735624
ID: 735625  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/735625
ID: 735634  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/735634
ID: 735657  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/735657
ID: 735716  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/735716
ID: 735722  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/735722
ID: 735739  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/735739
ID: 735743  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/735743
ID: 735749  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/735749
ID: 735763  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/735763
ID: 735772  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/735772
ID: 735773  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/735773

Soft failed openQA tests: 44/117 (aarch64), 82/180 (x86_64)
(Tests completed,

Re: Should the default editor be changed from vi to nano on upgrades to Fedora 33+

2020-12-04 Thread Kevin Kofler via devel

Ben Cotton wrote:
> ...changes in default behavior, when 1. technically reasonable and 2.
> not explicitly overridden by the user, should generally be made on
> upgrade.

I disagree. Upgrades should be as unsurprising as possible and keep user 
configuration as much as possible. Changes in defaults should normally 
(i.e., where technically reasonable) only be done for new installs. For 
upgrades, any changes should normally be opt-in, not opt-out.

> Distributions are supposed to be opinionated

No, absolutely not. Distributions are supposed to be at the users' service, 
not the other way round.

> and in cases where the user has accepted our opinion, we should do our
> best to provide it whether the system in question is an upgrade or a fresh
> install.

But as you state it:

> The difficulty here is cases where the user also has an opinion that
> formerly aligned with the distribution's opinion and no longer does.

Just because the user agreed with your former opinion does not mean they 
will agree with you making a U-turn on it as well.

And please note that this is NOT about my personal editor preference: I 
personally think nano is the much more user-friendly editor and my vi 
knowledge is limited to ":q!". So I think the new default definitely makes 
sense, for new installations, and I'll happily take the opt-in when I 
upgrade my systems. (I rarely use the default editor because I mostly use 
GUIs, so I usually just temporarily override EDITOR to something sane, 
usually kwrite because I'm in a GUI environment, and have never bothered 
actually setting EDITOR systemwide.) I just do not agree that the default 
editor should be forcefully changed for all existing installations. Also 
because, each time I upgrade Fedora, I routinely have to go through the list 
of Changes and undo whatever can be undone.

> In most cases, the benefits to a consistent experience outweigh the
> detriments of the user having to explicitly override an opinion.

I think not making surprising changes to existing installations is more 
important than consistency between old/upgraded and new installations.

> (I include the phrase "technically reasonable" above to account for
> cases like changing the default file system, which is not something
> you'd particularly want to try changing on existing systems at upgrade
> time)

Of course, my opposite opinion should be understood with the same 
limitation: Sometimes it is just not technically reasonable to keep 
supporting the old default, e.g., if it depends on some software package 
that is no longer maintained upstream. (E.g., I am NOT proposing that the 
KDE Spin should keep defaulting to Plasma 5 for upgrades after Plasma 6 is 
out, that would make no sense.) But where it is technically reasonable, 
changes should always be opt-in, not opt-out, for upgrades.

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

Re: Fedora TPM1.2 Support

2020-12-04 Thread Peter Robinson

On Fri, Dec 4, 2020 at 2:04 PM Simo Sorce  wrote:
>
> On Thu, 2020-12-03 at 21:25 +, Peter Robinson wrote:
> > > We are looking to no longer support TPM1.2 in RHEL9. Than raised the
> > > question with regards to opencryptoki-tpmtok if it should be changed in
> > > Fedora as well, so I thought I'd see what everyone thinks about future
> > > TPM1.2 support in Fedora. I know at one point in the last year or so
> > > trousers almost dropped from Fedora due to being orphaned for quite a
> > > while. From what I could find the following packages have dependencies:
> > >
> > > ecryptfs-utils  - --disable-tspi
> > > openconnect - looks like it will only build support if trousers-devel is
> > >   there, and makes use of tpm2-tss as well.
> > > strongswan  - --enable-tss-tss2 instead of --enable-tss-trousers?
> > > tboot   - the trousers dependency was just in a policy tool that has 
> > > now
> > >   been deprecated upstream.
> > > opencryptoki-tpmtok - --disable-tpmtok
> > >
> > > tpm-quote-tools, tpm-tools, and trousers are all tpm1.2 specific
> > > packages.
> > >
> > > Another thing is that in the kernel there currently is no way to build
> > > with just tpm1.2 or tpm2.0 support so the kernel support for tpm1.2
> > > would still be there.
> > >
> > > I don't think Fedora needs to drop the tpm1.2 support if people want to
> > > continue supporting it, but wanted to put the question out there and see
> > > how everyone felt.
> >
> > I think it should be dropped, tpm2 has been shipped in hardware for 5+
> > years and tpm1 has security issues, so I think the time is now to drop
> > it. Please do a Fedora Change proposal to ensure it's communicated
> > properly.
>
> Won't that hurt people that have keys trapped in a TPM 1.2 device ?

Won't it hurt RHEL users in similar ways? What is the likelihood of
those users actively upgrading anyway?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Should the default editor be changed from vi to nano on upgrades to Fedora 33+

On Fri, Dec 4, 2020 at 9:01 AM Simo Sorce  wrote:
>
> On Thu, 2020-12-03 at 15:41 -0500, Ben Cotton wrote:
> > On Thu, Dec 3, 2020 at 3:32 PM Tom Hughes via devel
> >  wrote:
> > > What exactly does "change the default on upgrade" actually mean
> > > here? Making nano-default-editor a dependency of something else
> > > that people are likely to have installed? Or adding something to
> > > some sort of post install script for system-upgrade that installs
> > > that package?
> >
> > From the BZ Miro linked to in the start of this thread:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1896707#c12
> > > dnf system-upgrade also upgrades groups, so nano-default-editor gets 
> > > installed on system upgrades
> > > If I accept our argument then how do I choose not to accept your
> > > opinion and "explicitly override" this choice?
> >
> > Also from that bug:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1896707#c13
> > > "dnf remove nano-default-editor". Alternatively, you can set "export 
> > > EDITOR=vim" in your ~/.bash_profile
>
>
> Shouldn't we just set export EDITOR=nano in the default profile and leave 
> existing users alone?
>
> I cannot see how change a *user default* vs a system default, can *ever* be 
> acceptable.
>

The intent is to make it the system-wide default when the user has no
setting. If the user has a setting in their profile, then that is
respected, regardless of whether the package is installed or not.



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

Re: Fedora TPM1.2 Support

On Thu, 2020-12-03 at 21:25 +, Peter Robinson wrote:
> > We are looking to no longer support TPM1.2 in RHEL9. Than raised the
> > question with regards to opencryptoki-tpmtok if it should be changed in
> > Fedora as well, so I thought I'd see what everyone thinks about future
> > TPM1.2 support in Fedora. I know at one point in the last year or so
> > trousers almost dropped from Fedora due to being orphaned for quite a
> > while. From what I could find the following packages have dependencies:
> > 
> > ecryptfs-utils  - --disable-tspi
> > openconnect - looks like it will only build support if trousers-devel is
> >   there, and makes use of tpm2-tss as well.
> > strongswan  - --enable-tss-tss2 instead of --enable-tss-trousers?
> > tboot   - the trousers dependency was just in a policy tool that has now
> >   been deprecated upstream.
> > opencryptoki-tpmtok - --disable-tpmtok
> > 
> > tpm-quote-tools, tpm-tools, and trousers are all tpm1.2 specific
> > packages.
> > 
> > Another thing is that in the kernel there currently is no way to build
> > with just tpm1.2 or tpm2.0 support so the kernel support for tpm1.2
> > would still be there.
> > 
> > I don't think Fedora needs to drop the tpm1.2 support if people want to
> > continue supporting it, but wanted to put the question out there and see
> > how everyone felt.
> 
> I think it should be dropped, tpm2 has been shipped in hardware for 5+
> years and tpm1 has security issues, so I think the time is now to drop
> it. Please do a Fedora Change proposal to ensure it's communicated
> properly.

Won't that hurt people that have keys trapped in a TPM 1.2 device ?

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

2020-12-04 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Dec 03, 2020 at 12:24:32PM -0800, Kevin Fenzi wrote:
> On Thu, Dec 03, 2020 at 03:25:20PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Dec 03, 2020 at 04:15:24PM +0100, Pierre-Yves Chibon wrote:
> > > On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
> > > > On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton  wrote:
> > > > >
> > > > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> > > > >
> > > > > == Summary ==
> > > > >
> > > > > This Change will move Fedora git repositories to use "main" as the
> > > > > default git branch instead of "master". Specific repositories will be
> > > > > manually moved and default git branch for new projects will be set to
> > > > > use "main".
> > > > 
> > > > Is there a reason why "main" is proposed instead of "rawhide" on 
> > > > src.fp.o?
> > > > For all non-dist-git repositories I am fine with "main", but if we are
> > > > changing this anyway, "rawhide" would actually make more sense for
> > > > dist-git repos.
> > > 
> > > One of the argument was that not every namespace on dist-git has a rawhide
> > > version, for example containers do not have/use rawhide.
> > > And having different default branches on different namespaces is not very
> > > appealing.
> > 
> > I second the request to use "rawhide" for rawhide branches.
> > 
> > The way that branches in dist-git are used is very different from how
> > branches are used in the usual git repo, so I find the argument that
> > the same rules as in other repos should be used convincing. If we rename
> 
> Not convincing? :) 

Yeah, sorry. That sentence was clearly too long.

> > it to rawhide, we have the simple rule that "branch of a given name is
> > used to build for that Fedora release", without any further explanation
> > about one exception necessary.
> 
> Thats nice I guess, but it's still going to be more confusing for new
> users that would expect a main branch (after more things move to that
> around the world). 
> 
> I suppose we could split the difference and make main a ref to rawhide
> or vice versa?

That'd work for me.

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

Re: Should the default editor be changed from vi to nano on upgrades to Fedora 33+

On Thu, 2020-12-03 at 15:41 -0500, Ben Cotton wrote:
> On Thu, Dec 3, 2020 at 3:32 PM Tom Hughes via devel
>  wrote:
> > What exactly does "change the default on upgrade" actually mean
> > here? Making nano-default-editor a dependency of something else
> > that people are likely to have installed? Or adding something to
> > some sort of post install script for system-upgrade that installs
> > that package?
> 
> From the BZ Miro linked to in the start of this thread:
> https://bugzilla.redhat.com/show_bug.cgi?id=1896707#c12
> > dnf system-upgrade also upgrades groups, so nano-default-editor gets 
> > installed on system upgrades
> > If I accept our argument then how do I choose not to accept your
> > opinion and "explicitly override" this choice?
> 
> Also from that bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1896707#c13
> > "dnf remove nano-default-editor". Alternatively, you can set "export 
> > EDITOR=vim" in your ~/.bash_profile


Shouldn't we just set export EDITOR=nano in the default profile and leave 
existing users alone?

I cannot see how change a *user default* vs a system default, can *ever* be 
acceptable.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

Re: Mass spec file change: Adding BuildRequires: make


On 12/3/20 6:27 PM, Tom Stellard wrote:
However, in the discussion on the mailing list for this change, not everyone 
agreed that cmake should Require make and this point was never resolved.  So, 
since there is still ambiguity here, I am planning to do the safest option, 
which is to add BuildRequires: make even for packages 
that use %cmake_build and do not invoke make directly.


For what's it worth I think that packages that only use make via cmake should 
not have an explcit dependency on make. Packages that use make directly should 
have an explicit dependency on make (even if they already BR cmake).


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: updating nbconvert


On 12/4/20 1:14 PM, José Abílio Matos wrote:

On Friday, December 4, 2020 9:56:35 AM WET Lumír Balhar wrote:

 > Hello.

 >

 > I'm getting HTTP/404 for

 > https://download.copr.fedorainfracloud.org/results/nonamedotc/nbconvert-6.0

 > .7/fedora-rawhide-x86_64/01795156-python-nbconvert/

 >

 > Could you please try to rebuild the package?

 > Have a nice day.

 >

 > Lumír


Probably the build was erased, another place where it can be found is:

https://copr-be.cloud.fedoraproject.org/results/nonamedotc/nbconvert-6.0.7/fedora-rawhide-x86_64/01795144-python-nbconvert/ 
 


Once (if) this expires as well, here is a more permanent link:

https://copr.fedorainfracloud.org/coprs/nonamedotc/nbconvert-6.0.7/builds/

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org

Fedora rawhide compose report: 20201204.n.0 changes

2020-12-04 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20201203.n.1
NEW: Fedora-Rawhide-20201204.n.0

= SUMMARY =
Added images:2
Dropped images:  0
Added packages:  1
Dropped packages:0
Upgraded packages:   44
Downgraded packages: 0

Size of added packages:  73.13 KiB
Size of dropped packages:0 B
Size of upgraded packages:   1.73 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20201204.n.0.iso
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20201204.n.0-sda.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: golang-github-hetznercloud-hcloud-1.23.1-1.fc34
Summary: Go library for the Hetzner Cloud API
RPMs:golang-github-hetznercloud-hcloud-devel
Size:73.13 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  apfs-fuse-0-14.20200928git290028b.fc34
Old package:  apfs-fuse-0-13.20200928git290028b.fc34
Summary:  A read-only FUSE driver for Apple's APFS
RPMs: apfs-fuse
Size: 1.16 MiB
Size change:  3.97 KiB
Changelog:
  * Thu Dec 03 2020 Peter Robinson  - 
0-14.20200928git290028b
  - Require fuse3 not fuse as it's built against that


Package:  certbot-1.10.1-1.fc34
Old package:  certbot-1.10.0-1.fc34
Summary:  A free, automated certificate authority client
RPMs: certbot python3-certbot
Size: 397.30 KiB
Size change:  611 B
Changelog:
  * Thu Dec 03 2020 Felix Schwarz  - 1.10.1-1
  - Update to 1.10.1 (#1904183)


Package:  cross-binutils-2.35.1-4.fc34
Old package:  cross-binutils-2.35.1-3.fc34
Summary:  A GNU collection of cross-compilation binary utilities
RPMs: binutils-aarch64-linux-gnu binutils-alpha-linux-gnu 
binutils-arc-linux-gnu binutils-arm-linux-gnu binutils-avr32-linux-gnu 
binutils-bfin-linux-gnu binutils-c6x-linux-gnu binutils-cris-linux-gnu 
binutils-frv-linux-gnu binutils-h8300-linux-gnu binutils-hppa-linux-gnu 
binutils-hppa64-linux-gnu binutils-ia64-linux-gnu binutils-m32r-linux-gnu 
binutils-m68k-linux-gnu binutils-metag-linux-gnu binutils-microblaze-linux-gnu 
binutils-mips64-linux-gnu binutils-mn10300-linux-gnu binutils-nios2-linux-gnu 
binutils-openrisc-linux-gnu binutils-powerpc64-linux-gnu 
binutils-powerpc64le-linux-gnu binutils-ppc64-linux-gnu 
binutils-ppc64le-linux-gnu binutils-riscv64-linux-gnu binutils-s390x-linux-gnu 
binutils-score-linux-gnu binutils-sh-linux-gnu binutils-sparc64-linux-gnu 
binutils-tile-linux-gnu binutils-x86_64-linux-gnu binutils-xtensa-linux-gnu 
cross-binutils-common
Size: 327.23 MiB
Size change:  82.60 KiB
Changelog:
  * Thu Dec 03 2020 Peter Robinson  - 2.35.1-4
  - Sync to binutils-2.35.1-16


Package:  firefox-83.0-14.fc34
Old package:  firefox-83.0-13.fc34
Summary:  Mozilla Firefox Web browser
RPMs: firefox firefox-wayland firefox-x11 mozilla-firefox-testresults
Added RPMs:   mozilla-firefox-testresults
Size: 210.20 MiB
Size change:  6.15 MiB
Changelog:
  * Tue Dec 01 2020 Martin Stransky  - 83.0-14
  - Enabled LTO


Package:  fontconfig-2.13.93-3.fc34
Old package:  fontconfig-2.13.93-2.fc34
Summary:  Font configuration and customization library
RPMs: fontconfig fontconfig-devel fontconfig-devel-doc
Size: 2.51 MiB
Size change:  2.39 KiB
Changelog:
  * Thu Dec 03 2020 Akira TAGOH  - 2.13.93-3
  - Add back fullname property at the scan matching phase for the backward 
compatibility.
Resolves: rhbz#1902881


Package:  golang-github-aliyun-cli-3.0.64-1.s20201203git9ce1f8a.fc34
Old package:  golang-github-aliyun-cli-3.0.63-1.s20201130gitf7af21e.fc34
Summary:  Alibaba Cloud (Aliyun) CLI
RPMs: golang-github-aliyun-cli golang-github-aliyun-cli-devel 
golang-github-aliyun-openapi-meta-devel
Size: 25.03 MiB
Size change:  -67.61 KiB
Changelog:
  * Thu Dec 03 2020 Brandon Perkins  - 3.0.64-1
  - Update to version 3.0.64 (#1903194)
  - Update to aliyun-openapi-meta to commit
9ce1f8ae486d76f0fc92a33082b764e73d5bf955


Package:  golang-github-prometheus-2.23.0-1.fc34
Old package:  golang-github-prometheus-2.20.0-2.fc34
Summary:  Prometheus monitoring system and time series database
RPMs: golang-github-prometheus golang-github-prometheus-devel
Size: 138.13 MiB
Size change:  26.27 MiB
Changelog:
  * Thu Dec 03 2020 Robert-Andr?? Mauchin  - 2.23.0-3
  - Update to 2.23.0
  - Add configuration
  - Close rhbz#1866613
  - Fix rhbz#1894089
  - Fix rhbz#1902496


Package:  golang-github-prometheus-common-0.15.0-1.fc34
Old package:  golang-github-prometheus-common-0.10.0-1.fc33
Summary:  Go libraries shared across prometheus components and libraries
RPMs: golang-github-prometheus-common-devel 
golang-github-prometheus-common-promlog-devel
Size: 88.02 KiB
Size change:  517 B
Changelog:
  * Thu Dec 03 2020

Re: Fedora 34 Change proposal: Xwayland as a standalone package (System-Wide Change)

2020-12-04 Thread Fabio Valentini

On Wed, Dec 2, 2020 at 11:34 AM Olivier Fourdan  wrote:
> This is a twofold question, a possible xserver 1.21 version and a separate 
> release of Xwayland upstream.
>
> Regarding a possible xserver 1.21 release, I guess that would be up to 
> someone upstream to step up and coordinate such a release upstream (and that 
> wouldn't even need to be a last, final release, as long as people are willing 
> to work on it upstream).

I understand. I assume that it's not possible for just anybody to step
up to do that? Not that I really want to volunteer, the X code base is
scary :)

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

Re: updating nbconvert

2020-12-04 Thread José Abílio Matos

On Friday, December 4, 2020 9:56:35 AM WET Lumír Balhar wrote:
> Hello.
> 
> I'm getting HTTP/404 for
> https://download.copr.fedorainfracloud.org/results/nonamedotc/nbconvert-6.0
> .7/fedora-rawhide-x86_64/01795156-python-nbconvert/
> 
> Could you please try to rebuild the package?
> Have a nice day.
> 
> Lumír

Probably the build was erased, another place where it can be found is:
https://copr-be.cloud.fedoraproject.org/results/nonamedotc/nbconvert-6.0.7/
fedora-rawhide-x86_64/01795144-python-nbconvert/ 

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

Re: Should the default editor be changed from vi to nano on upgrades to Fedora 33+

2020-12-04 Thread Vít Ondruch



Dne 04. 12. 20 v 12:36 Marius Schwarz napsal(a):

Am 03.12.20 um 21:06 schrieb Ben Cotton:

...changes in default behavior, when 1. technically reasonable and 2.
not explicitly overridden by the user, should generally be made on
upgrade. Distributions are supposed to be opinionated, and in cases
where the user has accepted our opinion, we should do our best to
provide it whether the system in question is an upgrade or a fresh
install.
Has anyone made any test on installed system, how man of them got 
changed by theire users to reflect a trend on changes in the user 
favor for vi or nano?


Or simpler: on which numbers has this decission been made? It is a 
"oh, i like nano and hate vim, so i suggest to change it" case or the 
"we asked 10.000 users  which editor they favor?" one?


One of those is a good base for a change proprosal, the other one not.

I, i.E., favor vi, as it has advantages.



Wasn't this already thoroughly discussed in the original change proposal 
ML thread?


https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/U5C4CC2O44E7Q4MVTT772NP667HTP25S/#U5C4CC2O44E7Q4MVTT772NP667HTP25S


Vít




Best regards,
Marius Schwarz
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital 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

[Test-Announce] Fedora 34 Rawhide 20201204.n.0 nightly compose nominated for testing

2020-12-04 Thread rawhide

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

Notable package version changes:
parted - 20201201.n.0: parted-3.3-7.fc34.src, 20201204.n.0: 
parted-3.3-8.fc34.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/34

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

https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201204.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201204.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201204.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201204.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201204.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201204.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Rawhide_20201204.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Should the default editor be changed from vi to nano on upgrades to Fedora 33+