Fedora-Cloud-33-20201203.0 compose check report

[Fedora compose checker]

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-20201202.0):

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

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] Please Review 4472

[William Brown]

https://github.com/389ds/389-ds-base/pull/4472
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Packaging chunkfs - no debug output

[Richard Shaw]

Bah... I'm seriously about to create a CMake config for this rather than
deal with the crappy Makefile...

/usr/bin/ld: /tmp/unchunkfs.bkUTgL.ltrans0.ltrans.o: in function `main':
/tmp/rpkg/chunkfs-25-h3w4te_q/chunkfs-0.8/unchunkfs.c:199: undefined
reference to `fuse_main_real_compat25'
/usr/bin/ld: /tmp/rpkg/chunkfs-25-h3w4te_q/chunkfs-0.8/unchunkfs.c:194:
undefined reference to `fuse_main_real_compat25'
/usr/bin/ld: /tmp/rpkg/chunkfs-25-h3w4te_q/chunkfs-0.8/unchunkfs.c:229:
undefined reference to `fuse_main_real_compat25'
collect2: error: ld returned 1 exit status
make: *** [: unchunkfs] Error 1
gcc -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -s -lfuse  unchunkfs.o
utils.o   -o unchunkfs
make: *** Waiting for unfinished jobs
/usr/bin/ld: /tmp/chunkfs.2zHD4j.ltrans0.ltrans.o: in function `main':
/tmp/rpkg/chunkfs-25-h3w4te_q/chunkfs-0.8/chunkfs.c:212: undefined
reference to `fuse_main_real_compat25'
/usr/bin/ld: /tmp/rpkg/chunkfs-25-h3w4te_q/chunkfs-0.8/chunkfs.c:207:
undefined reference to `fuse_main_real_compat25'
/usr/bin/ld: /tmp/rpkg/chunkfs-25-h3w4te_q/chunkfs-0.8/chunkfs.c:231:
undefined reference to `fuse_main_real_compat25'
collect2: error: ld returned 1 exit status
make: *** [: chunkfs] Error 1
gcc -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -s -lfuse  chunkfs.o utils.o
  -o chunkfs

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

Schedule for Thursday's FPC Meeting (2020-12-03 17:00 UTC)

[James Antill]

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

 Local time information (via. uitime):

= Day: Thursday ==
2020-12-03 09:00 PST  US/Pacific
2020-12-03 12:00 EST  --> US/Eastern <--
2020-12-03 17:00 GMT  Europe/London 
2020-12-03 17:00 UTC  UTC   
2020-12-03 18:00 CET  Europe/Berlin 
2020-12-03 18:00 CET  Europe/Paris  
2020-12-03 22:30 IST  Asia/Calcutta 
 New Day: Friday -
2020-12-04 01:00 HKT  Asia/Hong_Kong
2020-12-04 01:00 +08  Asia/Singapore
2020-12-04 02:00 JST  Asia/Tokyo
2020-12-04 03:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

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

= Followup Actions =

#topic #pr-954
 * King_InuYasha
   talk to copr to get config. turned on
 * tibbs
   talk to releng to get config. turned on

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

#topic Open Floor
 * decathorpe
   look through non-meeting tickets, see if any are stuck/need to be discussed

= Followup Issues =

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

= Followup Pull Requests =

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

= Open Floor = 

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

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

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

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

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Dusty Mabe]

On 12/2/20 12:57 PM, Ben Cotton wrote:
> On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson
>  wrote:
>>
>> So to boil this down into a representative question: when we are doing
>> the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
>> whether to release "Fedora CoreOS 34"?
>>
> This question is relevant to my interests.

That's fair. I think the answer to this question is that we need to consider
the way the Fedora CoreOS update streams/release model can play into this.
In short I think we'll all need to evolve a bit. It's just not going to be
the exact same as traditional Fedora major releases have been.

> 
> On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson
>  wrote:
>>
>> Note that if you go to getfedora.org and click on CoreOS *right now*,
>> it offers you a Fedora 32-based CoreOS. This is the kind of thing that
>> is kinda fine so long as it's an Emerging Edition. It would *not*,
>> IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
>> months after Fedora 34 is "released", our "stable" CoreOS is still
>> Fedora 33-based, that seems like the sort of thing that would look bad.
> 
> I agree. I understand the reasoning, but I'd really like to see FCOS
> align with the rest of the schedule or at least develop a clear and
> succinct explanation of why it's delayed so that the public and the
> tech press can easily understand.

I 100% would like to get to a point where we rebase to the latest Fedora
major soon after release. As jlebon mentioned earlier this does mean working
harder to get ahead of the curve by adopting a rawhide development stream
(not exposed to users) and taking more part in the Changes process.

> 
> On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa  wrote:
>>
>> I would personally rather see Fedora CoreOS pulled *back* into the
>> fold more as an Edtion
> 
> From a program management perspective, I've largely closed my eyes and
> gone "la la la" when it comes to FCOS, in part because it is so
> separate from what we know as Fedora. Making FCOS work more like what
> we know as Fedora would certainly be helpful from my perspective, but
> at the same time there are technical challenges to that. And maybe
> what FCOS does from a distro-building standpoint is more like what we
> should move toward. Maybe not.

Yes. I think we should consider it with a slightly different perspective
than we do other editions, but I'm definitely not asking for a pass. Let's
work together to define the future.

> 
> In any case, part of the work to be done here, if the Change is
> approved, is for me to figure out how to include FCOS in some of the
> program management work.
> 
> I wonder if it would be better to target this for Fedora 35, with some
> of the work starting now. Given the work it took to get IoT into the
> fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34
> feels pretty optimistic here.

I think that's reasonable, but maybe we can meet sooner to try to get some
answers to foundational questions answered so that we can be prepared to
be in better compliance for the Fedora 35 timeframe.

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Dusty Mabe]

On 12/2/20 12:33 PM, Adam Williamson wrote:



> 
> Note that if you go to getfedora.org and click on CoreOS *right now*,
> it offers you a Fedora 32-based CoreOS. This is the kind of thing that
> is kinda fine so long as it's an Emerging Edition. It would *not*,
> IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
> months after Fedora 34 is "released", our "stable" CoreOS is still
> Fedora 33-based, that seems like the sort of thing that would look bad.
> 

There are three update streams for Fedora CoreOS. The "stable" stream is still
on Fedora 32 but has been receiving bi-weekly updates and should be switched 
over
to Fedora 33 soon (probably this week). The `next` and `testing` streams have 
been
updated to Fedora 33 and the `next` stream has been on F33 since early october. 
My
point here is that if you want Fedora 33 and you are a Fedora CoreOS user you 
can
easily adopt a stream that has it.

Why is our FCOS stable stream still on Fedora 32? Our FCOS instances have 
automatic
updates on by default and we're trying very hard to not break systems on 
upgrade and
require human intervention. There are several changes in Fedora 33, including 
migrating
to systemd-resolved and also systemd changing the default fallback hostname 
from `localhost`
to `fedora` that are causing issues for people and we're trying to consider 
these things first.

Ideally we update our stable stream closer to Fedora's actual release date but 
I think it's
important to maybe release Fedora CoreOS from the notion that it's tightly 
coupled with the
Fedora major release date for a few reasons:

- we have people follow update streams and systems update automatically
- it's more of a "rolling" release, with incremental feature improvements and 
major rebases periodically
- this is a departure from Atomic Host where you had to manually decide 
when to do a major rebase
- new features get added all the time, mid stream, so it's more of a 
continuous development model

Ultimately it's just a slightly different release/development model (adopted 
from CoreOS Container
Linux) than what Fedora has traditionally used, but I don't think that's any 
reason to treat it like
it's not Fedora. We should embrace it and see the positives along with the 
negatives of the model.

Dusty

P.S. For more info on our various update streams see: 
https://docs.fedoraproject.org/en-US/fedora-coreos/update-streams/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1851872] Wrong tag in comment line of DKIM record: 'i=' should be 's='

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||amavis-2.12.1-3.el8
 Resolution|--- |ERRATA
Last Closed||2020-12-03 02:09:30



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2020-ca1ac5519e has been pushed to the Fedora EPEL 8 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

[Bug 1890417] amavisd-new-snmp can't be installed on EL8 because of dropped net-snmp-perl

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||amavis-2.12.1-3.el8
 Resolution|--- |ERRATA
Last Closed||2020-12-03 02:09:32



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2020-ca1ac5519e has been pushed to the Fedora EPEL 8 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

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

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||w3c-markup-validator-1.3-19
   ||.fc32
 Resolution|--- |ERRATA
Last Closed|2020-11-24 18:06:56 |2020-12-03 01:41:45



--- Comment #9 from Fedora Update System  ---
FEDORA-2020-2bd3082277 has been pushed to the Fedora 32 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

[Bug 1903855] perltidy-20201202 is available

[bugzilla]

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



--- 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/Perl/Perl-Tidy-20201202.tar.gz to
./Perl-Tidy-20201202.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 1903855] New: perltidy-20201202 is available

[bugzilla]

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

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



Latest upstream release: 20201202
Current version/release in rawhide: 20201001-1.fc34
URL: http://search.cpan.org/dist/Perl-Tidy/

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/3553/


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

FedoraRespin-33-updates-20201201.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 3/37 (x86_64)

ID: 734252  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/734252
ID: 734254  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/734254
ID: 734255  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/734255

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

ID: 734249  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/734249
ID: 734251  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/734251

Passed openQA tests: 17/37 (x86_64)

Skipped non-gating openQA tests: 15 of 37
-- 
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: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Matthew Miller]

On Wed, Dec 02, 2020 at 10:59:50PM +0100, David Kaufmann wrote:
> Count me in, but honestly I don't see a lot of things that need to be
> changed - I'm quite happy with how it behaves. But aside that I'm happy
> to help with those issues that come up.

That would be amazing! In order for it to remain as an edition, we (speaking
generally for the Council) like to see regular meetings -- at least monthly.
There are two open issues in the tracker at
https://pagure.io/fedora-server/issues, and even if it's not ever a flood of
things just making sure they're looked at helps keep things going.

That plus status updates on
https://docs.fedoraproject.org/en-US/project/dashboard/ regularly. And of
course people showing up to help with issues at release time.

One outstanding thing that could be worked on is the merger of the Fedora
Cloud Base image and Fedora Server. We agreed that this should be done
several Flocks ago, but no one has had time to actually make it happen.

There was also talk of working more closely with Ansible on system roles.
I'd love to see that revived too! There is also potential for greater
collaboration with CentOS and the CentOS Stream project. I'd love to have a
clear, non-competitive answer for each of these projects on when one should
use what.

And, of course, there's helping develop marketing materials for Mindshare
groups to use to help the Edition grow more users.

But none of these latter things are _necessary_. It's really the first thing
of just reviving the cadence of meetings and status updates.

-- 
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: Packaging chunkfs - no debug output

[Elliott Sales de Andrade]

On Wed, 2 Dec 2020 at 17:45, Richard Shaw  wrote:
>
> On Wed, Dec 2, 2020 at 2:34 PM Elliott Sales de Andrade 
>  wrote:
>>
>>
>>
>> On Wed., Dec. 2, 2020, 11:08 a.m. Richard Shaw,  wrote:
>>>
>>> I'm working on packaging chunkfs for fun and curiosity. It should make 
>>> backing up VMs or other large files with traditional backup compression and 
>>> deduplication methods (i.e. BackupPC) easier by breaking up the file into 
>>> chunks.
>>>
>>> It has a manual Makefile which I've patched to comply with the packaging 
>>> guidelines, but I've run into an issue.
>>>
>>> The build respects the required build flags:
>>>
>>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
>>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
>>> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
>>> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o utils.o utils.c
>>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
>>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
>>> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
>>> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o unchunkfs.o unchunkfs.c
>>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
>>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
>>> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
>>> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o chunkfs.o chunkfs.c
>>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
>>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
>>> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
>>> -fcf-protection -s -lfuse  unchunkfs.o utils.o   -o unchunkfs
>>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
>>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
>>> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
>>> -fcf-protection -s -lfuse  chunkfs.o utils.o   -o chunkfs
>>
>>
>>
>> This appears to be applying CFLAGS, but not LDFLAGS.
>
>
> I tried adding LDFLAGS="%{build_ldflags}" but then I get:
>
> cc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
> -fcf-protection --Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -s -lfuse  chunkfs.o utils.o   
> -o chunkfs
> make: *** Waiting for unfinished jobs
> cc: error: unrecognized command-line option '--Wl,-z,relro'
>

Either your substitution or the makefile has a typo. The flag is
-Wl,-z,relro, single dash, just like the other ones.

Why not use %set_build_flags instead of manually setting *FLAGS?

> Thanks,
> Richard
>

--
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Packaging chunkfs - no debug output

[Richard Shaw]

On Wed, Dec 2, 2020 at 2:34 PM Elliott Sales de Andrade <
quantum.anal...@gmail.com> wrote:

>
>
> On Wed., Dec. 2, 2020, 11:08 a.m. Richard Shaw, 
> wrote:
>
>> I'm working on packaging chunkfs for fun and curiosity. It should make
>> backing up VMs or other large files with traditional backup compression and
>> deduplication methods (i.e. BackupPC) easier by breaking up the file into
>> chunks.
>>
>> It has a manual Makefile which I've patched to comply with the
>> packaging guidelines, but I've run into an issue.
>>
>> The build respects the required build flags:
>>
>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g
>> -grecord-gcc-switches -pipe -Wall -Werror=format-security
>> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic
>> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
>> -DVERSION='"0.8"' -O2 -Wall   -c -o utils.o utils.c
>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g
>> -grecord-gcc-switches -pipe -Wall -Werror=format-security
>> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic
>> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
>> -DVERSION='"0.8"' -O2 -Wall   -c -o unchunkfs.o unchunkfs.c
>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g
>> -grecord-gcc-switches -pipe -Wall -Werror=format-security
>> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic
>> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
>> -DVERSION='"0.8"' -O2 -Wall   -c -o chunkfs.o chunkfs.c
>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g
>> -grecord-gcc-switches -pipe -Wall -Werror=format-security
>> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic
>> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -s
>> -lfuse  unchunkfs.o utils.o   -o unchunkfs
>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g
>> -grecord-gcc-switches -pipe -Wall -Werror=format-security
>> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mtune=generic
>> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -s
>> -lfuse  chunkfs.o utils.o   -o chunkfs
>>
>
>
> This appears to be applying CFLAGS, but not LDFLAGS.
>

I tried adding LDFLAGS="%{build_ldflags}" but then I get:

cc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection --Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -s -lfuse  chunkfs.o utils.o
  -o chunkfs
make: *** Waiting for unfinished jobs
cc: error: unrecognized command-line option '--Wl,-z,relro'

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

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[David Kaufmann]

Hi!

On Wed, Dec 02, 2020 at 11:11:02AM -0500, Ben Cotton wrote:
> One uncomfortable question that this raises: is it time to de-Edition
> Fedora Server?

Please don't, for me it is the Version I'm currently migrating my Centos
7 boxes to, so having it properly tested and being high on the "if it
breaks it needs to be fixed"-list is kinda important for me.

> As far as I can tell, the Server Working Group has essentially been
> dormant for a while, with sgallagh coming in to fix issues when they
> arise. So one alternative to demoting Server would be for someone to
> revive that WG.

Count me in, but honestly I don't see a lot of things that need to be
changed - I'm quite happy with how it behaves. But aside that I'm happy
to help with those issues that come up.

All the best,
Astra


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: External (non-rpm) BuidRequires - was New Mock release v2.7

[Miroslav Suchý]

Dne 02. 12. 20 v 17:19 Vít Ondruch napsal(a):
> Why these requires does not follow some standard naming convention possibly 
> with some prefix?

What do you mean? Like external:python3-foo?

> And actually wouldn't it be better to use some conditional dependency? One 
> idea which comes to my mind is something like:
> BuildRequires: python3-foo or external:python3-foo

This is an excellent idea. I'll put it to packaging recommendations.

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

Re: Delay service startup but only on boot

[Matthew Miller]

On Wed, Dec 02, 2020 at 10:09:52AM -0600, Richard Shaw wrote:
> Nope, it's an external networked device. They always "boot up" at the same
> time, but the computer which runs the service boots up faster than the
> device I need to connect to.

This might be overdoing it, but maybe make a oneshot service which actually
loops on a check if the service is up and exits when it is, and then have
your actual service be after that one?

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

Release cadence and Editions [was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]

[Matthew Miller]

On Wed, Dec 02, 2020 at 12:15:21PM -0800, Adam Williamson wrote:
> with quite a lot of consequences. It has consequences, for instance,
> for our most important forms of communication to the wider world: how
> do we pivot from this simple story that "Fedora is a (set of)
> product(s) that come(s) out every six months, look out for our big
> Fedora XX Release Announcements!" to "Fedora is that, but it's ALSO
> this other thing that has three streams which release every two weeks
> and roll over according to some completely other schedule"? And so on.

I think some of this is helped by not thinking of Fedora as the OS itself,
just like Red Hat isn't RHEL and RHEL isn't Red Hat. I mean, it doesn't
solve any of your problems :) but it's a start towards getting people to
think about it differently. I think this reads a lot more simply:

  Fedora is a project that has a set of deliverables that have traditionally
  been released every six months. We now have some deliverables that follow
  a different schedule. We're moving to a model where our main underlying
  software repository updates on the traditional six-month cadence, our
  various products will come with their own release announcements.

  Fedora Workstation, which is our most popular desktop offering, will stay
  on the familiar April/October release cadence. Silverblue, IoT, and CoreOS
  are examples of other Fedora operating system flavors that follow a
  rolling-release model instead. Our KDE Plasma Desktop follows the upstream
  KDE releases, which happen every four months, using the most-current
  Fedora software base at that time. [This last statement is obviously not
  true, but I'd like it to be a possiblity.] On the other hand, our Fedora
  School OS flavor [also not real] updates only once a year, at the end of
  May, so that school IT teams can deploy over the summer and not worry
  about upgrades until the next summer.

Obviously there's some hard work to make that into a reality. But that's
what I'd like to get to and it's basically what the Council decided we'd
like a couple of years ago. (See below.)

Right now, most of the press we get is around Fedora Workstation no matter
what we do. (I have tried very hard to get press folks to talk about Fedora
Server, Atomic, CoreOS, IoT, KDE and Xfce, SoaS, etc., etc., and I'm lucky
if I get a line or two in an article.) If we want press around other
offerings — desktop, or other use cases — it'll actually be _better_ to
split them off so they're not overshadowed.


> Good question! getfedora.org uses the concept, but doesn't define it.
> So the authoritative source, I guess, is still
> https://fedoraproject.org/wiki/Editions , which says "Fedora Editions
> are curated sets of packages, guidelines and configuration, and
> artifacts built from those pieces, that address a specific, targeted
> use-case. The Editions are the primary Fedora outputs that most Fedora
> users are encouraged to use and directed towards through the download
> site."

The latest official definition is in
https://docs.fedoraproject.org/en-US/council/policy/guiding-policy/#_what_does_this_mean,
which says:

"Some solutions are the premier showcases that we call Editions; these are
 used in the gating tests for our releases."

I'm not super-set on that, though, and would be open to some further
evolution. For example, "gating tests for our releases" should probably be
"for the twice-yearly Fedora rpm repository major-version releases" or
something.¹ And, I think some element of this still is the key thing: we
shouldn't do the general-repo release if it's not possible for the next
release of an Edition to be based on it.

This document is where we also said "Teams are free to define elements of their
Solutions, such as intent, deliverables, and release cadence."²

> Rawhide isn't an edition, which I think should be clear from the
> definitions above. Rawhide is sort of the primordial soup from which
> Editions and all else eventually emerges, I guess. :P

I am totally up for renaming it to Fedora Primordial Soup. :)

...

1. I'm also open to having more or fewer things that are Editions,
and finding new and better ways to let teams promote their
not-labeled-as-edition outputs.

2. Put "release cadence" in bold for the purposes of this message.

-- 
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-Rawhide-20201202.n.0 compose check report

[Fedora compose checker]

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: 11/180 (x86_64), 19/117 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20201201.n.0):

ID: 733903  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/733903
ID: 733906  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/733906
ID: 733984  Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/733984
ID: 733989  Test: aarch64 Server-dvd-iso install_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/733989
ID: 734010  Test: aarch64 Server-dvd-iso base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/734010
ID: 734146  Test: aarch64 universal install_package_set_minimal@uefi
URL: https://openqa.fedoraproject.org/tests/734146
ID: 734149  Test: aarch64 universal install_repository_http_variation@uefi
URL: https://openqa.fedoraproject.org/tests/734149

Old failures (same test failed in Fedora-Rawhide-20201201.n.0):

ID: 733899  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/733899
ID: 733900  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/733900
ID: 733907  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/733907
ID: 733914  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/733914
ID: 733915  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/733915
ID: 733951  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/733951
ID: 733967  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/733967
ID: 733988  Test: aarch64 Server-dvd-iso 
install_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/733988
ID: 734003  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/734003
ID: 734006  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/734006
ID: 734012  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/734012
ID: 734016  Test: aarch64 Server-dvd-iso server_cockpit_default@uefi
URL: https://openqa.fedoraproject.org/tests/734016
ID: 734020  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/734020
ID: 734021  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/734021
ID: 734030  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/734030
ID: 734112  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/734112
ID: 734135  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/734135
ID: 734139  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/734139
ID: 734159  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/734159
ID: 734168  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/734168
ID: 734169  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/734169
ID: 734170  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/734170
ID: 734171  Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/734171

Soft failed openQA tests: 85/180 (x86_64), 47/117 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 733936  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/733936
ID: 733974  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/733974
ID: 733976  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/733976
ID: 734045  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/734045

Old soft failures (same test soft failed in Fedora-Rawhide-20201201.n.0):

ID: 733873  Test: x86_64 

Re: Packaging chunkfs - no debug output

[Elliott Sales de Andrade]

On Wed., Dec. 2, 2020, 11:08 a.m. Richard Shaw, 
wrote:

> I'm working on packaging chunkfs for fun and curiosity. It should make
> backing up VMs or other large files with traditional backup compression and
> deduplication methods (i.e. BackupPC) easier by breaking up the file into
> chunks.
>
> It has a manual Makefile which I've patched to comply with the
> packaging guidelines, but I've run into an issue.
>
> The build respects the required build flags:
>
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o utils.o utils.c
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o unchunkfs.o unchunkfs.c
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o chunkfs.o chunkfs.c
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -s -lfuse  unchunkfs.o utils.o   -o unchunkfs
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -s -lfuse  chunkfs.o utils.o   -o chunkfs
>


This appears to be applying CFLAGS, but not LDFLAGS.


> And debuginfo runs:
>
>  /usr/lib/rpm/find-debuginfo.sh -j12 --strict-build-id -m -i
> --build-id-seed 0.8-1.fc33 --unique-debug-suffix -0.8-1.fc33.x86_64
> --unique-debug-src-base chunkfs-0.8-1.fc33.x86_64 --run-dwz
> --dwz-low-mem-die-limit 1000 --dwz-max-die-limit 11000 -S
> debugsourcefiles.list /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8
>
> But all the results are empty files:
>
> $ ll /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/*debug*
> -rw-r--r--. 1 build build 0 Dec  2 09:11
> /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debugfiles.list
> -rw-r--r--. 1 build build 0 Dec  2 09:11
> /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debuglinks.list
> -rw-r--r--. 1 build build 0 Dec  2 09:11
> /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debugsourcefiles.list
> -rw-r--r--. 1 build build 0 Dec  2 09:11
> /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debugsources.list
>
> What gives? Have it just missed something super simple?
>
> Thanks,
> Richard
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: VirtualBox pkgs for F33?

[Sérgio Basto]

On Wed, 2020-12-02 at 19:25 +0100, Nicolas Chauvet wrote:
> "Firefox does not trust koji.rpmfusion.org because its certificate
> issuer is unknown, the certificate is self-signed, or the server is
> not sending the correct intermediate certificates."

koji works with RPMFusion CA , but what this have to do with install
VirtualBox or any other package ?

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

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Adam Williamson]

On Wed, 2020-12-02 at 19:42 +0100, Clement Verna wrote:
> > 
> > CoreOS is going to be the same only worse, because it's not even built
> > the same way as the rest of Fedora. It's not built by Pungi, we don't
> > get the same messages published when CoreOS builds happen (we don't get
> > messages published at all, IIRC), the metadata for CoreOS builds is not
> > in productmd[2] form like the metadata for Pungi builds, the whole
> > process is entirely different.
> > 
> 
> Recently messages were added when streams are updated [0][1]. I believe
> that other messages could be added if needed.

Right, I forgot about that, thanks. I've got a ticket lying around here
somewhere to make something actually use them...:)
> > 
> > So to boil this down into a representative question: when we are doing
> > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
> > whether to release "Fedora CoreOS 34"?
> > 
> > 
> Fedora CoreOS 34 does not exist, you have Fedora CoreOS stable, testing and
> next, each stream is released every 2 weeks.
> The Go/No-Go is based on reports coming from each stream, next stream is
> promoted to testing and testing promoted to stable.
> If any blockers are found in next or testing the content will not be
> promoted to stable.
> 
> I think it is fairly well explained here[2]
> > 
> > What does the question "is Fedora CoreOS 34 ready to go" even mean, in
> > the context of how CoreOS is built and released? What set of bits will
> > we be deciding to ship or not ship, and how will that have been decided
> > and communicated? Where will we look to find the test results and
> > criteria on which we would base that decision?
> > 
> > 
> To maintain a fortnightly cadence there is a strong reliance on CI, every
> build is tested and results are inspected during the release process.
> Currently a release is gated on tests running on AWS, GCP and Openstack,
> these tests are running on a centos-ci jenkins instance which I think
> cannot be access without a centos account (I might be wrong), but yeah
> making these tests and results more transparent could be an improvement.

Right, but - as I think you started to recognize later in your mail -
we're sort of talking at cross-purposes here. You're talking about a
process that has been developed kind of in isolation for building and
releasing a thing which has the name "Fedora CoreOS" but doesn't
actually really integrate much at all with the processes we have for
building and releasing all the other things that make up "Fedora".

This is kind of fine as things stand because the thing with the name
"Fedora CoreOS" isn't considered to be a core fundamental part of the
thing with the name "Fedora". But this Change is about making it that.
Doing that causes all sorts of awkward impedance mismatches. Like,
saying "Fedora CoreOS 34 does not exist" is awkward, because we still
have this kind of institutional concept of a "Fedora release" which is
important to what the thing called "Fedora" is and does. To the outside
world, there is a strong impression that the thing called "Fedora" is a
product or set of products with a release number that gets released
every six months. The concept of "Fedora 33 release" or "Fedora 34
release" is a strong concept with all these sort of institutional
ripples.

If we want the thing called "Fedora CoreOS" to be a key, fundamental
component of the thing called "Fedora" - which is what making it an
"Edition" is effectively about - we have to deal with those impedance
mismatches.

So in this case, we could, for instance, make "Fedora CoreOS 34" a
'thing' by requiring that the CoreOS stable stream gets bumped at the
same time as the rest of the Fedora "release" happening. That gives us
a nice simple story that fits into our existing way of doing things.
This is more or less what we did with IoT: as things stand, the
situation with IoT is "OK, it's built from a separate compose stream,
but we still expect it to tie into the release cycle. We expect there
to be a release candidate based on the same bits as the mainline
release, with the same release number, that we sign off and release at
the same time."

Of course, that's also the drawback. If we don't want to do that, we
have to resolve the problem some other way, which is quite a
fundamental thing, if you think about it. My point here is that to do
that properly, we have to reconsider the strong idea that "Fedora is a
product that comes out every six months", which is a big job that comes
with quite a lot of consequences. It has consequences, for instance,
for our most important forms of communication to the wider world: how
do we pivot from this simple story that "Fedora is a (set of)
product(s) that come(s) out every six months, look out for our big
Fedora XX Release Announcements!" to "Fedora is that, but it's ALSO
this other thing that has three streams which release every two weeks
and roll over according to some completely other schedule"? And so on.

I'm not 

Fedora TPM1.2 Support

[Jerry Snitselaar]

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.

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

November Fedora CoreOS update for the Fedora Council

[Dusty Mabe]

The Fedora CoreOS working group periodically gives status updates to the
Fedora Council. Here's the update for this past month: 

 * Enablement work on getting the new LUKS path used in OKD
 * Informational fedora messages are now sent by the FCOS pipeline for 
integration with other services (e.g. openQA, AWS Marketplace)
 * OpenStack artifacts are now being tested on every pipeline build
 * The FCOS `testing` stream has been rebased to Fedora 33
 * Enablement work for Full disk RAID support (will land soon)
 * Reordered disk partitions in the OS image to simplify repartitioning 
with Ignition configs
 * https://github.com/coreos/fedora-coreos-tracker/issues/669
 * Added empty BIOS-BOOT partition to 4Kn image for consistency
 * Ignition [v2.8.0](https://github.com/coreos/ignition/releases/tag/v2.8.0)
 * Support unmasking systemd units
 * Zincati [v0.0.14](https://github.com/coreos/zincati/releases/tag/v0.0.14)
 * Deadend status is now shown in MOTD
 * Added documentation for Networking Configuration
 * 
https://docs.fedoraproject.org/en-US/fedora-coreos/sysconfig-network-configuration/
 * Design discussions on supporting kargs via Ignition
 * 
https://github.com/coreos/fedora-coreos-tracker/issues/318#issuecomment-724234961

Sorry for the markdown formatting. You can view it with slightly better 
formatting
at the original location, which was posted at:

https://github.com/coreos/fedora-coreos-tracker/issues/688#issuecomment-737463005

Dusty
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Jonathan Lebon]

On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa  wrote:
> This is a fair point. I've personally been very annoyed about how
> little Fedora CoreOS integrates with the rest of the Fedora Project.
> One very broken consequence of Fedora CoreOS working this way is that
> they basically *don't* participate in Changes discussions and just do
> things differently without warning or documentation. This has led to
> problems when Fedora CoreOS differs from the rest of Fedora in core,
> fundamental ways. This has even happened unintentionally, where Fedora
> CoreOS accidentally deviated from Fedora (and RHEL CoreOS!) by using
> the wrong variant of iptables:
> https://github.com/coreos/fedora-coreos-tracker/issues/676

We do look over every Fedora Changes that come through and evaluate
how we need to adapt FCOS for them. I agree we could do a better job
at providing more timely feedback to change owners and the community
(thinking about the recent rpmdb backend change for example). Part of
it I think is that we do not yet have a rawhide stream which would
expose us to all these changes earlier (it's on the radar though!).

But to be clear, the intent is always to match Fedora whenever
possible. Due to our update model, we have to be extremely careful
about these changes, and sometimes that means that FCOS lags behind a
bit in getting them. The iptables example was an unfortunate slip up;
ordinarily this would've been part of the f32 rebase just like the
rest of Fedora.

> Additionally, to the point about their tooling: there's been a bunch
> of effort to plug OSBuild based image builds into our normal
> infrastructure, and given that even Fedora IoT Edition can
> successfully be produced through that pipeline, I would think that we
> should have Fedora CoreOS transition to it. There's a lot more effort
> going around OSBuild within the project as a whole, and it's much more
> likely that we'll be able to incorporate that into the general
> infrastructure in a way that makes it traceable and actionable within
> and outside the project.

I agree build tooling is an important part of the picture. Both teams
of coreos-assembler and osbuild are aware of the overlap that exists
and we do plan to discuss this further. Though this is not something
we are likely to tackle in any serious way anytime soon. So for the
purposes of this discussion, I hope we can put this aside. We do run
our builds in CentOS CI, but we're open to integrating with Fedora
processes in any way necessary. For example, we recently added
informational fedmsgs when builds and releases happen as Clement
linked to above.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-20201202.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

Failed openQA tests: 4/15 (aarch64), 2/16 (x86_64)

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

ID: 734201  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/734201
ID: 734202  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/734202

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

ID: 734172  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/734172
ID: 734181  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/734181
ID: 734188  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/734188
ID: 734195  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/734195

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

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

ID: 734186  Test: x86_64 IoT-dvd_ostree-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/734186
ID: 734193  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/734193
ID: 734194  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/734194
ID: 734198  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/734198
ID: 734200  Test: aarch64 IoT-dvd_ostree-iso base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/734200

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
Used mem changed from 180 MiB to 159 MiB
System load changed from 0.36 to 0.15
Previous test data: https://openqa.fedoraproject.org/tests/732685#downloads
Current test data: https://openqa.fedoraproject.org/tests/734173#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
Used mem changed from 179 MiB to 158 MiB
Previous test data: https://openqa.fedoraproject.org/tests/732686#downloads
Current test data: https://openqa.fedoraproject.org/tests/734174#downloads

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

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Clement Verna]

On Wed, 2 Dec 2020 at 19:07, Ben Cotton  wrote:

> On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson
>  wrote:
> >
> > So to boil this down into a representative question: when we are doing
> > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
> > whether to release "Fedora CoreOS 34"?
> >
> This question is relevant to my interests.
>
> On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson
>  wrote:
> >
> > Note that if you go to getfedora.org and click on CoreOS *right now*,
> > it offers you a Fedora 32-based CoreOS. This is the kind of thing that
> > is kinda fine so long as it's an Emerging Edition. It would *not*,
> > IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
> > months after Fedora 34 is "released", our "stable" CoreOS is still
> > Fedora 33-based, that seems like the sort of thing that would look bad.
>
> I agree. I understand the reasoning, but I'd really like to see FCOS
> align with the rest of the schedule or at least develop a clear and
> succinct explanation of why it's delayed so that the public and the
> tech press can easily understand.
>

It is hard for something that releases every 2 weeks to align with the rest
of the schedule, we have the same struggle with the container images. It
feels odd to have to wait 6 months to introduce changes when you release a
new version every couple weeks.


>
> On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa  wrote:
> >
> > I would personally rather see Fedora CoreOS pulled *back* into the
> > fold more as an Edtion
>
> From a program management perspective, I've largely closed my eyes and
> gone "la la la" when it comes to FCOS, in part because it is so
> separate from what we know as Fedora. Making FCOS work more like what
> we know as Fedora would certainly be helpful from my perspective, but
> at the same time there are technical challenges to that. And maybe
> what FCOS does from a distro-building standpoint is more like what we
> should move toward. Maybe not.
>

> In any case, part of the work to be done here, if the Change is
> approved, is for me to figure out how to include FCOS in some of the
> program management work.
>
> I wonder if it would be better to target this for Fedora 35, with some
> of the work starting now. Given the work it took to get IoT into the
> fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34
> feels pretty optimistic here.
>

I am open to moving this to F3X but I currently don't have a clear idea of
what is required to be an Edition. If I could get a list of things that
needs to be done, that would help consider if this is doable or not.


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

[Clement Verna]

On Wed, 2 Dec 2020 at 18:27, Adam Williamson 
wrote:

> On Wed, 2020-12-02 at 09:23 -0500, Ben Cotton wrote:
> >
> > == How To Test ==
> > See QA test cases :
> https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases
> >
> > We also have regular tests days, for example
> > https://fedoramagazine.org/fedora-coreos-test-day/
>
> So...yeah, that's not really enough to call something a Fedora Edition
> :)
>
> I think this has a lot of the issues we had with IoT, but turned up to
> 11.
>
> We have an entire process for releasing a thing called "Fedora" which
> is based around the idea that all the bits that make up a "Fedora
> release" get built, tested, and signed off together.
>
> IoT stretched this process a bit, because it's not actually built as
> part of the same composes as all the other "Fedora" bits. So we had to
> implement an entire parallel validation process just for IoT composes.
> But at least it's built *the same way* as Fedora, so we could more or
> less just split existing things into two paths and use them, which is
> what we did. We now have both mainline and IoT composes and validation
> events. Even there, the process wasn't perfect for Fedora 33; if you
> look at the log of the Fedora 33 Go/No-Go meeting[1], which is supposed
> to be where we go over the status of the bits-to-be-released in great
> detail and decide whether to sign them off, there is precisely one line
> about IoT:
>
> 17:58:36  IoT is also covered -
> https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20201020.0_General#ISO_Install
>
> ...no-one else said a word about it. So yeah, we clearly don't have
> this whole "releasing from multiple streams" entirely down yet.
>
> CoreOS is going to be the same only worse, because it's not even built
> the same way as the rest of Fedora. It's not built by Pungi, we don't
> get the same messages published when CoreOS builds happen (we don't get
> messages published at all, IIRC), the metadata for CoreOS builds is not
> in productmd[2] form like the metadata for Pungi builds, the whole
> process is entirely different.
>

Recently messages were added when streams are updated [0][1]. I believe
that other messages could be added if needed.


>
> So to boil this down into a representative question: when we are doing
> the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
> whether to release "Fedora CoreOS 34"?
>
>
Fedora CoreOS 34 does not exist, you have Fedora CoreOS stable, testing and
next, each stream is released every 2 weeks.
The Go/No-Go is based on reports coming from each stream, next stream is
promoted to testing and testing promoted to stable.
If any blockers are found in next or testing the content will not be
promoted to stable.

I think it is fairly well explained here[2]


>
>
> What does the question "is Fedora CoreOS 34 ready to go" even mean, in
> the context of how CoreOS is built and released? What set of bits will
> we be deciding to ship or not ship, and how will that have been decided
> and communicated? Where will we look to find the test results and
> criteria on which we would base that decision?
>
>
To maintain a fortnightly cadence there is a strong reliance on CI, every
build is tested and results are inspected during the release process.
Currently a release is gated on tests running on AWS, GCP and Openstack,
these tests are running on a centos-ci jenkins instance which I think
cannot be access without a centos account (I might be wrong), but yeah
making these tests and results more transparent could be an improvement.


>
> Are any of these silly questions, which would indicate that our release
> process is based on assumptions which need to be fundamentally re-
> examined as part of this Change?
>

So what defines an Edition ? I think if we don't want to accept a different
philosophy about release schedule and release engineering we can just close
that Change proposal.

How do you consider Rawhide for example ?


>
> All of this is stuff we could kind of handwave so long as CoreOS wasn't
> an official Edition; we could *more or less* leave the CoreOS team to
> decide what a CoreOS release looked like and when it would happen and
> when it was good enough to ship, and so on.
>

So this change comes down to Can we have a Fedora Edition that has a
different workflow ?


> But if we're going to call it an Edition, which is one of the primary
> things that defines what Fedora *is*, I don't think we can do that any
> more. We need more groups to think about and decide on the answers to
> questions like the above.
>


[0] - https://github.com/coreos/fedora-coreos-tracker/issues/225
[1] -
https://apps.fedoraproject.org/datagrepper/id?id=2020-81657c3b-9703-431a-8c3c-0b409743fac4_raw=true=extra-large
[2] -
https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md#release-streams


> [1]:
> https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-10-22/f33-final-go_no_go-meeting.2020-10-22-17.00.log.html
> [2]: 

Fedora rawhide compose report: 20201202.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20201201.n.0
NEW: Fedora-Rawhide-20201202.n.0

= SUMMARY =
Added images:2
Dropped images:  5
Added packages:  8
Dropped packages:5
Upgraded packages:   164
Downgraded packages: 0

Size of added packages:  1.64 MiB
Size of dropped packages:85.71 MiB
Size of upgraded packages:   1.69 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Minimal raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Minimal-Rawhide-20201202.n.0.armhfp.raw.xz
Image: Minimal raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20201202.n.0.aarch64.raw.xz

= DROPPED IMAGES =
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20201201.n.0.x86_64.vagrant-virtualbox.box
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20201201.n.0.ppc64le.raw.xz
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20201201.n.0.x86_64.vagrant-libvirt.box
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20201201.n.0.ppc64le.qcow2
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20201201.n.0.ppc64le.tar.xz

= ADDED PACKAGES =
Package: lua-readline-2.7-1.fc34
Summary: Lua interface to the readline and history libraries
RPMs:lua-readline
Size:114.48 KiB

Package: pystring-1.1.3-1.fc34
Summary: Collection of C++ functions emulating Python's string class methods
RPMs:pystring pystring-devel
Size:315.56 KiB

Package: python-nbclient-0.5.1-2.fc34
Summary: A client library for executing notebooks
RPMs:python3-nbclient
Size:95.22 KiB

Package: python-nest_asyncio-1.4.3-2.fc34
Summary: Patch asyncio to allow nested event loops
RPMs:python3-nest_asyncio
Size:16.41 KiB

Package: python-pagure-messages-0.0.3-1.fc34
Summary: A schema package for messages sent by pagure
RPMs:python3-pagure-messages
Size:76.78 KiB

Package: python-pyerfa-1.7.1.1-1.fc34
Summary: Python wrapper for the ERFA library
RPMs:python3-pyerfa
Size:817.93 KiB

Package: realtime-setup-2.1-1.fc34
Summary: Setup RT/low-latency environment details
RPMs:realtime-setup
Size:112.36 KiB

Package: rust-crossterm0.17-0.17.7-1.fc34
Summary: Crossplatform terminal library for manipulating terminals
RPMs:rust-crossterm0.17+default-devel rust-crossterm0.17+event-stream-devel 
rust-crossterm0.17+futures-util-devel rust-crossterm0.17+serde-devel 
rust-crossterm0.17-devel
Size:130.18 KiB


= DROPPED PACKAGES =
Package: celt071-0.7.1-20.fc33
Summary: An audio codec for use in low-delay speech and audio communication
RPMs:celt071 celt071-devel
Size:508.36 KiB

Package: dnscap-141-19.fc33
Summary: DNS traffic capture utility
RPMs:dnscap
Size:168.04 KiB

Package: libbind-6.0-22.fc33
Summary: ISC's standard resolver library
RPMs:libbind libbind-devel
Size:1.42 MiB

Package: mingw-gtkglext-1.2.0-21.fc32
Summary: OpenGL Extension to GTK+
RPMs:mingw32-gtkglext mingw32-gtkglext-static mingw64-gtkglext 
mingw64-gtkglext-static
Size:622.19 KiB

Package: vrpn-07.33-23.fc33
Summary: The Virtual-Reality Peripheral Network
RPMs:python3-vrpn vrpn vrpn-devel vrpn-doc vrpn-java
Size:83.02 MiB


= UPGRADED PACKAGES =
Package:  FAudio-20.12-1.fc34
Old package:  FAudio-20.10-1.fc34
Summary:  FNA is a reimplementation of the Microsoft XNA Game Studio 4.0 
Refresh libraries
RPMs: libFAudio libFAudio-devel
Size: 837.86 KiB
Size change:  3.02 KiB
Changelog:
  * Tue Dec 01 2020 Michael Cronenworth  - 20.12-1
  - Update to 20.12


Package:  OpenImageIO-2.2.9.0-1.fc34
Old package:  OpenImageIO-2.2.8.0-1.fc34
Summary:  Library for reading and writing images
RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils 
python3-openimageio
Size: 20.93 MiB
Size change:  496.05 KiB
Changelog:
  * Wed Dec 02 2020 Richard Shaw  - 2.2.9.0-1
  - Update to 2.2.9.


Package:  adapt-0.3.7-1.fc34
Old package:  adapt-0.3.6-1.fc33
Summary:  Mycroft's Adapt Intent Parser
RPMs: python3-adapt
Size: 45.26 KiB
Size change:  1.63 KiB
Changelog:
  * Tue Dec 01 2020 Peter Robinson  - 0.3.7-1
  - Update to 0.3.7


Package:  adb-enhanced-2.5.7-1.fc34
Old package:  adb-enhanced-2.5.4-3.fc33
Summary:  Swiss-army knife for Android testing and development
RPMs: adb-enhanced
Size: 7.35 MiB
Size change:  1.26 KiB
Changelog:
  * Tue Dec 01 2020 Fabian Affolter  - 2.5.7-1
  - Update to latest upstream release 2.5.7 (#1898458)


Package:  annobin-9.47-1.fc34
Old package:  annobin-9.46-1.fc34
Summary:  Annotate and examine compiled binary files
RPMs: annobin annobin-annocheck
Size: 1.19 MiB

Re: Fedora 33 elections voting now open

[Ben Cotton]

This is your reminder that voting in the Fedora 33 elections remains
open through 23:59 UTC Thursday (slightly less than 30 hours from the
time I send this).

Elections results will be announced sometime on Friday.

On Wed, Nov 18, 2020 at 7:13 PM Ben Cotton  wrote:
>
> Voting in the Fedora 33 elections is now open. Go to the Elections app
> to cast[1] your vote. Voting closes at 23:59 UTC on Thursday 3
> December. Don't forget to claim your "I Voted" badge when you cast
> your ballot. Links to candidate interviews are in the Elections app
> and on the
> Community Blog[2].
>
> [1] https://elections.fedoraproject.org/
> [2] 
> https://communityblog.fedoraproject.org/fedora-33-elections-voting-now-open/

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

Re: Fedora 33 elections voting now open

[Ben Cotton]

This is your reminder that voting in the Fedora 33 elections remains
open through 23:59 UTC Thursday (slightly less than 30 hours from the
time I send this).

Elections results will be announced sometime on Friday.

On Wed, Nov 18, 2020 at 7:13 PM Ben Cotton  wrote:
>
> Voting in the Fedora 33 elections is now open. Go to the Elections app
> to cast[1] your vote. Voting closes at 23:59 UTC on Thursday 3
> December. Don't forget to claim your "I Voted" badge when you cast
> your ballot. Links to candidate interviews are in the Elections app
> and on the
> Community Blog[2].
>
> [1] https://elections.fedoraproject.org/
> [2] 
> https://communityblog.fedoraproject.org/fedora-33-elections-voting-now-open/

-- 
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: VirtualBox pkgs for F33?

[Nicolas Chauvet]

Le mer. 2 déc. 2020 à 17:18, PGNet Dev  a écrit :
>
> On 12/2/20 8:13 AM, Artem Tim wrote:
> > Vbox also available in RPM Fusion repo 
> > https://admin.rpmfusion.org/pkgdb/package/free/VirtualBox/
> > Works OK in f33.
>
> Didn't know about those -- thx.
>
> Visit to the rpmfusion site returns:
>
> "Firefox does not trust koji.rpmfusion.org because its certificate 
> issuer is unknown, the certificate is self-signed, or the server is not 
> sending the correct intermediate certificates."

This is normal as we are "stil" using our own CA for koji, but I plan
to migrate to a well known CA soon.
That been said, you are not expected to use this interface directly,
only the public mirrors...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Peter Robinson]

On Wed, Dec 2, 2020 at 5:58 PM Ben Cotton  wrote:
>
> On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson
>  wrote:
> >
> > So to boil this down into a representative question: when we are doing
> > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
> > whether to release "Fedora CoreOS 34"?
> >
> This question is relevant to my interests.
>
> On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson
>  wrote:
> >
> > Note that if you go to getfedora.org and click on CoreOS *right now*,
> > it offers you a Fedora 32-based CoreOS. This is the kind of thing that
> > is kinda fine so long as it's an Emerging Edition. It would *not*,
> > IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
> > months after Fedora 34 is "released", our "stable" CoreOS is still
> > Fedora 33-based, that seems like the sort of thing that would look bad.
>
> I agree. I understand the reasoning, but I'd really like to see FCOS
> align with the rest of the schedule or at least develop a clear and
> succinct explanation of why it's delayed so that the public and the
> tech press can easily understand.
>
> On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa  wrote:
> >
> > I would personally rather see Fedora CoreOS pulled *back* into the
> > fold more as an Edtion
>
> From a program management perspective, I've largely closed my eyes and
> gone "la la la" when it comes to FCOS, in part because it is so
> separate from what we know as Fedora. Making FCOS work more like what
> we know as Fedora would certainly be helpful from my perspective, but
> at the same time there are technical challenges to that. And maybe
> what FCOS does from a distro-building standpoint is more like what we
> should move toward. Maybe not.
>
> In any case, part of the work to be done here, if the Change is
> approved, is for me to figure out how to include FCOS in some of the
> program management work.
>
> I wonder if it would be better to target this for Fedora 35, with some
> of the work starting now. Given the work it took to get IoT into the
> fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34
> feels pretty optimistic here.

From memory we started in IoT Edition process in earnest in F-32, part
of the delay here was because there had never really been the process
properly defined for promotion, but it took some time and engagement
across a number of areas of the project which I feel were useful for
the IoT Edition, overall starting the discussion for what's required
and expected is useful for the Edition themselves to improve and work
in the right direction IMO from experience.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 34 Change: Ruby 3.0 (System-Wide Change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Ruby_3.0

== Summary ==
Ruby 3.0 is the latest stable version of Ruby. Many new features and
improvements are included for the increasingly diverse and expanding
demands for Ruby. With this major update from Ruby 2.7 in Fedora 33 to
Ruby 3.0 in Fedora 34, Fedora becomes the superior Ruby development
platform.

== Owner ==
* Name: [[User:vondruch| Vít Ondruch]], [[User:pvalena| Pavel Valena]]
* Email: vondr...@redhat.com, pval...@redhat.com


== Detailed Description ==


Ruby 3.0 is upstream's new major release of Ruby. Many new features
and improvements are included.

=== RBS ===

RBS is a language to describe the types of Ruby programs. Type
checkers including type-profiler and other tools supporting RBS will
understand Ruby programs much better with RBS definitions.

You can write down the definition of classes and modules: methods
defined in the class, instance variables and their types, and
inheritance/mix-in relations. The goal of RBS is to support commonly
seen patterns in Ruby programs and it allows writing advanced types
including union types, method overloading, and generics. It also
supports duck typing with interface types.

Ruby 3.0 ships with `rbs` gem, which allows parsing and processing
type definitions written in RBS.

=== Ractor (experimental) ===

Ractor is an Actor-model like concurrent abstraction designed to
provide a parallel execution feature without thread-safety concerns.

You can make multiple ractors and you can run them in parallel. Ractor
enables to make thread-safe parallel programs because ractors can not
share normal objects. Communication between ractors are supported by
message passing.

To limit sharing objects, Ractor introduces several restrictions to
the Ruby’s syntax (without multiple Ractors, there is no changes).

The specification and implementation are not matured and changed in
future, so this feature is marked as experimental and show the
experimental feature warning if Ractor is created.

=== Scheduler (Experimental) ===

`Thread#scheduler` is introduced for intercepting blocking operations.
This allows for light-weight concurrency without changing existing
code.

CAUTION: This feature is strongly experimental. Both the name and
feature will change in next preview release.

=== Other Notable New Features ===

* Rightward assignment statement is added.
* Endless method definition is added.
* Find pattern is added.
* `Hash#except` is now built-in.
* Memory view is added as an experimental feature

=== Performance improvements ===

Many improvements were implemented in MJIT.

=== Other notable changes since 2.7 ===

* Keyword arguments are separated from other arguments.
* The feature of `$SAFE` was completely removed; now it is a normal
global variable.
* The order of backtrace had been reversed at Ruby 2.5, but it was
cancelled. Now it behaves like Ruby 2.4; an error message and the line
number where the exception occurs are printed first, and its callers
are printed later.
* Some standard libraries are updated.

== Benefit to Fedora ==
With a latest release, Ruby language is supporting the newest language
features, which enables even faster and easier development of Ruby
applications.

== Scope ==
* Proposal owners:
** Finish packaging of Ruby 3.0. Current changes available in PR
https://src.fedoraproject.org/rpms/ruby/pull-request/70
** Rebuilding of Ruby packages providing native extensions (i.e.
packages which depends on libruby).

* Other developers:
** Rebuild of packages with binary extensions (i.e. packages which
depends on libruby) will be handled automatically, but some packages
might need fixes/updates to support Ruby 3.0 properly.

* Release engineering: [https://pagure.io/releng/issue/9882 #9882] (a
check of an impact with Release Engineering is needed)
** The packages are going to be rebuild in side-tag, but that does not
need releng involvement nowadays.

* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==
* User specific Ruby binary extensions need to be rebuild.

== How To Test ==
* No special hardware is needed.
* To test, install Ruby 3.0. The test builds are pusblished in PR or
on Ruby-SIG ML
* Try to locally rebuild your packages using Ruby 3.0.
* Use the packages with your applications previously written in Ruby.
* If something doesn't work as it should, let us know.

== User Experience ==
The Ruby programs/scripts should behave as they were used to.

== Dependencies ==

$ dnf repoquery --disablerepo=* --enablerepo=rawhide
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' |
sort | uniq | wc -l
138


== Contingency Plan ==
* Contingency mechanism: We would like to get a special buildroot tag
to be able to rebuild necessary the packages with Ruby 3.0. If
anything goes wrong, the tag could be easily dropped and previous
version of Ruby 2.7 and its dependencies 

Fedora 34 Change: Ruby 3.0 (System-Wide Change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Ruby_3.0

== Summary ==
Ruby 3.0 is the latest stable version of Ruby. Many new features and
improvements are included for the increasingly diverse and expanding
demands for Ruby. With this major update from Ruby 2.7 in Fedora 33 to
Ruby 3.0 in Fedora 34, Fedora becomes the superior Ruby development
platform.

== Owner ==
* Name: [[User:vondruch| Vít Ondruch]], [[User:pvalena| Pavel Valena]]
* Email: vondr...@redhat.com, pval...@redhat.com


== Detailed Description ==


Ruby 3.0 is upstream's new major release of Ruby. Many new features
and improvements are included.

=== RBS ===

RBS is a language to describe the types of Ruby programs. Type
checkers including type-profiler and other tools supporting RBS will
understand Ruby programs much better with RBS definitions.

You can write down the definition of classes and modules: methods
defined in the class, instance variables and their types, and
inheritance/mix-in relations. The goal of RBS is to support commonly
seen patterns in Ruby programs and it allows writing advanced types
including union types, method overloading, and generics. It also
supports duck typing with interface types.

Ruby 3.0 ships with `rbs` gem, which allows parsing and processing
type definitions written in RBS.

=== Ractor (experimental) ===

Ractor is an Actor-model like concurrent abstraction designed to
provide a parallel execution feature without thread-safety concerns.

You can make multiple ractors and you can run them in parallel. Ractor
enables to make thread-safe parallel programs because ractors can not
share normal objects. Communication between ractors are supported by
message passing.

To limit sharing objects, Ractor introduces several restrictions to
the Ruby’s syntax (without multiple Ractors, there is no changes).

The specification and implementation are not matured and changed in
future, so this feature is marked as experimental and show the
experimental feature warning if Ractor is created.

=== Scheduler (Experimental) ===

`Thread#scheduler` is introduced for intercepting blocking operations.
This allows for light-weight concurrency without changing existing
code.

CAUTION: This feature is strongly experimental. Both the name and
feature will change in next preview release.

=== Other Notable New Features ===

* Rightward assignment statement is added.
* Endless method definition is added.
* Find pattern is added.
* `Hash#except` is now built-in.
* Memory view is added as an experimental feature

=== Performance improvements ===

Many improvements were implemented in MJIT.

=== Other notable changes since 2.7 ===

* Keyword arguments are separated from other arguments.
* The feature of `$SAFE` was completely removed; now it is a normal
global variable.
* The order of backtrace had been reversed at Ruby 2.5, but it was
cancelled. Now it behaves like Ruby 2.4; an error message and the line
number where the exception occurs are printed first, and its callers
are printed later.
* Some standard libraries are updated.

== Benefit to Fedora ==
With a latest release, Ruby language is supporting the newest language
features, which enables even faster and easier development of Ruby
applications.

== Scope ==
* Proposal owners:
** Finish packaging of Ruby 3.0. Current changes available in PR
https://src.fedoraproject.org/rpms/ruby/pull-request/70
** Rebuilding of Ruby packages providing native extensions (i.e.
packages which depends on libruby).

* Other developers:
** Rebuild of packages with binary extensions (i.e. packages which
depends on libruby) will be handled automatically, but some packages
might need fixes/updates to support Ruby 3.0 properly.

* Release engineering: [https://pagure.io/releng/issue/9882 #9882] (a
check of an impact with Release Engineering is needed)
** The packages are going to be rebuild in side-tag, but that does not
need releng involvement nowadays.

* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==
* User specific Ruby binary extensions need to be rebuild.

== How To Test ==
* No special hardware is needed.
* To test, install Ruby 3.0. The test builds are pusblished in PR or
on Ruby-SIG ML
* Try to locally rebuild your packages using Ruby 3.0.
* Use the packages with your applications previously written in Ruby.
* If something doesn't work as it should, let us know.

== User Experience ==
The Ruby programs/scripts should behave as they were used to.

== Dependencies ==

$ dnf repoquery --disablerepo=* --enablerepo=rawhide
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' |
sort | uniq | wc -l
138


== Contingency Plan ==
* Contingency mechanism: We would like to get a special buildroot tag
to be able to rebuild necessary the packages with Ruby 3.0. If
anything goes wrong, the tag could be easily dropped and previous
version of Ruby 2.7 and its dependencies 

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Neal Gompa]

On Wed, Dec 2, 2020 at 12:58 PM Ben Cotton  wrote:
>
> On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson
>  wrote:
> >
> > So to boil this down into a representative question: when we are doing
> > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
> > whether to release "Fedora CoreOS 34"?
> >
> This question is relevant to my interests.
>
> On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson
>  wrote:
> >
> > Note that if you go to getfedora.org and click on CoreOS *right now*,
> > it offers you a Fedora 32-based CoreOS. This is the kind of thing that
> > is kinda fine so long as it's an Emerging Edition. It would *not*,
> > IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
> > months after Fedora 34 is "released", our "stable" CoreOS is still
> > Fedora 33-based, that seems like the sort of thing that would look bad.
>
> I agree. I understand the reasoning, but I'd really like to see FCOS
> align with the rest of the schedule or at least develop a clear and
> succinct explanation of why it's delayed so that the public and the
> tech press can easily understand.
>

I would probably suggest that they *must* make it so they can rebase
and release to a new stable release when the rest of the platform
does. If they want to make releases faster (a la Fedora Cloud), that's
fine. But being slower is not acceptable, IMHO.

> On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa  wrote:
> >
> > I would personally rather see Fedora CoreOS pulled *back* into the
> > fold more as an Edtion
>
> From a program management perspective, I've largely closed my eyes and
> gone "la la la" when it comes to FCOS, in part because it is so
> separate from what we know as Fedora. Making FCOS work more like what
> we know as Fedora would certainly be helpful from my perspective, but
> at the same time there are technical challenges to that. And maybe
> what FCOS does from a distro-building standpoint is more like what we
> should move toward. Maybe not.
>
> In any case, part of the work to be done here, if the Change is
> approved, is for me to figure out how to include FCOS in some of the
> program management work.
>
> I wonder if it would be better to target this for Fedora 35, with some
> of the work starting now. Given the work it took to get IoT into the
> fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34
> feels pretty optimistic here.

I suspect that you're right and this should be retargeted for Fedora 35.



-- 
真実はいつも一つ！/ 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 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Ben Cotton]

On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson
 wrote:
>
> So to boil this down into a representative question: when we are doing
> the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
> whether to release "Fedora CoreOS 34"?
>
This question is relevant to my interests.

On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson
 wrote:
>
> Note that if you go to getfedora.org and click on CoreOS *right now*,
> it offers you a Fedora 32-based CoreOS. This is the kind of thing that
> is kinda fine so long as it's an Emerging Edition. It would *not*,
> IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
> months after Fedora 34 is "released", our "stable" CoreOS is still
> Fedora 33-based, that seems like the sort of thing that would look bad.

I agree. I understand the reasoning, but I'd really like to see FCOS
align with the rest of the schedule or at least develop a clear and
succinct explanation of why it's delayed so that the public and the
tech press can easily understand.

On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa  wrote:
>
> I would personally rather see Fedora CoreOS pulled *back* into the
> fold more as an Edtion

From a program management perspective, I've largely closed my eyes and
gone "la la la" when it comes to FCOS, in part because it is so
separate from what we know as Fedora. Making FCOS work more like what
we know as Fedora would certainly be helpful from my perspective, but
at the same time there are technical challenges to that. And maybe
what FCOS does from a distro-building standpoint is more like what we
should move toward. Maybe not.

In any case, part of the work to be done here, if the Change is
approved, is for me to figure out how to include FCOS in some of the
program management work.

I wonder if it would be better to target this for Fedora 35, with some
of the work starting now. Given the work it took to get IoT into the
fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34
feels pretty optimistic here.

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

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

[Ben Cotton]

On Wed, 2020-12-02 at 11:14 -0500, Neal Gompa wrote:

> There were a number of people interested in helping with reviving the
> Server WG, myself included. But we don't know how to have that move
> forward. We've never really had a situation like this before...
>
I'd start with staging a takeover of https://fedoraproject.org/wiki/Server

It looks like there are no meeting logs in the last two years, so I
don't think you'll get much pushback.

I talked to sgallagh before posing this question, so I don't expect
you'll get any pushback. If anything, you'll probably make people
happy. :-)

On Wed, Dec 2, 2020 at 12:30 PM Adam Williamson
 wrote:
>
> I'm not sure it's really warranted, to be honest. A counterpoint is
> that you can consider Server to be sort of dormant *because it works*.

Is "it still works" sufficient to keep a deliverable at the forefront?
Obviously we want what we ship to work, whether it's an Edition or
bex's Llama Herder Lab. But what is Server doing to move the state of
the art forward? Server is a slightly different case in that generally
you don't want servers to be too adventurous, but if it's in statis,
should it be a flagship?

Like I said above, the Server WG appears to be in zombie state for at
least the last two years. Is Fedora Server doing what it should be
doing now, or is it doing what it should have done two years ago?

> Of course, we can keep publishing Server images and providing those
> capabilities without calling it an Edition, but...I'm not sure it just
> being sort of quiet and undramatic necessarily merits that, especially
> if we don't have clear replacements for its capabilities yet.

I'm certainly not advocating we drop Server entirely. But we should
evaluate its place in Fedora, particularly if there's no one providing
active care and feeding. I'd much rather see the Server WG come back
to life and keep it as an Edition.

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

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Adam Williamson]

On Wed, 2020-12-02 at 09:56 -0500, Neal Gompa wrote:
> 
> Meh, sure I guess? This is a paperwork change. It's been considered an
> Edition in practice since it replaced Fedora Atomic, which *was* a
> full Edition in its own right.

I would dispute that. To me the most obvious factor here is: what do
you see when you go to download Fedora? What you see is this:

https://getfedora.org/

which is very clear that the Editions - the primary Fedora Things - are
Workstation, Server and IoT. CoreOS and Silverblue are clearly labeled
"Emerging Fedora Editions", which clearly communicates to people "these
are things we consider important but aren't ready to make the Main
Things" yet - they are, as the subhead says, "the future of Fedora".
This is admirably clear messaging, I think, and it means that people
will give us a pass on all the sorts of awkward questions I asked in my
other mail.

If CoreOS moves up a few hundred pixels, we will *not* get a pass on
those questions. If we release a bad CoreOS, it will reflect badly on
Fedora. If we do a "Fedora release" and just basically forget to
include CoreOS in the messaging for that release at all, that will look
bad.

Note that if you go to getfedora.org and click on CoreOS *right now*,
it offers you a Fedora 32-based CoreOS. This is the kind of thing that
is kinda fine so long as it's an Emerging Edition. It would *not*,
IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
months after Fedora 34 is "released", our "stable" CoreOS is still
Fedora 33-based, that seems like the sort of thing that would look bad.
-- 
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: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Neal Gompa]

On Wed, Dec 2, 2020 at 12:19 PM Adam Williamson
 wrote:
>
> On Wed, 2020-12-02 at 09:23 -0500, Ben Cotton wrote:
> >
> > == How To Test ==
> > See QA test cases : 
> > https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases
> >
> > We also have regular tests days, for example
> > https://fedoramagazine.org/fedora-coreos-test-day/
>
> So...yeah, that's not really enough to call something a Fedora Edition
> :)
>
> I think this has a lot of the issues we had with IoT, but turned up to
> 11.
>
> We have an entire process for releasing a thing called "Fedora" which
> is based around the idea that all the bits that make up a "Fedora
> release" get built, tested, and signed off together.
>
> IoT stretched this process a bit, because it's not actually built as
> part of the same composes as all the other "Fedora" bits. So we had to
> implement an entire parallel validation process just for IoT composes.
> But at least it's built *the same way* as Fedora, so we could more or
> less just split existing things into two paths and use them, which is
> what we did. We now have both mainline and IoT composes and validation
> events. Even there, the process wasn't perfect for Fedora 33; if you
> look at the log of the Fedora 33 Go/No-Go meeting[1], which is supposed
> to be where we go over the status of the bits-to-be-released in great
> detail and decide whether to sign them off, there is precisely one line
> about IoT:
>
> 17:58:36  IoT is also covered - 
> https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20201020.0_General#ISO_Install
>
> ...no-one else said a word about it. So yeah, we clearly don't have
> this whole "releasing from multiple streams" entirely down yet.
>
> CoreOS is going to be the same only worse, because it's not even built
> the same way as the rest of Fedora. It's not built by Pungi, we don't
> get the same messages published when CoreOS builds happen (we don't get
> messages published at all, IIRC), the metadata for CoreOS builds is not
> in productmd[2] form like the metadata for Pungi builds, the whole
> process is entirely different.
>
> So to boil this down into a representative question: when we are doing
> the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
> whether to release "Fedora CoreOS 34"?
>
> What does the question "is Fedora CoreOS 34 ready to go" even mean, in
> the context of how CoreOS is built and released? What set of bits will
> we be deciding to ship or not ship, and how will that have been decided
> and communicated? Where will we look to find the test results and
> criteria on which we would base that decision?
>
> Are any of these silly questions, which would indicate that our release
> process is based on assumptions which need to be fundamentally re-
> examined as part of this Change?
>
> All of this is stuff we could kind of handwave so long as CoreOS wasn't
> an official Edition; we could *more or less* leave the CoreOS team to
> decide what a CoreOS release looked like and when it would happen and
> when it was good enough to ship, and so on.
>
> But if we're going to call it an Edition, which is one of the primary
> things that defines what Fedora *is*, I don't think we can do that any
> more. We need more groups to think about and decide on the answers to
> questions like the above.
>
> [1]: 
> https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-10-22/f33-final-go_no_go-meeting.2020-10-22-17.00.log.html
> [2]: https://github.com/release-engineering/productmd

This is a fair point. I've personally been very annoyed about how
little Fedora CoreOS integrates with the rest of the Fedora Project.
One very broken consequence of Fedora CoreOS working this way is that
they basically *don't* participate in Changes discussions and just do
things differently without warning or documentation. This has led to
problems when Fedora CoreOS differs from the rest of Fedora in core,
fundamental ways. This has even happened unintentionally, where Fedora
CoreOS accidentally deviated from Fedora (and RHEL CoreOS!) by using
the wrong variant of iptables:
https://github.com/coreos/fedora-coreos-tracker/issues/676

Additionally, to the point about their tooling: there's been a bunch
of effort to plug OSBuild based image builds into our normal
infrastructure, and given that even Fedora IoT Edition can
successfully be produced through that pipeline, I would think that we
should have Fedora CoreOS transition to it. There's a lot more effort
going around OSBuild within the project as a whole, and it's much more
likely that we'll be able to incorporate that into the general
infrastructure in a way that makes it traceable and actionable within
and outside the project.

I would personally rather see Fedora CoreOS pulled *back* into the
fold more as an Edtion.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 

Re: Request for advice on KiCAD appdata

[Richard Hughes]

On Wed, 2 Dec 2020 at 16:13, Steven A. Falco  wrote:
> There is a bug report [1] that KiCAD doesn't show up in the GNOME Software or 
> KDE Discover managers.  I ran desktop-file-validate on the kicad.desktop file 
> and got a hint that there is no registered main category.

That just means it's not going to show up in the category view.

> Is this something that happens during a compose?  How can I test to see if my 
> change is effective?

If you have the metainfo.xml file handy you can run "appstream-util
validate foo.xml" and if you only have the .rpm you can do
"appstream-builder --verbose *.rpm" and see what the log files say.

I hope that helps,

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

Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Adam Williamson]

On Wed, 2020-12-02 at 11:14 -0500, Neal Gompa wrote:
> On Wed, Dec 2, 2020 at 11:11 AM Ben Cotton  wrote:
> > 
> > One uncomfortable question that this raises: is it time to de-Edition
> > Fedora Server? We'd still produce it, but it would no longer be
> > considered an Edition (and thus potentially not block releases, etc,
> > the exact implications would have to be worked out)
> > 
> > As far as I can tell, the Server Working Group has essentially been
> > dormant for a while, with sgallagh coming in to fix issues when they
> > arise. So one alternative to demoting Server would be for someone to
> > revive that WG.
> > 
> > Fedora CoreOS is not an exact replacement for Fedora Server, of
> > course, but this does present what feels like a natural opportunity to
> > ask this question.
> > 
> 
> There were a number of people interested in helping with reviving the
> Server WG, myself included. But we don't know how to have that move
> forward. We've never really had a situation like this before...

I'm not sure it's really warranted, to be honest. A counterpoint is
that you can consider Server to be sort of dormant *because it works*.
We have a defined set of capabilities for Fedora Server, testing of
them is almost entirely automated, and our releases keep providing
those capabilities reliably. We have a couple of representative boring-
server-things that Server is required to be able to do well: being a
database server, and being a FreeIPA server. We have decent automated
tests for those, and when they break, people jump on them and fix them.
All our Fedora Server releases have met them pretty well. People run it
and are happy.

CoreOS can be a database server too, of course. I could set things up
to run those tests for CoreOS builds, I guess. I'm not sure it can be a
FreeIPA server, or if anyone's even tried.

Of course, we can keep publishing Server images and providing those
capabilities without calling it an Edition, but...I'm not sure it just
being sort of quiet and undramatic necessarily merits that, especially
if we don't have clear replacements for its capabilities yet.
-- 
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: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Adam Williamson]

On Wed, 2020-12-02 at 09:23 -0500, Ben Cotton wrote:
> 
> == How To Test ==
> See QA test cases : https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases
> 
> We also have regular tests days, for example
> https://fedoramagazine.org/fedora-coreos-test-day/

So...yeah, that's not really enough to call something a Fedora Edition
:)

I think this has a lot of the issues we had with IoT, but turned up to
11.

We have an entire process for releasing a thing called "Fedora" which
is based around the idea that all the bits that make up a "Fedora
release" get built, tested, and signed off together.

IoT stretched this process a bit, because it's not actually built as
part of the same composes as all the other "Fedora" bits. So we had to
implement an entire parallel validation process just for IoT composes.
But at least it's built *the same way* as Fedora, so we could more or
less just split existing things into two paths and use them, which is
what we did. We now have both mainline and IoT composes and validation
events. Even there, the process wasn't perfect for Fedora 33; if you
look at the log of the Fedora 33 Go/No-Go meeting[1], which is supposed
to be where we go over the status of the bits-to-be-released in great
detail and decide whether to sign them off, there is precisely one line
about IoT:

17:58:36  IoT is also covered - 
https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20201020.0_General#ISO_Install

...no-one else said a word about it. So yeah, we clearly don't have
this whole "releasing from multiple streams" entirely down yet.

CoreOS is going to be the same only worse, because it's not even built
the same way as the rest of Fedora. It's not built by Pungi, we don't
get the same messages published when CoreOS builds happen (we don't get
messages published at all, IIRC), the metadata for CoreOS builds is not
in productmd[2] form like the metadata for Pungi builds, the whole
process is entirely different.

So to boil this down into a representative question: when we are doing
the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
whether to release "Fedora CoreOS 34"?

What does the question "is Fedora CoreOS 34 ready to go" even mean, in
the context of how CoreOS is built and released? What set of bits will
we be deciding to ship or not ship, and how will that have been decided
and communicated? Where will we look to find the test results and
criteria on which we would base that decision?

Are any of these silly questions, which would indicate that our release
process is based on assumptions which need to be fundamentally re-
examined as part of this Change?

All of this is stuff we could kind of handwave so long as CoreOS wasn't
an official Edition; we could *more or less* leave the CoreOS team to
decide what a CoreOS release looked like and when it would happen and
when it was good enough to ship, and so on.

But if we're going to call it an Edition, which is one of the primary
things that defines what Fedora *is*, I don't think we can do that any
more. We need more groups to think about and decide on the answers to
questions like the above.

[1]: 
https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-10-22/f33-final-go_no_go-meeting.2020-10-22-17.00.log.html
[2]: https://github.com/release-engineering/productmd
-- 
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: VirtualBox pkgs for F33?

[Sérgio Basto]

On Wed, 2020-12-02 at 16:14 +, Artem Tim wrote:
> https://rpmfusion.org/Howto/VirtualBox


I just update wiki , please report in RPMFusion [1] when kmods doesn't
build or package not install or if we can improve wiki page.
BTW we still haven't patches for next upcoming kernel 4.10 .

But errors that happens in all VirtualBox flavors (problems not related
to packaging), please report it on VirtualBox site because we can't do
nothing but report there.

Thanks


[1]
https://bugzilla.rpmfusion.org/enter_bug.cgi?product=Fedora=VirtualBox-kmod=rawhide
 

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

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

[Vít Ondruch]

Dne 02. 12. 20 v 14:18 Neal Gompa napsal(a):

On Wed, Dec 2, 2020 at 8:14 AM Olivier Fourdan  wrote:

Hi Dominik,

On Wed, Dec 2, 2020 at 2:02 PM Dominik 'Rathann' Mierzejewski 
 wrote:


Provides: xorg-x11-server-Xwayland = %{version}-%{release}
Obsoletes: xorg-x11-server-Xwayland < first-version-built-from-new-upstream

https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages


The package in the COPR [1] does:

Provides:  xorg-x11-server-Xwayland = %{version}-%{release}
Provides:  xorg-x11-server-Xwayland%{?_isa}
Obsoletes: xorg-x11-server-Xwayland < %{version}-%{release}

For some reason, dnf would complain when upgrading from the original 
xorg-x11-server-Xwayland otherwise.

But anyhow, the original question from Vít was not really how to achieve it, 
but rather what name we want for that package.



Right, that was intent of my question.



I think that unless it's actually being split out from upstream
sources from the xorg-server repo, it would just be easier to call it
xorg-x11-server-Xwayland.



That was also my thought. I was just curious if this was considered, 
because both approaches have some pros/cons. But I don't think I have 
preference.




  But if you're dead set on renaming it, you
need to do it like so:

Obsoletes: xorg-x11-server-Xwayland < %{version}-%{release}
Provides:  xorg-x11-server-Xwayland = %{version}-%{release}
Provides:  xorg-x11-server-Xwayland%{?_isa} = %{version}-%{release}

The archful Provides needs to be versioned too.




Glad that my curiosity brings also other fruit, because I think Neal is 
right here ;)



Vít



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: External (non-rpm) BuidRequires - was New Mock release v2.7

[Vít Ondruch]

Dne 02. 12. 20 v 8:00 Miroslav Suchý napsal(a):

Dne 01. 12. 20 v 13:07 Pavel Raiskup napsal(a):

I'm pleased to announce that there's a new Mock release.  Except for
several bugfixes, this release introduces a new
"External Build Requires" feature (by Miroslav Suchý)

I want to ask you for feedback on this feature.
   https://github.com/rpm-software-management/mock/wiki/Feature-external-deps

This feature will allow you to use in SPEC file
   BuildRequires: external:pypi:foo



Why these requires does not follow some standard naming convention 
possibly with some prefix?


And actually wouldn't it be better to use some conditional dependency? 
One idea which comes to my mind is something like:



~~~

BuildRequires: python3-foo or external:python3-foo

~~~


The other is to use these BRs just if some specific provide is available:


~~~

BuildRequires: external:pypi:foo if 
some-package-providing-or-enabling-support-of-this-is-available


~~~


Vít



which will run
pip3 --install foo
in the buildroot.

This is a new and experimental feature. Not yet enabled in Mock by default. And 
I do **not** expect that it will be
enabled in Fedora. Ever. It may be enabled in Copr one day. The primary 
audience is 3rd party packagers who need some
library for building, and it is not available as RPM.

I am aware that this is breaking some fundamentals of RPM. For this reason, I 
want to hear the feedback on whether this
is interesting for you or it should die in agony.

Right now, this feature supports PyPI - I am confident there. I also added 
Crate (Rust) support. But I do not use Rust;
therefore, it is very likely that it will need fixes.

I will welcome if you can guide me on how to add support for another language. 
There are two requirements. The native
package manager needs to be available in Fedora. And the manager has to have 
--root or something similar, which lets you
install the files in the different root path. That is because we run this tool 
in bootstrap chroot.

In case you want to send PR, the code is here:

https://github.com/rpm-software-management/mock/blob/d58dc2a87f6327ec563d2d7d63920c04f0315ba4/mock/py/mockbuild/external.py#L32



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: VirtualBox pkgs for F33?

[PGNet Dev]

On 12/2/20 8:13 AM, Artem Tim wrote:

Vbox also available in RPM Fusion repo 
https://admin.rpmfusion.org/pkgdb/package/free/VirtualBox/
Works OK in f33.


Didn't know about those -- thx.

Visit to the rpmfusion site returns:

"Firefox does not trust koji.rpmfusion.org because its certificate issuer is 
unknown, the certificate is self-signed, or the server is not sending the correct 
intermediate certificates."


Normal state of affairs?  New issue?  Poking around now ...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Neal Gompa]

On Wed, Dec 2, 2020 at 11:11 AM Ben Cotton  wrote:
>
> One uncomfortable question that this raises: is it time to de-Edition
> Fedora Server? We'd still produce it, but it would no longer be
> considered an Edition (and thus potentially not block releases, etc,
> the exact implications would have to be worked out)
>
> As far as I can tell, the Server Working Group has essentially been
> dormant for a while, with sgallagh coming in to fix issues when they
> arise. So one alternative to demoting Server would be for someone to
> revive that WG.
>
> Fedora CoreOS is not an exact replacement for Fedora Server, of
> course, but this does present what feels like a natural opportunity to
> ask this question.
>

There were a number of people interested in helping with reviving the
Server WG, myself included. But we don't know how to have that move
forward. We've never really had a situation like this before...



-- 
真実はいつも一つ！/ 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: VirtualBox pkgs for F33?

[Artem Tim]

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

Request for advice on KiCAD appdata

[Steven A. Falco]

There is a bug report [1] that KiCAD doesn't show up in the GNOME Software or 
KDE Discover managers.  I ran desktop-file-validate on the kicad.desktop file 
and got a hint that there is no registered main category.

I'll try adding "Science" to the category list, but I'm unclear on how this 
data gets into the package manager before the package has even been installed.

Is this something that happens during a compose?  How can I test to see if my 
change is effective?

Steve

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1903576
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: VirtualBox pkgs for F33?

[Artem Tim]

Vbox also available in RPM Fusion repo 
https://admin.rpmfusion.org/pkgdb/package/free/VirtualBox/
Works OK in f33.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Ben Cotton]

One uncomfortable question that this raises: is it time to de-Edition
Fedora Server? We'd still produce it, but it would no longer be
considered an Edition (and thus potentially not block releases, etc,
the exact implications would have to be worked out)

As far as I can tell, the Server Working Group has essentially been
dormant for a while, with sgallagh coming in to fix issues when they
arise. So one alternative to demoting Server would be for someone to
revive that WG.

Fedora CoreOS is not an exact replacement for Fedora Server, of
course, but this does present what feels like a natural opportunity to
ask this question.

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

Re: Delay service startup but only on boot

[Richard Shaw]

On Wed, Dec 2, 2020 at 10:02 AM Lennart Poettering 
wrote:

> On Mi, 02.12.20 09:56, Richard Shaw (hobbes1...@gmail.com) wrote:
>
> > I've got a SystemD service file that starts a service, the problem is it
> > connects to another device that takes longer to boot up into a "ready"
> > state than the computer with the service.
> >
> > I could just add a "ExecStartPre=/usr/bin/sleep 30" to the service file,
> > but will it delay for 30 seconds on restarts as well? I only want it to
> > wait on cold boots.
> >
> > I may be better off creating a timer unit file and using OnBootSec but
> > didn't want to go with the complexity of a timer if I didn't have to.
>
> That's more of a question for the systemd mailing list, rather than
> the Fedora ML.
>

I figured there were enough experts here, I need to be subscribed to
another mailing list like I need another hole in my head :)



> That said, what kind of device is it? Is it shown among the devices
> "systemctl -t device" shows? If so, just add
>

Nope, it's an external networked device. They always "boot up" at the same
time, but the computer which runs the service boots up faster than the
device I need to connect to.

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

Packaging chunkfs - no debug output

[Richard Shaw]

I'm working on packaging chunkfs for fun and curiosity. It should make
backing up VMs or other large files with traditional backup compression and
deduplication methods (i.e. BackupPC) easier by breaking up the file into
chunks.

It has a manual Makefile which I've patched to comply with the
packaging guidelines, but I've run into an issue.

The build respects the required build flags:

gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o utils.o utils.c
gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o unchunkfs.o unchunkfs.c
gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o chunkfs.o chunkfs.c
gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -s -lfuse  unchunkfs.o utils.o   -o unchunkfs
gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -s -lfuse  chunkfs.o utils.o   -o chunkfs

And debuginfo runs:

 /usr/lib/rpm/find-debuginfo.sh -j12 --strict-build-id -m -i
--build-id-seed 0.8-1.fc33 --unique-debug-suffix -0.8-1.fc33.x86_64
--unique-debug-src-base chunkfs-0.8-1.fc33.x86_64 --run-dwz
--dwz-low-mem-die-limit 1000 --dwz-max-die-limit 11000 -S
debugsourcefiles.list /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8

But all the results are empty files:

$ ll /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/*debug*
-rw-r--r--. 1 build build 0 Dec  2 09:11
/tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debugfiles.list
-rw-r--r--. 1 build build 0 Dec  2 09:11
/tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debuglinks.list
-rw-r--r--. 1 build build 0 Dec  2 09:11
/tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debugsourcefiles.list
-rw-r--r--. 1 build build 0 Dec  2 09:11
/tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debugsources.list

What gives? Have it just missed something super simple?

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

VirtualBox pkgs for F33?

[PGNet Dev]

Is there an available/alternative option for VirtualBox repo installs on F33?

Currently,

http://download.virtualbox.org/virtualbox/rpm/fedora/

has only up to F32.

This thread

https://forums.virtualbox.org/viewtopic.php?f=7=100418

is the latest info I've found; atm, no pkgs, no timeline, and a 
Fedora+PulseAudio bug.

Yes, DIY via shellscript install is, apparently, do-able ...

I'm asking re: DNF-installable F33 packages, for end-users that would like to 
upgrade F32->F33
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Delay service startup but only on boot

[Lennart Poettering]

On Mi, 02.12.20 09:56, Richard Shaw (hobbes1...@gmail.com) wrote:

> I've got a SystemD service file that starts a service, the problem is it
> connects to another device that takes longer to boot up into a "ready"
> state than the computer with the service.
>
> I could just add a "ExecStartPre=/usr/bin/sleep 30" to the service file,
> but will it delay for 30 seconds on restarts as well? I only want it to
> wait on cold boots.
>
> I may be better off creating a timer unit file and using OnBootSec but
> didn't want to go with the complexity of a timer if I didn't have to.

That's more of a question for the systemd mailing list, rather than
the Fedora ML.

That said, what kind of device is it? Is it shown among the devices
"systemctl -t device" shows? If so, just add

   Wants=…
   After=…

to the [Unit] section of your unit file, both times listing the same
device unit name of your device on the right-hand-side.

Lennart

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

Delay service startup but only on boot

[Richard Shaw]

I've got a SystemD service file that starts a service, the problem is it
connects to another device that takes longer to boot up into a "ready"
state than the computer with the service.

I could just add a "ExecStartPre=/usr/bin/sleep 30" to the service file,
but will it delay for 30 seconds on restarts as well? I only want it to
wait on cold boots.

I may be better off creating a timer unit file and using OnBootSec but
didn't want to go with the complexity of a timer if I didn't have to.

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

Summary/Minutes from today's FESCo Meeting (2020-12-02)

[Stephen Gallagher]

=
#fedora-meeting-2: FESCO (2020-12-02)
=


Meeting started by sgallagh at 15:00:55 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-12-02/fesco.2020-12-02-15.00.log.html
.



Meeting summary
---
* init process  (sgallagh, 15:00:55)

* #2507 F34 Change: GNU Toolchain update (gcc 11, glibc 2.33)
  (sgallagh, 15:04:46)
  * AGREED: F34 Change: GNU Toolchain update (gcc 11, glibc 2.33) is
accepted (+7, 0, -0)  (sgallagh, 15:15:45)

* #2501 F34 System-Wide Change: Remove nscd in favour of sssd and
  systemd-resolved  (sgallagh, 15:16:29)
  * AGREED: Deprecation of nscd is approved for F34, removal of nscd is
approved for F35 (+6, 0, -0)  (sgallagh, 15:27:11)
  * ACTION: arjun will split the Change proposal for F34 and F35 and
update the FESCo ticket with the new links.  (sgallagh, 15:27:48)

* Next week's chair  (sgallagh, 15:29:06)
  * ACTION: cverna will chair the next meeting  (sgallagh, 15:35:08)

* Open Floor  (sgallagh, 15:35:14)
  * Elections voting ends at 2359 UTC on Thursday:
https://elections.fedoraproject.org  (bcotton, 15:36:11)

Meeting ended at 15:51:09 UTC.




Action Items

* arjun will split the Change proposal for F34 and F35 and update the
  FESCo ticket with the new links.
* cverna will chair the next meeting




Action Items, by person
---
* arjun
  * arjun will split the Change proposal for F34 and F35 and update the
FESCo ticket with the new links.
* cverna
  * cverna will chair the next meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* sgallagh (68)
* King_InuYasha (46)
* bcotton (24)
* zodbot (23)
* jlaw (19)
* nirik (18)
* zbyszek (14)
* dcantrell (13)
* decathorpe (10)
* arjun (5)
* cverna (4)
* Conan_Kudo (2)
* smooge (2)
* copperi (1)
* ignatenkobrain (0)
* Eighth_Doctor (0)
* mhroncok (0)
* Sir_Gallantmon (0)
* Son_Goku (0)
* Pharaoh_Atem (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: ntp replacement (Self-Contained Change)

[Miroslav Lichvar]

On Wed, Dec 02, 2020 at 09:29:05AM -0600, Chris Adams wrote:
> Once upon a time, Tomasz Torcz  said:
> >   There ARE functional changes. Mainly removal of long-obsolete drivers,
> > full list can be found at:
> > https://docs.ntpsec.org/latest/ntpsec.html#incompatible
> > https://www.ntpsec.org/removal-plan.html
> 
> Yeah, this would break my use of NTP, since I use one of the drivers to
> be removed (I have an old Trimble Resolution T, which uses the Palisade
> driver).  I think I tried gpsd with it at one point and something didn't
> work, can't remember now.

The ntp drivers stay in the ntp-refclock package. It requires an extra
service to run the ntpd driver, but you can feed the ntpsec ntpd or
chrony using the SHM or SOCK driver.

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

Simple review request: perl-File-DirList (needed to unbreak devscripts)

[Sandro Mani]

Hi

devscripts grew a new runtime dependency for perl-File-DirList which was 
not picked up. Review request is here:


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

Happy to review in exchange.

Thanks
Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: ntp replacement (Self-Contained Change)

[Chris Adams]

Once upon a time, Tomasz Torcz  said:
>   There ARE functional changes. Mainly removal of long-obsolete drivers,
> full list can be found at:
> https://docs.ntpsec.org/latest/ntpsec.html#incompatible
> https://www.ntpsec.org/removal-plan.html

Yeah, this would break my use of NTP, since I use one of the drivers to
be removed (I have an old Trimble Resolution T, which uses the Palisade
driver).  I think I tried gpsd with it at one point and something didn't
work, can't remember now.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: ntp replacement (Self-Contained Change)

[Tomasz Torcz]

On Wed, Dec 02, 2020 at 10:00:04AM -0500, Neal Gompa wrote:
> > == Release Notes ==
> > TBD
> >
> 
> Makes sense, though I think the release notes section would be pretty
> easy to write:
> 
> "The classic ntpd service was formerly provided by the ntp package.
> The ntp software has significant security issues and development seems
> moribund. It has now been replaced with the ntpsec package, an
> actively maintained fork of the ntp software. No functional changes
> are expected."

  There ARE functional changes. Mainly removal of long-obsolete drivers,
full list can be found at:
https://docs.ntpsec.org/latest/ntpsec.html#incompatible
https://www.ntpsec.org/removal-plan.html


-- 
Tomasz TorczTo co nierealne – tutaj jest normalne.
to...@pipebreaker.pl  Ziomale na życie mają tu patenty specjalne.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: ntp replacement (Self-Contained Change)

[Miroslav Lichvar]

On Wed, Dec 02, 2020 at 10:00:04AM -0500, Neal Gompa wrote:
> Makes sense, though I think the release notes section would be pretty
> easy to write:
> 
> "The classic ntpd service was formerly provided by the ntp package.
> The ntp software has significant security issues and development seems
> moribund. It has now been replaced with the ntpsec package, an
> actively maintained fork of the ntp software. No functional changes
> are expected."

Thanks. I put it there with "No functional changes are expected for most
users" as ntpsec doesn't have some of the less useful features of ntp.

-- 
Miroslav Lichvar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: ntp replacement (Self-Contained Change)

[Neal Gompa]

On Wed, Dec 2, 2020 at 9:24 AM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/NtpReplacement
>
> == Summary ==
>
> The `ntp` package is replaced with `ntpsec`.
>
> == Owner ==
> * Name: [[User:mlichvar| Miroslav Lichvar]]
> * Email: mlich...@redhat.com
>
> == Detailed Description ==
>
> `ntp` is one of the few NTP implementations provided in Fedora. It is
> not used or installed by default.
>
> The [https://www.ntp.org/ upstream project] is not in a good shape and
> it doesn't seem to be improving. The development is slow and happens
> behind closed doors. There is a significant number of known security
> issues that have not been fixed yet. Some are exploitable in the
> default configuration.
>
> [https://www.ntpsec.org/ ntpsec] is a fork of `ntp` with focus on
> security. It has removed a lot of code and fixed or avoided most of
> the security issues in `ntp`. It doesn't support all features, but in
> typical configurations it can be used as a drop-in replacement for
> `ntp`.
>
> There are few packages in Fedora that have a dependency on `ntp`:
> * `nagios-plugins-ntp-perl`
> * `ntpstat`
>
> == Benefit to Fedora ==
>
> This change makes Fedora more secure.
>
> == Scope ==
> * Proposal owners:
>
> # Package `ntpsec` obsoleting the `ntp` package.
> # Retire `ntp` package.
> # Make sure the dependent packages still work.
>
> * Other developers: N/A (not a System Wide Change)
> * Release engineering: N/A (not needed for this Change)
> * Policies and guidelines: N/A (not a System Wide Change)
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
>
> The `ntp` package is replaced automatically on upgrade to Fedora 34.
> The configuration file ''/etc/ntp.conf'' is saved as to
> ''/etc/ntp.conf.rpmsave'' and it needs to be renamed to
> ''/etc/ntp.conf'' to be used by `ntpsec`. Otherwise, `ntpsec` will
> fall back to the default configuration in ''/etc/ntp.d'' using the
> ''pool.ntp.org'' servers.
>
> The `ntpd` service is disabled after the upgrade and needs to be enabled 
> again.
>
> == How To Test ==
> * Install `ntpsec`
> * Run `ntpdate pool.ntp.org`
> * Start the `ntpd` service
> * Run `ntpq -p` to verify `ntpd` is polling servers and synchronizing the 
> clock
>
> == User Experience ==
> For most users of `ntp` the experience is not expected to change
> significantly. Advanced configurations may need to be modified to work
> with `ntpsec`.
>
> == Dependencies ==
> N/A (not a System Wide Change)
>
> == Contingency Plan ==
>
> * Contingency mechanism: Unretire `ntp` and remove the obsoletes in `ntpsec`
> * Contingency deadline: Fedora 34 Beta
> * Blocks release? N/A (not a System Wide Change)
> * Blocks product?
>
> == Documentation ==
> N/A (not a System Wide Change)
>
> == Release Notes ==
> TBD
>

Makes sense, though I think the release notes section would be pretty
easy to write:

"The classic ntpd service was formerly provided by the ntp package.
The ntp software has significant security issues and development seems
moribund. It has now been replaced with the ntpsec package, an
actively maintained fork of the ntp software. No functional changes
are expected."



-- 
真実はいつも一つ！/ 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 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Neal Gompa]

On Wed, Dec 2, 2020 at 9:23 AM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/FedoraCoreOS
>
> == Summary ==
>
> This changes is to promote Fedora CoreOS to Edition status alongside
> Workstation, Server and IoT.
>
> == Owners ==
>
> * Name: [[User:cverna|Clement Verna]]
> * Email: cve...@fedoraproject.org
> * Products: Fedora CoreOS
> * Responsible WGs: Fedora CoreOS Group
>
>
> == Detailed Description ==
>
> This changes is to promote Fedora CoreOS to Edition status alongside
> Workstation, Server and IoT.
>
> [https://fedoraproject.org/wiki/Editions/Promotion_Process#Prerequisites
> Prerequisites] are tracked bellow :
>
> * Edition has a team with regular public meeting :
> [https://apps.fedoraproject.org/calendar/meeting/9437/ weekly meeting
> happening on #fedora-meeting-1]
>
> * Trademark approval from the Fedora Council :
> [https://pagure.io/Fedora-Council/tickets/issue/340 council ticket]
>
> * Product requirements document (PRD) :
> https://fedoraproject.org/wiki/CoreOS/PRD
>
> * Technical specification :
> https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md
>
> == Feedback ==
>
> == Benefit to Fedora ==
>
> Make Fedora CoreOS an official edition, will help spread adoption and
> position Fedora as credible solution for running container workflow.
>
> == Scope ==
> * Proposal owners: see change owners
>
> * Other developers: N/A
>
> * Release engineering: Fedora CoreOS is already being composed and released.
>
> * Policies and guidelines: N/A
>
> * Trademark approval: https://pagure.io/Fedora-Council/tickets/issue/340
>
> == Upgrade/compatibility impact ==
> N/A
>
> == How To Test ==
> See QA test cases : https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases
>
> We also have regular tests days, for example
> https://fedoramagazine.org/fedora-coreos-test-day/
>
> == User Experience ==
>
>  Pros 
>
>  Enhancement opportunities 
>
> == Dependencies ==
>
> == Contingency Plan ==
> Contingency mechanism: (What to do? Who will do it?) Delay promotion until F35
>
> Contingency deadline: F34 Final release date
>
> Blocks release? No
>
> == Documentation ==
> https://docs.fedoraproject.org/en-US/fedora-coreos/
>
> == Release Notes ==

Meh, sure I guess? This is a paperwork change. It's been considered an
Edition in practice since it replaced Fedora Atomic, which *was* a
full Edition in its own right.


-- 
真実はいつも一つ！/ 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

Upcoming Fedora 34 deadlines

[Ben Cotton]

Here we are, already thinking about Change submission deadlines for
Fedora 34! Some key dates you should know:

* 2020-12-16 — Change proposal deadline: Changes requiring
infrastructure changes
* 2020-12-29 — Change proposal deadline: System-Wide Changes, Changes
requiring mass rebuild
* 2021-01-19 — Change proposal deadline: Self-Contained Changes

The full Fedora 34 schedule is on Fedora People:
https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html

I will send additional reminders as we approach the deadlines. You can
also read the weekly Fedora program updates on the Community Blog[2]
or join the FPgM office hours at 9 AM Eastern (currently 1400 UTC) on
Wednesdays[3].


[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
[2] https://communityblog.fedoraproject.org/category/program-management/
[3] https://apps.fedoraproject.org/calendar/meeting/9527/

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

Upcoming Fedora 34 deadlines

[Ben Cotton]

Here we are, already thinking about Change submission deadlines for
Fedora 34! Some key dates you should know:

* 2020-12-16 — Change proposal deadline: Changes requiring
infrastructure changes
* 2020-12-29 — Change proposal deadline: System-Wide Changes, Changes
requiring mass rebuild
* 2021-01-19 — Change proposal deadline: Self-Contained Changes

The full Fedora 34 schedule is on Fedora People:
https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html

I will send additional reminders as we approach the deadlines. You can
also read the weekly Fedora program updates on the Community Blog[2]
or join the FPgM office hours at 9 AM Eastern (currently 1400 UTC) on
Wednesdays[3].


[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
[2] https://communityblog.fedoraproject.org/category/program-management/
[3] https://apps.fedoraproject.org/calendar/meeting/9527/

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

Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Ben Cotton]

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

== Summary ==

This changes is to promote Fedora CoreOS to Edition status alongside
Workstation, Server and IoT.

== Owners ==

* Name: [[User:cverna|Clement Verna]]
* Email: cve...@fedoraproject.org
* Products: Fedora CoreOS
* Responsible WGs: Fedora CoreOS Group


== Detailed Description ==

This changes is to promote Fedora CoreOS to Edition status alongside
Workstation, Server and IoT.

[https://fedoraproject.org/wiki/Editions/Promotion_Process#Prerequisites
Prerequisites] are tracked bellow :

* Edition has a team with regular public meeting :
[https://apps.fedoraproject.org/calendar/meeting/9437/ weekly meeting
happening on #fedora-meeting-1]

* Trademark approval from the Fedora Council :
[https://pagure.io/Fedora-Council/tickets/issue/340 council ticket]

* Product requirements document (PRD) :
https://fedoraproject.org/wiki/CoreOS/PRD

* Technical specification :
https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md

== Feedback ==

== Benefit to Fedora ==

Make Fedora CoreOS an official edition, will help spread adoption and
position Fedora as credible solution for running container workflow.

== Scope ==
* Proposal owners: see change owners

* Other developers: N/A

* Release engineering: Fedora CoreOS is already being composed and released.

* Policies and guidelines: N/A

* Trademark approval: https://pagure.io/Fedora-Council/tickets/issue/340

== Upgrade/compatibility impact ==
N/A

== How To Test ==
See QA test cases : https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases

We also have regular tests days, for example
https://fedoramagazine.org/fedora-coreos-test-day/

== User Experience ==

 Pros 

 Enhancement opportunities 

== Dependencies ==

== Contingency Plan ==
Contingency mechanism: (What to do? Who will do it?) Delay promotion until F35

Contingency deadline: F34 Final release date

Blocks release? No

== Documentation ==
https://docs.fedoraproject.org/en-US/fedora-coreos/

== Release Notes ==


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

Fedora 34 Change: ntp replacement (Self-Contained Change)

[Ben Cotton]

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

== Summary ==

The `ntp` package is replaced with `ntpsec`.

== Owner ==
* Name: [[User:mlichvar| Miroslav Lichvar]]
* Email: mlich...@redhat.com

== Detailed Description ==

`ntp` is one of the few NTP implementations provided in Fedora. It is
not used or installed by default.

The [https://www.ntp.org/ upstream project] is not in a good shape and
it doesn't seem to be improving. The development is slow and happens
behind closed doors. There is a significant number of known security
issues that have not been fixed yet. Some are exploitable in the
default configuration.

[https://www.ntpsec.org/ ntpsec] is a fork of `ntp` with focus on
security. It has removed a lot of code and fixed or avoided most of
the security issues in `ntp`. It doesn't support all features, but in
typical configurations it can be used as a drop-in replacement for
`ntp`.

There are few packages in Fedora that have a dependency on `ntp`:
* `nagios-plugins-ntp-perl`
* `ntpstat`

== Benefit to Fedora ==

This change makes Fedora more secure.

== Scope ==
* Proposal owners:

# Package `ntpsec` obsoleting the `ntp` package.
# Retire `ntp` package.
# Make sure the dependent packages still work.

* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==

The `ntp` package is replaced automatically on upgrade to Fedora 34.
The configuration file ''/etc/ntp.conf'' is saved as to
''/etc/ntp.conf.rpmsave'' and it needs to be renamed to
''/etc/ntp.conf'' to be used by `ntpsec`. Otherwise, `ntpsec` will
fall back to the default configuration in ''/etc/ntp.d'' using the
''pool.ntp.org'' servers.

The `ntpd` service is disabled after the upgrade and needs to be enabled again.

== How To Test ==
* Install `ntpsec`
* Run `ntpdate pool.ntp.org`
* Start the `ntpd` service
* Run `ntpq -p` to verify `ntpd` is polling servers and synchronizing the clock

== User Experience ==
For most users of `ntp` the experience is not expected to change
significantly. Advanced configurations may need to be modified to work
with `ntpsec`.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==

* Contingency mechanism: Unretire `ntp` and remove the obsoletes in `ntpsec`
* Contingency deadline: Fedora 34 Beta
* Blocks release? N/A (not a System Wide Change)
* Blocks product?

== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==
TBD


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

Fedora 34 Change: ntp replacement (Self-Contained Change)

[Ben Cotton]

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

== Summary ==

The `ntp` package is replaced with `ntpsec`.

== Owner ==
* Name: [[User:mlichvar| Miroslav Lichvar]]
* Email: mlich...@redhat.com

== Detailed Description ==

`ntp` is one of the few NTP implementations provided in Fedora. It is
not used or installed by default.

The [https://www.ntp.org/ upstream project] is not in a good shape and
it doesn't seem to be improving. The development is slow and happens
behind closed doors. There is a significant number of known security
issues that have not been fixed yet. Some are exploitable in the
default configuration.

[https://www.ntpsec.org/ ntpsec] is a fork of `ntp` with focus on
security. It has removed a lot of code and fixed or avoided most of
the security issues in `ntp`. It doesn't support all features, but in
typical configurations it can be used as a drop-in replacement for
`ntp`.

There are few packages in Fedora that have a dependency on `ntp`:
* `nagios-plugins-ntp-perl`
* `ntpstat`

== Benefit to Fedora ==

This change makes Fedora more secure.

== Scope ==
* Proposal owners:

# Package `ntpsec` obsoleting the `ntp` package.
# Retire `ntp` package.
# Make sure the dependent packages still work.

* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==

The `ntp` package is replaced automatically on upgrade to Fedora 34.
The configuration file ''/etc/ntp.conf'' is saved as to
''/etc/ntp.conf.rpmsave'' and it needs to be renamed to
''/etc/ntp.conf'' to be used by `ntpsec`. Otherwise, `ntpsec` will
fall back to the default configuration in ''/etc/ntp.d'' using the
''pool.ntp.org'' servers.

The `ntpd` service is disabled after the upgrade and needs to be enabled again.

== How To Test ==
* Install `ntpsec`
* Run `ntpdate pool.ntp.org`
* Start the `ntpd` service
* Run `ntpq -p` to verify `ntpd` is polling servers and synchronizing the clock

== User Experience ==
For most users of `ntp` the experience is not expected to change
significantly. Advanced configurations may need to be modified to work
with `ntpsec`.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==

* Contingency mechanism: Unretire `ntp` and remove the obsoletes in `ntpsec`
* Contingency deadline: Fedora 34 Beta
* Blocks release? N/A (not a System Wide Change)
* Blocks product?

== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==
TBD


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

Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Ben Cotton]

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

== Summary ==

This changes is to promote Fedora CoreOS to Edition status alongside
Workstation, Server and IoT.

== Owners ==

* Name: [[User:cverna|Clement Verna]]
* Email: cve...@fedoraproject.org
* Products: Fedora CoreOS
* Responsible WGs: Fedora CoreOS Group


== Detailed Description ==

This changes is to promote Fedora CoreOS to Edition status alongside
Workstation, Server and IoT.

[https://fedoraproject.org/wiki/Editions/Promotion_Process#Prerequisites
Prerequisites] are tracked bellow :

* Edition has a team with regular public meeting :
[https://apps.fedoraproject.org/calendar/meeting/9437/ weekly meeting
happening on #fedora-meeting-1]

* Trademark approval from the Fedora Council :
[https://pagure.io/Fedora-Council/tickets/issue/340 council ticket]

* Product requirements document (PRD) :
https://fedoraproject.org/wiki/CoreOS/PRD

* Technical specification :
https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md

== Feedback ==

== Benefit to Fedora ==

Make Fedora CoreOS an official edition, will help spread adoption and
position Fedora as credible solution for running container workflow.

== Scope ==
* Proposal owners: see change owners

* Other developers: N/A

* Release engineering: Fedora CoreOS is already being composed and released.

* Policies and guidelines: N/A

* Trademark approval: https://pagure.io/Fedora-Council/tickets/issue/340

== Upgrade/compatibility impact ==
N/A

== How To Test ==
See QA test cases : https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases

We also have regular tests days, for example
https://fedoramagazine.org/fedora-coreos-test-day/

== User Experience ==

 Pros 

 Enhancement opportunities 

== Dependencies ==

== Contingency Plan ==
Contingency mechanism: (What to do? Who will do it?) Delay promotion until F35

Contingency deadline: F34 Final release date

Blocks release? No

== Documentation ==
https://docs.fedoraproject.org/en-US/fedora-coreos/

== Release Notes ==


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

Re: Notice of upgrading xalan-c to 1.12.0 in Rawhide

[Zbigniew Jędrzejewski-Szmek]

On Wed, Dec 02, 2020 at 02:48:46PM +0100, Fabio Valentini wrote:
> On Wed, Dec 2, 2020 at 2:21 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Wed, Dec 02, 2020 at 07:36:44AM -0500, Ben Beasley wrote:
> > > To use a side-tag, I think I will need to ask for help from a
> > > provenpackager or file a releng ticket, in order to build dependent
> > > packages I do not maintain. Is that correct?
> > >
> > > It sounds like even the dependent package maintainers might not be
> > > able to submit a build to a side tag created by me—is that also your
> > > understanding?
> >
> > I'm not sure. I *think* other packagers can do builds into the side-tag.
> > ProvenPackagers privileges might be required to actually merge the side-tag.
> > If that's the case, I'll be happy to do it once the builds are done.
> >
> > I'm adding fedora-devel back in CC, so other people can comment.
> 
> I *think* building into side tags was never restricted to the user who
> created the side tag. Creating an update from a side tag that
> contained other user's builds used to require provenpackager rights,
> but should no longer do so, since bodhi 5.6.0 was deployed a few days
> ago:
> https://github.com/fedora-infra/bodhi/releases/tag/5.6.0

Thanks, that's great news.

FTR, I see three related side-tag-related improvements:
> Users which owns a side-tag can now create updates from that side-tag even if
> it contains builds for which they haven't commit access 
>
> Updates from side-tag for non-rawhide releases were not pushed to testing
> 
> Side-tag updates builds were not editable in the WebUI

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: External (non-rpm) BuidRequires - was New Mock release v2.7

[Miro Hrončok]

On 12/2/20 2:13 PM, Miroslav Suchý wrote:

Dne 02. 12. 20 v 11:51 Miro Hrončok napsal(a):

I can imagine myself using this locally when some test dependencies are missing 
(e.g. in RHEL). I hope it's possible to
use this with `mock --install` and not just as BuildRequires. It is not clear 
from the linked GH wiki page.


I did not thought about this. Should be easy to implement. Tracked here:
  https://github.com/rpm-software-management/mock/issues/671



1) Can I specify version ranges? Do I use RPM or Python syntax?


Version of module? Or version of python?


Version of the buildrequired PyPI package. E.g. "external:pypi:dnspython < 2".

(I assume this is what you've meant by "version of module".)


Python version will be whatever Python version pip is for. That's fine.

If support for multiple Python versions (e.g. for RHEL) is desired, passing 
custom pip package / command needs to be supported, e.g. via 
config_opts['external_buildrequires_pypi_required_packages'] and 
config_opts['external_buildrequires_pypi_install_command'].



No. You cannot. Neither of them.
Can you point me to differences between RPM and Python syntax of version ranges?


It's complicated :)

See https://github.com/gordonmessmer/pyreq2rpm/ for a best-effort conversion 
from Python package version specifiers to the RPM ones. The dependency generator 
uses this.



2) I've read that a temporary RPM package is created:


To satisfy rpm dependencies Mock calls create-fake-rpm and creates a fake rpm
package that provides external:pypi:foo and installs it in chroot.


Does the fake RPM provide pytohn3.9dist(foo)?


No. It does not. The fake rpm is there only to provide the string 
"external:pypi:*' so rpmbuild will proceed with building.
I can enhance it to provide pytohn3.9dist(foo). How can I get that 3.9 number?
I tried to look through existing macros and I tried to fiddle with 
/usr/lib/rpm/pythondistdeps.py but it does not ring
the bell.


If you can get the list of files installed by pip (pip knows them), you could 
run the dependency generator directly upon them.


This somehow gives the files, except you need to join Location and Files.

$ python -m pip show -f appdirs

Running the generator is:

$ echo /usr/lib/python3.9/site-packages/appdirs-1.4.3.dist-info/* | \
/usr/lib/rpm/pythondistdeps.py --provides \
--normalized-names-format pep503 --normalized-names-provide-both \
--majorver-provides-versions 2.7,3.9
python3.9dist(appdirs) = 1.4.3
python3dist(appdirs) = 1.4.3

However, since the buildrequired pypi packages can also bring in other packages, 
it's not that simple.


Also, that command's options will differ from buildroot to buildroot.


Should it?


I do not know. Should? :) I think it should. As it is build requirements it is 
welcomed and safe. Run time requirement
would be different case.

Tracked as:
https://github.com/rpm-software-management/mock/issues/672

Thank you for the feedback.




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

Schedule for Wednesday's FESCo Meeting (2020-12-02)

[Stephen Gallagher]

Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 15:00UTC in #fedora-meeting-2 on
irc.freenode.net.

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

or run:
  date -d '2020-12-02 15:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

tstellar request for provenpackager
https://pagure.io/fesco/issue/2505
DECISION (+17, 0, -0)

F34 Self-Contained Change: Stratis 2.2.0
https://pagure.io/fesco/issue/2503
DECISION (+4, 0, -0)

F34 Self-Contained Change: Modular GNOME Keyring services
https://pagure.io/fesco/issue/2502
DECISION (+4, 0, -0)

F34 System-Wide Change: Remove make from BuildRoot
https://pagure.io/fesco/issue/2500
DECISION (+4, 0, -0)

F34 Self-Contained Change: MariaDB 10.5
https://pagure.io/fesco/issue/2499
DECISION (+5, 0, -0)

= Followups =


= New business =

#topic #2507 F34 Change: GNU Toolchain update (gcc 11, glibc 2.33)
https://pagure.io/fesco/issue/2507

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Notice of upgrading xalan-c to 1.12.0 in Rawhide

[Fabio Valentini]

On Wed, Dec 2, 2020 at 2:21 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Dec 02, 2020 at 07:36:44AM -0500, Ben Beasley wrote:
> > To use a side-tag, I think I will need to ask for help from a
> > provenpackager or file a releng ticket, in order to build dependent
> > packages I do not maintain. Is that correct?
> >
> > It sounds like even the dependent package maintainers might not be
> > able to submit a build to a side tag created by me—is that also your
> > understanding?
>
> I'm not sure. I *think* other packagers can do builds into the side-tag.
> ProvenPackagers privileges might be required to actually merge the side-tag.
> If that's the case, I'll be happy to do it once the builds are done.
>
> I'm adding fedora-devel back in CC, so other people can comment.

I *think* building into side tags was never restricted to the user who
created the side tag. Creating an update from a side tag that
contained other user's builds used to require provenpackager rights,
but should no longer do so, since bodhi 5.6.0 was deployed a few days
ago:
https://github.com/fedora-infra/bodhi/releases/tag/5.6.0

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: Mass spec file change: Adding BuildRequires: make

[Artem Tim]

How to quickly retest packages which listed here 
https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested few 
locally and in Koji Rawhide scratch, but they are compiled fine.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Notice of upgrading xalan-c to 1.12.0 in Rawhide

[Zbigniew Jędrzejewski-Szmek]

On Wed, Dec 02, 2020 at 07:36:44AM -0500, Ben Beasley wrote:
> To use a side-tag, I think I will need to ask for help from a
> provenpackager or file a releng ticket, in order to build dependent
> packages I do not maintain. Is that correct?
>
> It sounds like even the dependent package maintainers might not be
> able to submit a build to a side tag created by me—is that also your
> understanding?

I'm not sure. I *think* other packagers can do builds into the side-tag.
ProvenPackagers privileges might be required to actually merge the side-tag.
If that's the case, I'll be happy to do it once the builds are done.

I'm adding fedora-devel back in CC, so other people can comment.

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

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

[Neal Gompa]

On Wed, Dec 2, 2020 at 8:14 AM Olivier Fourdan  wrote:
>
> Hi Dominik,
>
> On Wed, Dec 2, 2020 at 2:02 PM Dominik 'Rathann' Mierzejewski 
>  wrote:
>>
>>
>> Provides: xorg-x11-server-Xwayland = %{version}-%{release}
>> Obsoletes: xorg-x11-server-Xwayland < first-version-built-from-new-upstream
>>
>> https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages
>
>
> The package in the COPR [1] does:
>
> Provides:  xorg-x11-server-Xwayland = %{version}-%{release}
> Provides:  xorg-x11-server-Xwayland%{?_isa}
> Obsoletes: xorg-x11-server-Xwayland < %{version}-%{release}
>
> For some reason, dnf would complain when upgrading from the original 
> xorg-x11-server-Xwayland otherwise.
>
> But anyhow, the original question from Vít was not really how to achieve it, 
> but rather what name we want for that package.
>

I think that unless it's actually being split out from upstream
sources from the xorg-server repo, it would just be easier to call it
xorg-x11-server-Xwayland. But if you're dead set on renaming it, you
need to do it like so:

Obsoletes: xorg-x11-server-Xwayland < %{version}-%{release}
Provides:  xorg-x11-server-Xwayland = %{version}-%{release}
Provides:  xorg-x11-server-Xwayland%{?_isa} = %{version}-%{release}

The archful Provides needs to be versioned too.


-- 
真実はいつも一つ！/ 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 34 Change proposal: Xwayland as a standalone package (System-Wide Change)

[Olivier Fourdan]

Hi Dominik,

On Wed, Dec 2, 2020 at 2:02 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

>
> Provides: xorg-x11-server-Xwayland = %{version}-%{release}
> Obsoletes: xorg-x11-server-Xwayland < first-version-built-from-new-upstream
>
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages
>

The package in the COPR [1] does:

Provides:  xorg-x11-server-Xwayland = %{version}-%{release}
Provides:  xorg-x11-server-Xwayland%{?_isa}
Obsoletes: xorg-x11-server-Xwayland < %{version}-%{release}

For some reason, dnf would complain when upgrading from the original
xorg-x11-server-Xwayland otherwise.

But anyhow, the original question from Vít was not really how to achieve
it, but rather what name we want for that package.

Cheers
Olivier

[1] https://copr.fedorainfracloud.org/coprs/ofourdan/Xwayland/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: External (non-rpm) BuidRequires - was New Mock release v2.7

[Miroslav Suchý]

Dne 02. 12. 20 v 11:51 Miro Hrončok napsal(a):
> I can imagine myself using this locally when some test dependencies are 
> missing (e.g. in RHEL). I hope it's possible to
> use this with `mock --install` and not just as BuildRequires. It is not clear 
> from the linked GH wiki page.

I did not thought about this. Should be easy to implement. Tracked here:
 https://github.com/rpm-software-management/mock/issues/671


> 1) Can I specify version ranges? Do I use RPM or Python syntax?

Version of module? Or version of python?
No. You cannot. Neither of them.
Can you point me to differences between RPM and Python syntax of version ranges?

> 2) I've read that a temporary RPM package is created:
> 
>> To satisfy rpm dependencies Mock calls create-fake-rpm and creates a fake rpm
>> package that provides external:pypi:foo and installs it in chroot.
> 
> Does the fake RPM provide pytohn3.9dist(foo)? 

No. It does not. The fake rpm is there only to provide the string 
"external:pypi:*' so rpmbuild will proceed with building.
I can enhance it to provide pytohn3.9dist(foo). How can I get that 3.9 number?
I tried to look through existing macros and I tried to fiddle with 
/usr/lib/rpm/pythondistdeps.py but it does not ring
the bell.

> Should it?

I do not know. Should? :) I think it should. As it is build requirements it is 
welcomed and safe. Run time requirement
would be different case.

Tracked as:
https://github.com/rpm-software-management/mock/issues/672

Thank you for the feedback.


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

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

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 02 December 2020 at 11:35, Olivier Fourdan wrote:
> On Tue, Dec 1, 2020 at 1:12 PM Vít Ondruch  wrote:
> 
> > Have you considered to keep using the "xorg-x11-server-Xwayland" package
> > name?
> 
> Yes, the first package I did when considering this approach was indeed
> named xorg-x11-server-Xwayland :)
> 
> Changing the name makes it clear that this package is not built from the
> same sources as the rest of the xorg-x11-server-* packages, it makes the
> distinction very clear.
> 
> But if we reckon we should stick to xorg-x11-server-Xwayland, I don't have
> a strong opinion on that.

Provides: xorg-x11-server-Xwayland = %{version}-%{release}
Obsoletes: xorg-x11-server-Xwayland < first-version-built-from-new-upstream

https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages

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: Fedora 34 Change proposal: Xwayland as a standalone package (System-Wide Change)

[Felix Schwarz]

(Disclaimer: Just an XWayland user, so I might be totally wrong)

Am 01.12.20 um 10:58 schrieb Fabio Valentini:

I assume there are also at least *some* improvements (other than
XWayland improvements) in the xserver repo that are not released yet?


I think one example could be:

xwayland: Add EGL-backed GLX provider
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/195

which fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=98272

Basically this fixes some well-known (sort of) Steam games from "Paradox 
Interactive" to launch when using a wayland desktop session. Right now users 
have to resort to X.org to play these games on Linux.


These fixes were merged in May 2019 with some follow-up fix in December 2019 but 
only in master so it is quite difficult for users to benefit from these.




Could we at least get one final, last, xserver release, maybe even
with XWayland split out as a separate component upstream?


As far as I know nobody is really keen on spending time on xserver releases:

Adam Jackson (@ajax): "on abandoning the X server"
https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server.html

Also Daniel Vetter (Intel) is on record that the xserver might be considered 
"abandonware".

https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/533#note_670522

If I am reading Adam's comments correctly we would need some kind of release 
manager who herds all the cats and publishes a release. It's kind of sad that 
there is still Xorg development even though users do not benefit as there are no 
release being made.


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: External (non-rpm) BuidRequires - was New Mock release v2.7

[Miro Hrončok]

On 12/2/20 8:00 AM, Miroslav Suchý wrote:

Dne 01. 12. 20 v 13:07 Pavel Raiskup napsal(a):

I'm pleased to announce that there's a new Mock release.  Except for
several bugfixes, this release introduces a new
"External Build Requires" feature (by Miroslav Suchý)


I want to ask you for feedback on this feature.
   https://github.com/rpm-software-management/mock/wiki/Feature-external-deps

This feature will allow you to use in SPEC file
   BuildRequires: external:pypi:foo
which will run
pip3 --install foo
in the buildroot.

This is a new and experimental feature. Not yet enabled in Mock by default. And 
I do **not** expect that it will be
enabled in Fedora. Ever. It may be enabled in Copr one day. The primary 
audience is 3rd party packagers who need some
library for building, and it is not available as RPM.

I am aware that this is breaking some fundamentals of RPM. For this reason, I 
want to hear the feedback on whether this
is interesting for you or it should die in agony.


I can imagine myself using this locally when some test dependencies are missing 
(e.g. in RHEL). I hope it's possible to use this with `mock --install` and not 
just as BuildRequires. It is not clear from the linked GH wiki page.




Right now, this feature supports PyPI - I am confident there.


I have two questions about the PyPI support.


1) Can I specify version ranges? Do I use RPM or Python syntax?


2) I've read that a temporary RPM package is created:

> To satisfy rpm dependencies Mock calls create-fake-rpm and creates a fake rpm
> package that provides external:pypi:foo and installs it in chroot.

Does the fake RPM provide pytohn3.9dist(foo)? Should it?

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

Re: %pretrans [package name]

[Miro Hrončok]

On 12/2/20 1:04 AM, Jerry James wrote:

Hi all,

I need a little help.  Sagemath packages up through version 9.1
bundled mathjax (several times!  with 1 png file for every single
glyph in every single font!), which made the documentation very large.
When I built version 9.2, I attempted to unbundle mathjax, replacing
the relevant directories with symlinks.  This requires a %pretrans
scriptlet, as described here:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/

My first attempt added a script starting with "%pretrans doc-en -p
", since sagemath-doc-en is the package containing the
directories-turned-symlinks.  I built that version successfully in
mock, installed the old RPMs into a mock chroot, and then successfully
upgraded to the new version without RPM file conflicts.  Success!

Except that when I tried to build that version in koji, the SRPM
creation step failed.  I unfortunately did not write down the error,
but it pointed to the %pretrans line in the spec, and I somehow
deduced from the error message that something did not understand the
package name just after %pretrans.  So I changed it to "%pretrans -p
" in the most recent commit to the sagemath package git
repository, hoping that that would be okay, because it would still run
before the RPM transaction, right? Well, that didn't work:
https://bugzilla.redhat.com/show_bug.cgi?id=1903009

So now what?  How does one get "%pretrans [subpackage] -p " to
pass muster with koji?  Am I missing a trick?


Try this (note the -n):

%pretrans -n doc-en -p 

See an example in here:

https://src.fedoraproject.org/rpms/python-notebook/blob/master/f/python-notebook.spec#_175

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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4b568a793a   
golang-1.15.5-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a2eeb128a9   
drupal7-7.74-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ca501b4c5b   
chromium-87.0.4280.66-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

copr-cli-1.91-1.el7
mock-2.7-1.el7
python-copr-1.107-1.el7
python-qpid-1.37.0-5.el7

Details about builds:



 copr-cli-1.91-1.el7 (FEDORA-EPEL-2020-91149a4361)
 Command line interface for COPR

Update Information:

new mock --isolation option

ChangeLog:

* Mon Nov 30 2020 Pavel Raiskup  1.91-1
- new --isolation option
- add --help output for build --timeout option




 mock-2.7-1.el7 (FEDORA-EPEL-2020-77cf1cc1a9)
 Builds packages inside chroots

Update Information:

Mock v2.7  Release notes: https://github.com/rpm-software-
management/mock/wiki/Release-Notes-2.7  - bootstrap: copy-in katello CA pem file
if exists - early error when bootstrap is off and external buildrequires are
detected (msu...@redhat.com) - hotfix preexec_fn traceback on RHEL 8 s390x
(issue 653) - introduce external buildrequires (msu...@redhat.com) - add rpkg
spec preprocessing capability (cl...@fedoraproject.org) - sign plugin: don't
ignore signing command failure - don't setsid() twice with --shell - better
logging when dynamic BR detected (msu...@redhat.com) - do not TB if rpmbuild
fails with exit code 11 (msu...@redhat.com) - fix addrepo when repo is missing
(markus.linn...@gmail.com) - own the cheat directory - Allow percent-sign in
config_opts['resultdir'] - add a new "postupdate" hook (dture...@redhat.com) -
log mock's NVR

ChangeLog:

* Mon Nov 30 2020 Pavel Raiskup  2.7-1
- bootstrap: copy-in katello CA pem file if exists
- early error when bootstrap is off and external buildrequires are detected 
(msu...@redhat.com)
- hotfix preexec_fn traceback on RHEL 8 s390x (issue 653)
- introduce external buildrequires (msu...@redhat.com)
- add rpkg spec preprocessing capability (cl...@fedoraproject.org)
- sign plugin: don't ignore signing command failure
- don't setsid() twice with --shell
- better logging when dynamic BR detected (msu...@redhat.com)
- do not TB if rpmbuild fails with exit code 11 (msu...@redhat.com)
- fix addrepo when repo is missing (markus.linn...@gmail.com)
- own the cheat directory
- Allow percent-sign in config_opts['resultdir']
- add a new "postupdate" hook (dture...@redhat.com)
- log mock's NVR

References:

  [ 1 ] Bug #1175346 - RFE: LVM postinit snapshot should be re-created after 
update
https://bugzilla.redhat.com/show_bug.cgi?id=1175346
  [ 2 ] Bug #1879231 - RFE: include mock package version info in mock output
https://bugzilla.redhat.com/show_bug.cgi?id=1879231
  [ 3 ] Bug #1887905 - mock: unowned /usr/share/cheat directory
https://bugzilla.redhat.com/show_bug.cgi?id=1887905




 python-copr-1.107-1.el7 (FEDORA-EPEL-2020-91149a4361)
 Python interface for Copr

Update Information:

new mock --isolation option

ChangeLog:

* Mon Nov 30 2020 Pavel Raiskup  1.107-1
- new mock --isolation option
- deduplicate APIv3 build-chroot parameters




 python-qpid-1.37.0-5.el7 (FEDORA-EPEL-2020-9fc650ec67)
 Python client library for AMQP

Update Information:

Rebuilt against latest packages.

ChangeLog:



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

Re: Mass spec file change: Adding BuildRequires: make

[Mark Wielaard]

Hi Tom,

On Mon, 2020-11-30 at 14:06 -0800, Tom Stellard wrote:
> As part of the f34 change request[1] for removing make from the 
> buildroot, I will be doing a mass update of packages[2] to add 
> BuildRequires: make where it is needed.

As part of a previous change request [1] various packages were
transformed to use make macros (%make_build, %make_install) do these
macros automagically pull in the make build requires (or can they be
made to do so)?

Thanks,

Mark

[1] https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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)

[Olivier Fourdan]

Hi Vít,

On Tue, Dec 1, 2020 at 1:12 PM Vít Ondruch  wrote:

> Have you considered to keep using the "xorg-x11-server-Xwayland" package
> name?
>

Yes, the first package I did when considering this approach was indeed
named xorg-x11-server-Xwayland :)

Changing the name makes it clear that this package is not built from the
same sources as the rest of the xorg-x11-server-* packages, it makes the
distinction very clear.

But if we reckon we should stick to xorg-x11-server-Xwayland, I don't have
a strong opinion on that.

Cheers
Olivier
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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)

[Olivier Fourdan]

Hi Zbyszek

On Tue, Dec 1, 2020 at 12:35 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Mon, Nov 30, 2020 at 02:05:55PM -0500, Ben Cotton wrote:
> > This change is about moving Xwayland to a separate package from the
> > rest of Xorg, built from git snapshots of the current code upstream
> > rather than the stable branch.
>
> Sounds like the reasonable thing to do in the situation where Xwayland
> is still evolving but the other (huge) parts of the codebase are not.
> Consuming Xwayland independently seems much better than gathering an
> endless list of patches in downstream distro repos.
>

Exactly.

Do you have any plan how to pick specific commits that are "good"?
>

We contribute a lot to Xwayland upstream and we have a good knowledge of
what is happening upstream, so I reckon we are best placed to decide when
the standalone Xwayland package needs updating downstream, in Fedora.

Will those points be somehow coordinated between distros?
>

No, I have no plan to coordinate that with other distributions, this is
only about Fedora packaging.

But once upstream moves toward separate releases for Xwayland eventually,
we shall switch to that and most likely other distributions will follow.

Cheers
Olivier
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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)

[Olivier Fourdan]

Hi Fabio,

On Tue, Dec 1, 2020 at 11:01 AM Fabio Valentini 
wrote:

>
> I assume there are also at least *some* improvements (other than
> XWayland improvements) in the xserver repo that are not released yet?
>

Yes, surely.

Could we at least get one final, last, xserver release, maybe even
> with XWayland split out as a separate component upstream?
>

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).

As for a separate release of Xwayland upstream, I think this will happen
eventually.

This change here in Fedora is basically a first step forward in that
direction, when upstream comes up with a separate release for Xwayland as
well, our Fedora Xwayland standalone package will use that.


> That would make this downstream change easier, and would also benefit
> all other users of X (e.g. other distros that would like to do
> something similar to this change proposal)
>

Sure.

Cheers
Olivier
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: qemu-srpm-macros

[Dan Čermák]

"Richard W.M. Jones"  writes:

> Information about what architectures support what virtualization
> features is encoded in the qemu spec file.
>
> As an example, only a subset of architectures support qemu at all.
> A different subset support KVM hardware acceleration.  To find out
> which you'd better be an expert at decoding RPM macros:
>
>   https://src.fedoraproject.org/rpms/qemu/blob/master/f/qemu.spec
>
> libvirt.spec duplicates this information (arches_qemu_kvm):
>
>   https://src.fedoraproject.org/rpms/libvirt/blob/master/f/libvirt.spec
>
> libguestfs.spec will need to duplicate this too because we will need
> to ExcludeArch riscv64 until libvirt-daemon-kvm support is added.  At
> least cockpit, gnome-boxes also need libvirt-daemon-kvm, so I guess
> they will need the same information.
>
> For OCaml we successfully tackled a similar problem by adding a new
> standalone package called ocaml-srpm-macros which defines what
> architectures support what features:
>
>   
> https://src.fedoraproject.org/rpms/ocaml-srpm-macros/blob/master/f/macros.ocaml-srpm
>
> Note in this case it is a new top level, standalone package that
> redhat-rpm-config depends on.  A simpler way to do this would be to
> have qemu itself provide the /etc/rpm/macros.d/macros.qemu file.

Sounds good to me, but that has the disadvantage that every package that
wants to use these macros has to BuildRequire qemu. So unless that's the
default anyway, I'd suggest to use a subpackage.


Cheers,

Dan


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

qemu-srpm-macros

[Richard W.M. Jones]

Information about what architectures support what virtualization
features is encoded in the qemu spec file.

As an example, only a subset of architectures support qemu at all.
A different subset support KVM hardware acceleration.  To find out
which you'd better be an expert at decoding RPM macros:

  https://src.fedoraproject.org/rpms/qemu/blob/master/f/qemu.spec

libvirt.spec duplicates this information (arches_qemu_kvm):

  https://src.fedoraproject.org/rpms/libvirt/blob/master/f/libvirt.spec

libguestfs.spec will need to duplicate this too because we will need
to ExcludeArch riscv64 until libvirt-daemon-kvm support is added.  At
least cockpit, gnome-boxes also need libvirt-daemon-kvm, so I guess
they will need the same information.

For OCaml we successfully tackled a similar problem by adding a new
standalone package called ocaml-srpm-macros which defines what
architectures support what features:

  
https://src.fedoraproject.org/rpms/ocaml-srpm-macros/blob/master/f/macros.ocaml-srpm

Note in this case it is a new top level, standalone package that
redhat-rpm-config depends on.  A simpler way to do this would be to
have qemu itself provide the /etc/rpm/macros.d/macros.qemu file.

What do you think?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1903541] New: perl-Encode-3.08 is available

[bugzilla]

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

Bug ID: 1903541
   Summary: perl-Encode-3.08 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Encode
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 3.08
Current version/release in rawhide: 3.07-457.fc33
URL: http://search.cpan.org/dist/Encode/

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/2849/


-- 
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: Notice of upgrading xalan-c to 1.12.0 in Rawhide

[Zbigniew Jędrzejewski-Szmek]

On Tue, Dec 01, 2020 at 04:48:41PM -, Benjamin Beasley wrote:
> I am the new volunteer maintainer of the orphaned xalan-c package
> (Xalan XSLT processor for C/C++). On 2020-12-08, I plan to submit a
> build of the new upstream version, 1.12.0, to Rawhide.

Hi Benjamin,

great to see this package picked up. Thanks for working on this!

Don't submit the build to rawhide directly. The modern way of doing an
SOVERSION bump is to use a side-tag to rebuild the library and all
dependent packages together, and only then merge the side-tag into
rawhide.

Zbyszek

> Because the ABI will change (so-version changes from 111 to 112), the 
> following packages will need to be rebuilt. I will forward this notice 
> directly to their maintainers.
> 
> libdigidocpp – maintained by germano
> xml-security-c – maintained by kloczek
>
> The new release brings the following significant changes to the Fedora 
> package:
> 
> - Source code signature verification
> - New CMake build system
> - Enable new optional ICU dependency
> - Build API documentation with Doxygen
> 
> It will also resolve the following outstanding bugs:
> 
> xalan-c: New upstream release 1.12
> https://bugzilla.redhat.com/show_bug.cgi?id=1900893
> 
> xalan-c: FTBFS in Fedora rawhide/f33
> https://bugzilla.redhat.com/show_bug.cgi?id=1865631
> 
> I am also happy to report that we no longer need to carry a 6000+ line patch!
> 
> Note that the -devel packages now include pkg-config and CMake module files.
> 
> The upstream changelog for the new release is available at:
> 
> https://github.com/apache/xalan-c/releases/tag/Xalan-C_1_12_0
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

corsepiu pushed to perl-HTTP-Entity-Parser (f32). "Update to 0.25."

[notifications]

Notification time stamped 2020-12-02 09:18:32 UTC

From ead2cf008e27152ccf95ab9a0821e794c9900e60 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius 
Date: Dec 02 2020 09:13:41 +
Subject: Update to 0.25.


---

diff --git a/.gitignore b/.gitignore
index 0d5215b..0d68264 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/HTTP-Entity-Parser-0.24.tar.gz
+/HTTP-Entity-Parser-0.25.tar.gz
diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index c0fe7ca..27ed804 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -1,5 +1,5 @@
 Name:   perl-HTTP-Entity-Parser
-Version:0.24
+Version:0.25
 Release:1%{?dist}
 Summary:PSGI compliant HTTP Entity Parser
 License:GPL+ or Artistic
@@ -69,6 +69,9 @@ data and application/json.
 %{_mandir}/man3/*
 
 %changelog
+* Mon Nov 30 2020 Ralf Corsépius  - 0.25-1
+- Update to 0.25.
+
 * Sat Aug 22 2020 Ralf Corsépius  - 0.24-1
 - Update to 0.24.
 
diff --git a/sources b/sources
index 53823b6..4daf00a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (HTTP-Entity-Parser-0.24.tar.gz) = 
54552b772815e4b5b2a006a53f1fb8f89d3f002e4b203badaccd484354bababcc9875b7950743434fb79f6ce52e6c10421f0ba9255acf9cddad92c0b00171415
+SHA512 (HTTP-Entity-Parser-0.25.tar.gz) = 
760bff3ddd818ecb8eeeaee86c2d2bd895820b4011c306135b2d6eb3c2519322b3bd4e20098c9458c2fec7dd944384dcd33bfdd5b2d368a28270ac14e8dab54b



https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/ead2cf008e27152ccf95ab9a0821e794c9900e60?branch=f32
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Fedora-Cloud-32-20201202.0 compose check report

[Fedora compose checker]

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-32-20201201.0):

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

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

Re: Mass spec file change: Adding BuildRequires: make

[Vít Ondruch]

Dne 01. 12. 20 v 19:35 Tom Stellard napsal(a):

On 12/1/20 8:33 AM, Vít Ondruch wrote:


Dne 01. 12. 20 v 13:56 Zbigniew Jędrzejewski-Szmek napsal(a):

On Tue, Dec 01, 2020 at 01:20:33PM +0100, Vít Ondruch wrote:

Dne 01. 12. 20 v 2:37 Tom Stellard napsal(a):

False positive because they use gcc which was crashing due to the
(at the time) missing make dependency. Are these packages missing
BuildRequires: gcc ?



Do I understand correctly, that gcc requires make [0]? Therefore at
this stage, it should be enough to have `BuildRequires: gcc` and
hence such packages should not be on your list?

Please don't rely on gcc requiring make. This is an internal
implementation detail of the gcc package, and hopefully one day
we'll be able to drop this dependency.
If a package uses make directly, it should BR:make itself.



I think this was never clear cut if such dependency should be 
specified or not. The dependencies, which are at some point added for 
whatever good reason might be left behind while they are not useful 
anymore. This problem on itself is much harder to solve then adding 
the missing dependencies should they be needed one day.


So while I don't disagree with your point, I think the the `BR: make` 
should be automatically added only where needed right now to prevent 
FTBFS after make removal.




Now that gcc requires make, if we took this approach there would be 
very few packages that need to be updated for this change request.  If 
gcc did decide to drop the make dependency or make it weak, who would 
take on the work of updating the thousands of packages that use make?  
Right now, we have someone (me) who is willing an able to do the 
updates, and I think we should this is a good reason to update all the 
packages now.



As a Ruby maintainer, I generally care about all rubygems- packages and 
since there is more then a few on the list, I was considering also other 
options, such as adding `BR: make` as a dependency of ruby{,gems}-devel 
or possibly directly into rubygems package, because honestly it is not 
that obvious that some rubygem- packages depends on make, because this 
dependency is well hidden. This is one thing.


But there are others. If the decision is to move forward with the 
change, then there should be fixed not only the rubygem- packages in 
question, but there should be fixed also gem2rpm to add the dependency.


Please don't get me wrong, I don't object the change. I especially don't 
object to the "Remove make from BuildRoot". I just want to highlight 
that that the landscape slightly changed since the initial proposal, 
because gcc explicitly depends on make and there are different possible 
options for some of the packages. And there are necessary changes which 
are left out of the scope. Therefore it might be good to focus again on 
the original proposal, which was not to "Add make dependency to every 
package which requires make."



Vít




-Tom



Vít




Zbyszek


I am asking, because for example rubygem-bcrypt is on the list while
requiring gcc [1]. This is just one package I have checked (but
actually I have added make to the ruby package, later wondering if
it was necessary), but I suspect that also other rubygem- packages
are similar case. Could you please make sure if they should or
should not be on your list?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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






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