[Bug 1927563] perl-Test-Output-1.033 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Test-Output-1.03.3-1.f
   ||c35
   ||perl-Test-Output-1.03.3-1.f
   ||c34
 Resolution|--- |RAWHIDE
Last Closed||2021-02-11 07:53:18




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

Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream

[Adam Williamson]

On Thu, 2021-02-11 at 08:16 +0100, Frantisek Zatloukal wrote:
> On Wed, Feb 10, 2021 at 11:27 PM Debarshi Ray  wrote:
> 
> > Hey,
> > 
> > I wanted to respond earlier, but it totally slipped my mind.
> > 
> > We'd totally use releasestream in Toolbox for mapping the string
> > "rawhide" to a numeric version:
> > https://github.com/containers/toolbox/issues/646
> > 
> > Cheers,
> > Rishi
> > 
> 
> You (and anybody else, ofc :) ) can take a look at the packager dashboard
> before Adam deploys releasestream. It exposes Fedora release information on
> https://packager-dashboard.fedoraproject.org/api/v1/releases . It's  based
> on fedfind, with some more logic and information processing in the
> background.

In the end, though, fedfind is just getting its info from a JSON file I
hand edit, which winds up getting reprocessed into that...:D
https://fedorapeople.org/groups/qa/metadata/release.json 
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-33-20210211.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-20210210.0):

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

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

Packages conflict in /usr/lib/.build-id/

[Lumír Balhar]

Hello.

I'm facing a problem with a conflict between two packages from 
non-fedora repositories. I'm using vscodium and rememberthemilk apps for 
a long time but now I cannot update both because there is a conflict in 
/usr/lib/.build-id/.


Error: Transaction test error:
  file /usr/lib/.build-id/14/512ca58e91f1940ba8e68d620c03e13cfb7d82 
from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file 
from package rememberthemilk-1.3.2-1.x86_64
  file /usr/lib/.build-id/1c/1eccea7fe32b13593eb32f999fc3ce90432239 
from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file 
from package rememberthemilk-1.3.2-1.x86_64
  file /usr/lib/.build-id/63/e57a96064e30d496ce9596cb5861ce64f52160 
from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file 
from package rememberthemilk-1.3.2-1.x86_64
  file /usr/lib/.build-id/66/c77539c4ab0def65c2f355188fe71bff7b602d 
from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file 
from package rememberthemilk-1.3.2-1.x86_64
  file /usr/lib/.build-id/74/589964965a9efc95d3e4202f7fc6a7226b6e78 
from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file 
from package rememberthemilk-1.3.2-1.x86_64
  file /usr/lib/.build-id/76/90a7dcb40a4a052fdfb0f46a0dbeabbdf6df47 
from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file 
from package rememberthemilk-1.3.2-1.x86_64
  file /usr/lib/.build-id/a7/97d3b4a5fac6864fda3d230e3ac9104d624990 
from install of codium-1.53.1-1612917076.el7.x86_64 conflicts with file 
from package rememberthemilk-1.3.2-1.x86_64


It seems to me that both apps are using the same engine which might lead 
to this.


Is there any way how to solve this problem from user perespective?

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

[Bug 1927623] New: perl-Workflow-1.52 is available

[bugzilla]

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

Bug ID: 1927623
   Summary: perl-Workflow-1.52 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Workflow
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.52
Current version/release in rawhide: 1.51-1.fc34
URL: https://metacpan.org/release/Workflow

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


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

[Bug 1927563] perl-Test-Output-1.033 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|st...@silug.org |
   Doc Type|--- |If docs needed, set a value




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

Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream

[Frantisek Zatloukal]

On Wed, Feb 10, 2021 at 11:27 PM Debarshi Ray  wrote:

> Hey,
>
> I wanted to respond earlier, but it totally slipped my mind.
>
> We'd totally use releasestream in Toolbox for mapping the string
> "rawhide" to a numeric version:
> https://github.com/containers/toolbox/issues/646
>
> Cheers,
> Rishi
>

You (and anybody else, ofc :) ) can take a look at the packager dashboard
before Adam deploys releasestream. It exposes Fedora release information on
https://packager-dashboard.fedoraproject.org/api/v1/releases . It's  based
on fedfind, with some more logic and information processing in the
background.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Jeff,

thank you for your offer, I will gladly use your tester. What
information/RPMs/SRPMs do you need from me?

Miro,

maybe it could be a system-wide change. If you think so, I can change it.
About the absolute numbers, as you said, not all FTBFS are necessarily
caused by autoconf, but I did not have the time to investigate all of them.
>From my perspective, lots of failures were caused by upstream/downstream
dependency directly on autoconf-2.69, so we have to discuss these changes
with package maintainers.

Ondrej

On Wed, Feb 10, 2021 at 8:32 PM Jeff Law  wrote:

>
>
> On 2/10/21 11:00 AM, Miro Hrončok wrote:
> > On 10. 02. 21 18:47, Ben Cotton wrote:
> >> == Upgrade/compatibility impact ==
> >> Problems during build can appear in multiple packages what can lead to
> >> build failure, as multiple packages require autoconf-2.69 as their
> >> upstream dependency. These problems have to be resolved before adding
> >> autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages
> >> are having problems during build, which could be caused by a problem
> >> with same pattern.
> >
> > In absolute numbers, what is 20%? I see ~200 failures at
> > https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/monitor/
> > (obviously not all of them are necessarily caused by autoconf).
> >
> > Should this be a system-wide change instead?
> Given how many packages use autoconf, I think so.
>
> --
>
> I've already volunteered my tester to help shake out this change.  It's
> actually a really good fit because of the autoconf/LTO interactions we
> had to sort out for F33/LTO.  The plan is to spin it up next week.
>
> In simplest terms autoconf generated code to test for the existence of
> certain capabilities can be optimized away completely by LTO.  This
> results in autoconf incorrectly claiming certain capabilities exist.
> This can cause packages to FTBFS or to even mis-behave at runtime.
>
> Thus it was critical to find these cases and deal with them as part of
> the LTO effort.  So my tester has the ability to capture generated
> config.h files across its control and test builds and will report a
> failure if the generated config.h files differ (with an ability to
> exclude those where timestamps and such end up in the generated config.h
> files).
>
> In the test I'm going to run the only difference between the control and
> test build will be the version of autoconf.  So the failures should give
> us a highly accurate picture of how autoconf-2.70 will impact the
> distribution as a whole.
>
> jeff
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-devel] 389 DS nightly 2021-02-11 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/11/report-389-ds-base-2.0.2-20210211git137db8058.fc33.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp
Xfce raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
11 of 43 required tests failed, 1 result missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 42/183 (x86_64), 30/124 (aarch64)

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

ID: 773961  Test: x86_64 Server-dvd-iso server_role_deploy_database_server 
**GATING**
URL: https://openqa.fedoraproject.org/tests/773961
ID: 773963  Test: x86_64 Server-dvd-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/773963
ID: 773966  Test: x86_64 Server-dvd-iso server_database_client **GATING**
URL: https://openqa.fedoraproject.org/tests/773966
ID: 773974  Test: x86_64 Server-dvd-iso mediakit_fileconflicts
URL: https://openqa.fedoraproject.org/tests/773974
ID: 773976  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/773976
ID: 773986  Test: x86_64 Server-dvd-iso server_cockpit_default **GATING**
URL: https://openqa.fedoraproject.org/tests/773986
ID: 774006  Test: x86_64 Workstation-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/774006
ID: 774007  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/774007
ID: 774018  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/774018
ID: 774022  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/774022
ID: 774023  Test: x86_64 KDE-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/774023
ID: 774024  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/774024
ID: 774028  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/774028
ID: 774032  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/774032
ID: 774033  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/774033
ID: 774035  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/774035
ID: 774059  Test: aarch64 Minimal-raw_xz-raw.xz base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/774059
ID: 774072  Test: aarch64 Server-dvd-iso 
server_role_deploy_database_server@uefi
URL: https://openqa.fedoraproject.org/tests/774072
ID: 774074  Test: aarch64 Server-dvd-iso base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/774074
ID: 774079  Test: aarch64 Server-dvd-iso server_database_client@uefi
URL: https://openqa.fedoraproject.org/tests/774079
ID: 774085  Test: aarch64 Server-dvd-iso mediakit_fileconflicts@uefi
URL: https://openqa.fedoraproject.org/tests/774085
ID: 774087  Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/774087
ID: 774096  Test: aarch64 Server-dvd-iso server_cockpit_default@uefi
URL: https://openqa.fedoraproject.org/tests/774096
ID: 774111  Test: aarch64 Server-raw_xz-raw.xz base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/774111
ID: 774115  Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/774115
ID: 774120  Test: aarch64 Workstation-raw_xz-raw.xz base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/774120
ID: 774143  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/774143
ID: 774144  Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/774144
ID: 774145  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/774145
ID: 774150  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/774150
ID: 774151  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/774151
ID: 774152  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/774152
ID: 774168  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/774168
ID: 774216  Test: aarch64 universal upgrade_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/774216
ID: 774217  Test: aarch64 universal upgrade_server_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/774217
ID: 774233  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/774233
ID: 774245  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/774245
ID: 774364  Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/774364
ID: 774370  Test: x86_64 Server-dvd-iso 

[Bug 1926738] perl-Graphics-TIFF-8 is available

[bugzilla]

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



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

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


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

[Bug 1926738] perl-Graphics-TIFF-8 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


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

[Bug 1923845] perl-Tree-Simple-VisitorFactory-0.16 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Tree-Simple-VisitorFac |perl-Tree-Simple-VisitorFac
   |tory-0.16-1.fc34|tory-0.16-1.fc34
   ||perl-Tree-Simple-VisitorFac
   ||tory-0.16-1.fc33
 Resolution|--- |ERRATA
Last Closed||2021-02-11 01:42:34



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


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

[Bug 1923810] perl-Tree-1.15 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Tree-1.15-1.fc34   |perl-Tree-1.15-1.fc34
   |perl-Tree-1.15-1.fc33   |perl-Tree-1.15-1.fc33
   ||perl-Tree-1.15-1.fc32



--- Comment #5 from Fedora Update System  ---
FEDORA-2021-cb066c1429 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  55  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4a9fc09599   
openjpeg2-2.3.1-10.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-5ecfbfc6f6   
pngcheck-2.4.0-7.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-6eebad70ee   
SDL2-2.0.14-2.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-01679b76db   
chromium-88.0.4324.150-1.el7


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

websocketpp-0.8.2-5.el7

Details about builds:



 websocketpp-0.8.2-5.el7 (FEDORA-EPEL-2021-0357d78665)
 C++ WebSocket Protocol Library

Update Information:

Build for epel7

ChangeLog:


References:

  [ 1 ] Bug #1926555 - plans for EPEL
https://bugzilla.redhat.com/show_bug.cgi?id=1926555


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

[Bug 1923810] perl-Tree-1.15 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Tree-1.15-1.fc34   |perl-Tree-1.15-1.fc34
   ||perl-Tree-1.15-1.fc33
 Resolution|--- |ERRATA
Last Closed||2021-02-11 01:42:37



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


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

[Bug 1927563] New: perl-Test-Output-1.033 is available

[bugzilla]

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

Bug ID: 1927563
   Summary: perl-Test-Output-1.033 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test-Output
  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, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.033
Current version/release in rawhide: 1.03.2-1.fc34
URL: http://search.cpan.org/dist/Test-Output/

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


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

Re: Update on Modular Obsoletes and EOL change

[Dan Čermák]

Hi Martin,

Martin Curlej  writes:

 [snip]

> It would be great if we could start a discussion about how modular
> obsoletes will be used in Fedora? Where will be they stored? Who will be
> able to change them? Just a couple of questions to get the discussion
> started. Any involvement of the Fedora community is highly appreciated.

I think for modules to be most useful, these metadata should be set by
the packager/maintainer of said module in git directly (and should
preferably not be changed after creation). I'd be also in favor of not
tying the EOL date to Fedora EOLs, as that limits the potential benefits
of modules in Fedora a lot.


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

Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream

[Debarshi Ray]

Hey,

I wanted to respond earlier, but it totally slipped my mind.

We'd totally use releasestream in Toolbox for mapping the string
"rawhide" to a numeric version:
https://github.com/containers/toolbox/issues/646

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

Re: Fwd: Orphaning some packages (C++/Gtkmm)

[Benjamin Beasley]

I have picked up cairomm. I might pick up more later, if others do not. Many 
thanks for your efforts thus far, and best wishes for your health.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: /usr/include/c++/11/type_traits:3164:1: error: template with C linkage

[Rex Dieter]

Rex Dieter wrote:

> Antonio T. sagitter wrote:
> 
>> Hi all.
>> 
>> I can't compile IceCat on Fedora 33+ since some days because of these
>> errors:
>> 
>> ...
>> /usr/include/c++/11/type_traits:3164:1: error: template with C linkage
> 
> This is impacting plasma-discover and flatpak, the latter's flatpak.h
> header will need to fixed first (I think) before plasma-discover can build
> again.

Filed flatpak bug,
https://bugzilla.redhat.com/1927439

which blocks fixing plasma-discover FTBFS

-- Rex

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

Re: git push permission denied

[Todd Zullinger]

Tony Breeds wrote:
> One annoying gotcha I hit after adding the new key to my agent was that
> many places now failed to auth as it tried each key in my agent and
> exceeded the MaxAuthTries in sshd

The IdentitiesOnly option to ssh is useful for that.  From
ssh_config(1):

   Specifies that ssh(1) should only use the configured authentication
   identity and certificate files (either the default files, or those
   explicitly configured in the ssh_config files or passed on the ssh(1)
   command-line), even if ssh-agent(1) or a PKCS11Provider or
   SecurityKeyProvider offers more identities.  The argument to this
   keyword must be yes or no (the default).  This option is intended for
   situations where ssh-agent offers many different identities.

-- 
Todd


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

glib2 2.67.3-2 seems to cause crashes with pipewire and pulse

[Marius Schwarz]

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


If 2.67.3 is installed, and audio settings get changed, after a few 
changes, mostly on the input devices, phosh is crashing.


Crashing started 2 days ago, which is exactly the time, that package 
came on the system.

Downgrading glib2 back to 2.67.1-4 from late Jan, fixed the crashes.

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

Re: Help wanted: Multiple packages with different ver-rel from one spec

[Josh Stone]

On 2/4/21 11:19 AM, Fabio Valentini wrote:
> I am aware of at least three (?) other "noteworthy" packages that have
> to deal with this (or at least, had to do something like this in the
> past):
> 
> - ruby (with the gems that are bundled with the interpreter),
> - perl (with the modules that are bundled with the interpreter), and
> - rust (with tools like cargo that are bundled with the compiler)

I got tired of dealing with sub-versions for rust tools, so they've all
just followed the primary rust version for a while now. I think this
matches user expectations anyway, since if you use the upstream builds,
they're all associated with a particular version of the rust compiler,
not typically called out as independent versions.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Proposal: EPEL9 timeline

[Stephen John Smoogen]

On Wed, 10 Feb 2021 at 14:48, Miro Hrončok  wrote:

> On 10. 02. 21 20:24, Stephen John Smoogen wrote:
> >
> >
> > On Wed, 10 Feb 2021 at 14:19, Miro Hrončok  > > wrote:
> >
> > On 10. 02. 21 19:53, Stephen John Smoogen wrote:
> >  > fedpkg-minimal
> >  > epel-release
> >  > epel-rpm-macros
> >
> >
> > Those make perfect sense to me.
> >
> >  > fedpkg
> >  > koji
> >  > bodhi
> >
> > But I don't understand why those are required. What am I missing?
> >
> >
> > A lot of EPEL developers do their development on an EL system and use
> the base
> > tools to do so. That needs fedpkg to be on that system to talk to
> koji/bodhi and
> > a host of other items. In order to get fedpkg to do that you end up
> needing
> > parts of koji and bodhi because of library needs. That requires the yak
> train.
>
> Oh, so this is only needed to make EPEL "self hosting" in a sense. So
> packagers
> can contribute to EPEL 9 from an EL 9 system.
>
> I agree that this is a valuable goal, but should this be an essential part
> of
> the initial "bootstrap"?
>
>
Well it depends on what bootstrap means. Is it 'what is needed to have a
package set to call it EPEL' or 'what are the minimal set of packages
needed for an EPEL packager to be able to work'

In the past it was enough to get enough of the package set together that
others can build and add packages to the distro. Since a LOT of packages
use fedpkg local etc for their testing/porting.. having fedpkg fully
functional was a requirement.  However that does mean extra work for things
like this which no one is working on and no one is paying anyone to work
on. So maybe the group should say it is a requirement that development is
done in Fedora instead.



> I'm asking because I know that yak train has a lot of packages, including
> some
> deprecated that I maintain in Fedora. So I'd rather see a real maintainer
> deciding to package e.g. python-nose or python-mock for EPEL 9, than a SIG
> member who is more likely to import/build it once and move on.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
>


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

[Bug 1927466] New: perl-Graphics-TIFF-9 is available

[bugzilla]

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

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



Latest upstream release: 9
Current version/release in rawhide: 8-2.fc35
URL: http://search.cpan.org/dist/Graphics-TIFF/

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


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

[EPEL-devel] Re: Proposal: EPEL9 timeline

[Miro Hrončok]

On 10. 02. 21 20:24, Stephen John Smoogen wrote:



On Wed, 10 Feb 2021 at 14:19, Miro Hrončok > wrote:


On 10. 02. 21 19:53, Stephen John Smoogen wrote:
 > fedpkg-minimal
 > epel-release
 > epel-rpm-macros


Those make perfect sense to me.

 > fedpkg
 > koji
 > bodhi

But I don't understand why those are required. What am I missing?


A lot of EPEL developers do their development on an EL system and use the base 
tools to do so. That needs fedpkg to be on that system to talk to koji/bodhi and 
a host of other items. In order to get fedpkg to do that you end up needing 
parts of koji and bodhi because of library needs. That requires the yak train.


Oh, so this is only needed to make EPEL "self hosting" in a sense. So packagers 
can contribute to EPEL 9 from an EL 9 system.


I agree that this is a valuable goal, but should this be an essential part of 
the initial "bootstrap"?


I'm asking because I know that yak train has a lot of packages, including some 
deprecated that I maintain in Fedora. So I'd rather see a real maintainer 
deciding to package e.g. python-nose or python-mock for EPEL 9, than a SIG 
member who is more likely to import/build it once and move on.


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

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Jeff Law]

On 2/10/21 11:00 AM, Miro Hrončok wrote:
> On 10. 02. 21 18:47, Ben Cotton wrote:
>> == Upgrade/compatibility impact ==
>> Problems during build can appear in multiple packages what can lead to
>> build failure, as multiple packages require autoconf-2.69 as their
>> upstream dependency. These problems have to be resolved before adding
>> autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages
>> are having problems during build, which could be caused by a problem
>> with same pattern.
>
> In absolute numbers, what is 20%? I see ~200 failures at
> https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/monitor/
> (obviously not all of them are necessarily caused by autoconf).
>
> Should this be a system-wide change instead?
Given how many packages use autoconf, I think so.

--

I've already volunteered my tester to help shake out this change.  It's
actually a really good fit because of the autoconf/LTO interactions we
had to sort out for F33/LTO.  The plan is to spin it up next week.

In simplest terms autoconf generated code to test for the existence of
certain capabilities can be optimized away completely by LTO.  This
results in autoconf incorrectly claiming certain capabilities exist. 
This can cause packages to FTBFS or to even mis-behave at runtime.

Thus it was critical to find these cases and deal with them as part of
the LTO effort.  So my tester has the ability to capture generated
config.h files across its control and test builds and will report a
failure if the generated config.h files differ (with an ability to
exclude those where timestamps and such end up in the generated config.h
files).

In the test I'm going to run the only difference between the control and
test build will be the version of autoconf.  So the failures should give
us a highly accurate picture of how autoconf-2.70 will impact the
distribution as a whole.

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

[EPEL-devel] Re: Proposal: EPEL9 timeline

[Stephen John Smoogen]

On Wed, 10 Feb 2021 at 14:24, Stephen John Smoogen  wrote:

>
>
> On Wed, 10 Feb 2021 at 14:19, Miro Hrončok  wrote:
>
>> On 10. 02. 21 19:53, Stephen John Smoogen wrote:
>> > fedpkg-minimal
>> > epel-release
>> > epel-rpm-macros
>>
>>
>> Those make perfect sense to me.
>>
>> > fedpkg
>> > koji
>> > bodhi
>>
>> But I don't understand why those are required. What am I missing?
>>
>>
> A lot of EPEL developers do their development on an EL system and use the
> base tools to do so. That needs fedpkg to be on that system to talk to
> koji/bodhi and a host of other items. In order to get fedpkg to do that you
> end up needing parts of koji and bodhi because of library needs. That
> requires the yak train.
>
>

All fedpkg-minimal is

#!/bin/bash

baseurl=http://pkgs.fedoraproject.org/repo/pkgs
pkgname=$(pwd| sed -e 's|^/.*/||g')
cat sources | while read line; do
tarball=$(echo  $line| sed -e 's|.* ||g')
md5sum=$(echo $line| sed -e 's| .*||g')
wget $baseurl/$pkgname/$tarball/$md5sum/$tarball
done

it does not do builds, it does not have any of the 'local' tools developers
expect and so the full fedpkg is what is expected for a person to have.





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

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

Re: git push permission denied

[Cătălin George Feștilă]

also, you need to start the sshd service ...

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

[EPEL-devel] Re: Proposal: EPEL9 timeline

[Stephen John Smoogen]

On Wed, 10 Feb 2021 at 14:19, Miro Hrončok  wrote:

> On 10. 02. 21 19:53, Stephen John Smoogen wrote:
> > fedpkg-minimal
> > epel-release
> > epel-rpm-macros
>
>
> Those make perfect sense to me.
>
> > fedpkg
> > koji
> > bodhi
>
> But I don't understand why those are required. What am I missing?
>
>
A lot of EPEL developers do their development on an EL system and use the
base tools to do so. That needs fedpkg to be on that system to talk to
koji/bodhi and a host of other items. In order to get fedpkg to do that you
end up needing parts of koji and bodhi because of library needs. That
requires the yak train.


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


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

[EPEL-devel] Re: Proposal: EPEL9 timeline

[Miro Hrončok]

On 10. 02. 21 19:53, Stephen John Smoogen wrote:

fedpkg-minimal
epel-release
epel-rpm-macros



Those make perfect sense to me.


fedpkg
koji
bodhi


But I don't understand why those are required. What am I missing?

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

[EPEL-devel] Re: Proposal: EPEL9 timeline

[Stephen John Smoogen]

On Mon, 8 Feb 2021 at 17:36, Troy Dawson  wrote:

> On Mon, Feb 8, 2021 at 11:50 AM Kevin Fenzi  wrote:
> >
> > On Mon, Feb 08, 2021 at 08:19:24AM -0500, Stephen John Smoogen wrote:
> > > There is a little nuance here. In order to get the repository going,
> we had
> > > to 'mass-branch' about 40 or so packages. fedpkg and some other items
> > > require quite a few packages which all have to be done at once. Without
> > > those you can't build anything else to put into EPEL... so I would say
> that
> > > EPEL is the specific set of packages in order to get a minimal
> repository
> > > working in the Fedora Build System. Everything else is just extras
> people
> > > add to it.
> >
> > That is an excellent point. Perhaps we should try and identify those
> > packages and see if we can just add epel-packagers sig to all of them?
> > Do we have any record of those?
> >
> If they were the packages that I built they were
> fedpkg
> koji
> bodhi
>
> And then all the packages needed to build them, that weren't in RHEL.
> But there might have been others that Smooge did.
>
>
For EL8 it was a larger pile of yaks than what tdawson had originally.  I
found all the src.rpms from that timeframe (and others have been updated
since then so would need to be included also). Looking at the initial EPEL
build dates of 2019-07, there are still about 124 packages which were in
that grouping because some things had dropped out of beta and other things
needed a long line of bootstrapping

That said I can try to replicate on a weekend.

fedpkg-minimal
fedpkg
koji
bodhi
epel-release
epel-rpm-macros


I can re

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

Re: ocamlx() deps changed by mass rebuild

[Jerry James]

Since the OCaml 4.12.0 release is near, I thought I would report on a
few changes from my previous message.

On Tue, Feb 2, 2021 at 9:08 AM Jerry James  wrote:
> Thanks for handling the rebuilds.  I want to note that there be a few
> dragons lurking in wait for the ocaml 4.12.0 release.  I maintain some
> packages that need to be updated for 4.12.0.  The problematic one is
> ocaml-ppxlib.  It is currently on version 0.15.0.  The latest upstream
> version is 0.21.0.  All versions > 0.15.0 require
> ocaml-migrate-parsetree >= 2.0.  The 2.x ocaml-migrate-parsetree
> versions break ocaml-ppx-tools-versioned.  There is ongoing effort to
> move all ocaml-ppx-tools-versioned consumers over to ocaml-ppxlib, but
> it isn't quite done.  To avoid breaking Fedora packages, this is what
> needs to be done, in approximate package build order:

Due to some upstream activity, this is what the list looks like now.

- ocaml-base: 0.14.0 -> 0.14.1
- ocaml-migrate-parsetree: 1.8.0 -> 2.1.0
- ocaml-ppxlib: 0.15.0 -> 0.22.0
- ocaml-bisect-ppx: 2.5.0 -> 2.6.0
- ocaml-tyxml: apply this pull request to switch to ppxlib:
https://github.com/ocsigen/tyxml/pull/271
- ocaml-lwt: 5.3.0 -> 5.4.0
- ocaml-ppx-deriving: 5.1 -> 5.2.1
- ocaml-ppx-optcomp: 0.14.0 -> 0.14.1
- ocaml-ppx-sexp-conv: 0.14.1 -> 0.14.2
- ocaml-sedlex: 2.2 -> 2.3
- ocaml-ppx-custom-printf: 0.14.0 -> 0.14.1
- ocaml-ppx-fields-conv: 0.14.1 -> 0.14.2
- Retire ocaml-ppx-tools-versioned

I have done some test builds to flush out problems.  The ocaml-tyxml
pull request cannot be applied as is.  First, it doesn't apply cleanly
due to commits made after the 4.4.0 release.  Second, it doesn't work
due to changes made to ppxlib after the pull request was made.  I've
modified the pull request into a patch that fixes both issues.  I am
concerned that that pull request has not been updated since last July.

The ocaml-lwt 5.4.0 release adds a dependency on the "luv" library,
which we do not have in Fedora.  Getting it means adding a handful of
new ocaml packages, namely:

- bigarray-compat: https://bugzilla.redhat.com/show_bug.cgi?id=1927441
- integers: https://bugzilla.redhat.com/show_bug.cgi?id=1927442
- ctypes: https://bugzilla.redhat.com/show_bug.cgi?id=1927443
- luv: https://bugzilla.redhat.com/show_bug.cgi?id=1927444

Also, since ocaml-ppxlib is becoming a dependency of ocaml-txyml,
ocaml-ppxlib and all of its dependencies will become transitive
dependencies of ocaml-odoc, which means we cannot build documentation
for those packages with odoc without introducing circularities.  I'll
add "%bcond_with doc" or something similar to handle this, unless
someone has a better idea.

Richard, what's the best way to handle all of this?  I can open pull
requests on all of the above packages, so you only have to merge them
before starting the ocaml 4.12 builds.  Or, since I am the primary
maintainer for most of them, I can simply push to git when you say you
are ready to start.  Let me know what works best for you.
--
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Miro Hrončok]

On 10. 02. 21 18:47, Ben Cotton wrote:

== Upgrade/compatibility impact ==
Problems during build can appear in multiple packages what can lead to
build failure, as multiple packages require autoconf-2.69 as their
upstream dependency. These problems have to be resolved before adding
autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages
are having problems during build, which could be caused by a problem
with same pattern.


In absolute numbers, what is 20%? I see ~200 failures at 
https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/monitor/ (obviously 
not all of them are necessarily caused by autoconf).


Should this be a system-wide change instead?

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

Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ben Cotton]

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

== Summary ==
Autoconf upgrade from version 2.69 to the last upstream version 2.71 in Fedora.

== Owner ==
* Name: [[User:odubaj| Ondrej Dubaj]]
* Email: odu...@redhat.com

== Detailed Description ==
Upgrading autoconf from version 2.69 to version 2.71 according to new
upstream release. Version 2.70 is skipped due to multiple ABI
incompatibilities, where some of them were fixed in version 2.71.
Years of development differ these two releases, so problems are
expected.

This change might easily cause fails during builds of multiple
packages, as some of them still require autoconf-2.69. This step must
be properly discussed with maintainers of dependent packages, which
should forward this change proposal to their upstream projects.


== Benefit to Fedora ==
Brings a stable and up-to-date version of autoconf according to
upsteam release. It is expected, that in the future many upstream
development teams will use autoconf-2.71 as their default builder, so
Fedora will be prepared for such a step.

== Scope ==
* Proposal owners:
**Prepare autoconf-2.71 as RPM package for Fedora Rawhide
**Check software that requires `autoconf` or `autoconf-2.69` and
rebuild it with autoconf-2.71
**Build autoconf-2.71 to Rawhide in a side-tag
(https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag)
**Rebuild depended packages with autoconf-2.71 in the side-tag
**Merge the side-tag to Rawhide

* Other developers:
**Check if their packages can be build with autoconf-2.71
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
Problems during build can appear in multiple packages what can lead to
build failure, as multiple packages require autoconf-2.69 as their
upstream dependency. These problems have to be resolved before adding
autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages
are having problems during build, which could be caused by a problem
with same pattern.

== How To Test ==
Rebuilding your packages with autoconf-2.71 dependency in copr
(https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/).

Mass rebuild of dependent packages in a side tag.

== User Experience ==
Users will be able to use the newer version (2.71) of autoconf, and
building packages with autoconf-2.69 won't be available, as it won't
be present on the specific fedora version. This can affect 3rd partly
packages, which are not part of Fedora.

== Dependencies ==
Hundreds of packages have build dependency on autoconf, therefore it
is a huge step forward for Fedora, what should be properly discussed
and tested. List of dependent packages with their ability to be built
with autoconf-2.71 can be found in the given copr project
(https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/)

We should also look at dependent packages of `libtool` and `automake`
(other critical autotools packages), as there might be some
incompatibilities with the new autoconf version.

== Contingency Plan ==
* Contingency mechanism: moving this change to Fedora 36, if not
successfully finished until Fedora 35 branching from Rawhide
* Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)
* Blocks release? No

== Documentation ==

Latest autoconf documentation:
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/index.html

== Release Notes ==
Release notes for autoconf-2.70:
https://lists.gnu.org/archive/html/autotools-announce/2020-12/msg1.html

Release notes for autoconf-2.71:
https://lists.gnu.org/archive/html/autotools-announce/2021-01/msg0.html


-- 
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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ben Cotton]

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

== Summary ==
Autoconf upgrade from version 2.69 to the last upstream version 2.71 in Fedora.

== Owner ==
* Name: [[User:odubaj| Ondrej Dubaj]]
* Email: odu...@redhat.com

== Detailed Description ==
Upgrading autoconf from version 2.69 to version 2.71 according to new
upstream release. Version 2.70 is skipped due to multiple ABI
incompatibilities, where some of them were fixed in version 2.71.
Years of development differ these two releases, so problems are
expected.

This change might easily cause fails during builds of multiple
packages, as some of them still require autoconf-2.69. This step must
be properly discussed with maintainers of dependent packages, which
should forward this change proposal to their upstream projects.


== Benefit to Fedora ==
Brings a stable and up-to-date version of autoconf according to
upsteam release. It is expected, that in the future many upstream
development teams will use autoconf-2.71 as their default builder, so
Fedora will be prepared for such a step.

== Scope ==
* Proposal owners:
**Prepare autoconf-2.71 as RPM package for Fedora Rawhide
**Check software that requires `autoconf` or `autoconf-2.69` and
rebuild it with autoconf-2.71
**Build autoconf-2.71 to Rawhide in a side-tag
(https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag)
**Rebuild depended packages with autoconf-2.71 in the side-tag
**Merge the side-tag to Rawhide

* Other developers:
**Check if their packages can be build with autoconf-2.71
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
Problems during build can appear in multiple packages what can lead to
build failure, as multiple packages require autoconf-2.69 as their
upstream dependency. These problems have to be resolved before adding
autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages
are having problems during build, which could be caused by a problem
with same pattern.

== How To Test ==
Rebuilding your packages with autoconf-2.71 dependency in copr
(https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/).

Mass rebuild of dependent packages in a side tag.

== User Experience ==
Users will be able to use the newer version (2.71) of autoconf, and
building packages with autoconf-2.69 won't be available, as it won't
be present on the specific fedora version. This can affect 3rd partly
packages, which are not part of Fedora.

== Dependencies ==
Hundreds of packages have build dependency on autoconf, therefore it
is a huge step forward for Fedora, what should be properly discussed
and tested. List of dependent packages with their ability to be built
with autoconf-2.71 can be found in the given copr project
(https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/)

We should also look at dependent packages of `libtool` and `automake`
(other critical autotools packages), as there might be some
incompatibilities with the new autoconf version.

== Contingency Plan ==
* Contingency mechanism: moving this change to Fedora 36, if not
successfully finished until Fedora 35 branching from Rawhide
* Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)
* Blocks release? No

== Documentation ==

Latest autoconf documentation:
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/index.html

== Release Notes ==
Release notes for autoconf-2.70:
https://lists.gnu.org/archive/html/autotools-announce/2020-12/msg1.html

Release notes for autoconf-2.71:
https://lists.gnu.org/archive/html/autotools-announce/2021-01/msg0.html


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

License field corrections: agenda, appeditor, dippi, harvey, notejot, sequeler, gaupol

[Benjamin Beasley]

The license for agenda has been corrected from “GPLv3” to “GPLv3+ and GPLv2+ 
and LGPLv2+ and CC0”.

The license for appeditor has been corrected from “LGPLv2+” to “GPLv3 and 
LGPLv2+ and CC0”.

The license for dippi has been corrected from “GPLv3” to “GPLv3+ and GPLv2+ and 
CC0”.

The license for harvey has been corrected from “GPLv3” to “GPLv3+ and GPLv2+ 
and CC0”.

The license for notejot has been corrected from “GPLv3” to “GPLv3+ and GPLv2+ 
and CC0”.

The license for sequeler has been corrected from “GPLv3” to “GPLv3+ and GPLv2+ 
and LGPLv2+ and CC0”.

The license for gaupol (but not python3-aeidon) has been corrected from 
“GPLv3+” to “GPLv3+ and CC0”.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Kevin Fenzi]

On Thu, Feb 04, 2021 at 12:24:34PM +0100, Michal Schorm wrote:
> I checked out https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> 
> And in the section "Phase2" I wanted to check out the scripts in
> "Release engineering:" sub-section.
> Surprisingly (not surprisingly) the links are dead now.

These were since fixed. Thanks wiki editing folks. :) 

> Will you also go through all https://fedoraproject.org/wiki links and
> fix them too ?
> 

There's no plan for that, but we did add a http redirect for old master
links to redirect to rawhide. Others should update links as time
permits. 

kevin
--
> 
> --
> 
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
> 
> --
> 
> On Wed, Feb 3, 2021 at 12:09 AM Kevin Fenzi  wrote:
> >
> > Greetings everyone.
> >
> > We finally have everything in place and hopefully tested to make the
> > switch tomorrow from master to rawhide/main branches for
> > src.fedoraproject.org.
> >
> > At 13:30UTC we will adjust pagure to reject pushes to 'master' and then
> > will be moving all the branches over to rawhide/main. As soon as all
> > packages are done, we will be adjusting pdc/hooks/existing pr's.
> >
> > We will be sending an additional email once changes are complete and
> > hopefully any downtime will be limited.
> >
> > Once the change is completed you will want to checkout rawhide/main
> > instead of master and update/recreate any existing forks you have.
> >
> > See
> > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> > for more information.
> >
> > Thanks,
> >
> > kevin
> > ___
> > 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


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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Kevin Fenzi]

On Wed, Feb 10, 2021 at 05:19:15PM +, Ian McInerney wrote:
> On Wed, Feb 10, 2021 at 5:04 PM Pierre-Yves Chibon 
> wrote:
> 
> > On Wed, Feb 10, 2021 at 09:59:24AM -0500, Matthew Miller wrote:
> > > On Wed, Feb 10, 2021 at 03:50:06PM +0100, Fabio Valentini wrote:
> > > > This is something we explicitly did not want on the git level, which
> > > > is why there is a main → rawhide link, but no master → rawhide link.
> > > > But it could possibly be done on the HTTP level in pagure, with a
> > redirect?
> > >
> > > Yeah, if not too much work this would be really beneficial. Lots of
> > existing
> > > links out there.
> >
> > We've added redirects to links pointing to files in the 'master' branch to
> > the
> > new default branch.
> > For example:
> > https://src.fedoraproject.org/rpms/klickety/blob/master/f/klickety.spec#_68
> > will redirect you to
> >
> > https://src.fedoraproject.org/rpms/klickety//blob/rawhide/f/klickety.spec#_68
> >
> > This should help with some of the links.
> >
> >
> > Pierre
> >
> 
> Thanks! This is exactly what I was hoping we could implement. (and it is
> just slightly scary that the example link you show is actually the link I
> had followed from an upstream bug report that led me to finding the lack of
> redirect last night ;) ).

It was requested a few days ago, we just hadn't implemented it yet. 
(Until this morning). 

Thanks pingou!

kevin


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

Re: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Ian McInerney]

On Wed, Feb 10, 2021 at 5:04 PM Pierre-Yves Chibon 
wrote:

> On Wed, Feb 10, 2021 at 09:59:24AM -0500, Matthew Miller wrote:
> > On Wed, Feb 10, 2021 at 03:50:06PM +0100, Fabio Valentini wrote:
> > > This is something we explicitly did not want on the git level, which
> > > is why there is a main → rawhide link, but no master → rawhide link.
> > > But it could possibly be done on the HTTP level in pagure, with a
> redirect?
> >
> > Yeah, if not too much work this would be really beneficial. Lots of
> existing
> > links out there.
>
> We've added redirects to links pointing to files in the 'master' branch to
> the
> new default branch.
> For example:
> https://src.fedoraproject.org/rpms/klickety/blob/master/f/klickety.spec#_68
> will redirect you to
>
> https://src.fedoraproject.org/rpms/klickety//blob/rawhide/f/klickety.spec#_68
>
> This should help with some of the links.
>
>
> Pierre
>

Thanks! This is exactly what I was hoping we could implement. (and it is
just slightly scary that the example link you show is actually the link I
had followed from an upstream bug report that led me to finding the lack of
redirect last night ;) ).

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

Re: /usr/include/c++/11/type_traits:3164:1: error: template with C linkage

[Rex Dieter]

Antonio T. sagitter wrote:

> Hi all.
> 
> I can't compile IceCat on Fedora 33+ since some days because of these
> errors:
> 
> ...
> /usr/include/c++/11/type_traits:3164:1: error: template with C linkage

This is impacting plasma-discover and flatpak, the latter's flatpak.h header 
will need to fixed first (I think) before plasma-discover can build again.

I already fixed appstream, pulling in upstream fix 
https://github.com/ximion/appstream/commit/8a179f14619103247e4a14d96ea03c358d9c1492

Needless to say, this is a pain (that's about the best constructive 
criticism I can give right now).

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Fwd: Orphaning some packages (C++/Gtkmm)

[Haïkel]

Le mer. 10 févr. 2021 à 18:10, Zbigniew Jędrzejewski-Szmek
 a écrit :
>
> Hi,
>
> In case you didn't see bcotton's mail about pp status, please do.
>
> Zbyszek

I did, it helped deciding to actively reduce the scope.

Regards,
H.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Fwd: Orphaning some packages (C++/Gtkmm)

[Zbigniew Jędrzejewski-Szmek]

Hi,

In case you didn't see bcotton's mail about pp status, please do.

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

Fwd: Orphaning some packages (C++/Gtkmm)

[Haïkel]

Hello,

due to long-standing health issues, I'd like to focus on a smaller set
of packages and continue mentoring new packagers which helped me to
stay afloat during grim times.
Here's a list of packages that have no co-maintainers and are required
for other projects.
- cairomm
- gconfmm26
- libglademm24
-  gtkmm24
- gstreamermm
- glom
- goocanvasmm2 (only used by glom)

should not be picked up:
- libnotifymm
- plotmm

I might update this list, as I'll focus my attention into getting better.
Most other packages are co-maintained by either SIGs or
co-maintainers, but if you need access to a package that I maintain,
you can directly mail me.

Regards,
H.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Pierre-Yves Chibon]

On Wed, Feb 10, 2021 at 09:59:24AM -0500, Matthew Miller wrote:
> On Wed, Feb 10, 2021 at 03:50:06PM +0100, Fabio Valentini wrote:
> > This is something we explicitly did not want on the git level, which
> > is why there is a main → rawhide link, but no master → rawhide link.
> > But it could possibly be done on the HTTP level in pagure, with a redirect?
> 
> Yeah, if not too much work this would be really beneficial. Lots of existing
> links out there.

We've added redirects to links pointing to files in the 'master' branch to the
new default branch.
For example:
https://src.fedoraproject.org/rpms/klickety/blob/master/f/klickety.spec#_68 
will redirect you to
https://src.fedoraproject.org/rpms/klickety//blob/rawhide/f/klickety.spec#_68

This should help with some of the links.


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

Re: [heads-up] soname version bump for evolution-data-server in rawhide

[Milan Crha]

On Wed, 2021-02-10 at 17:48 +0100, Fabio Valentini wrote:
> Yes, you'll need two side tags and build everything twice. f34 and
> f35/rawhide are separate now.
> I can also use my provenpackager powers to help you with that, if
> needed.

Hi,
okay, thanks a lot. I'll let you know if I face any issue. I surely do
not have commit rights for all the dependencies, but I'll see which
those are when I get to it, as some packages had been orphaned
recently. I'll left the two packages you mentioned up to you.

As promised, I'll update this thread once I've the side tags ready,
with compiled evolution-data-server.
Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1927271] perl-DBD-CSV-0.58 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-DBD-CSV-0.58-1.fc34
   ||perl-DBD-CSV-0.58-1.fc35
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2021-02-10 16:54:40



--- Comment #1 from Paul Howarth  ---
Rawhide:
https://koji.fedoraproject.org/koji/taskinfo?taskID=61712657

F34:
https://koji.fedoraproject.org/koji/taskinfo?taskID=61713149


-- 
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: [heads-up] soname version bump for evolution-data-server in rawhide

[Fabio Valentini]

On Wed, Feb 10, 2021 at 5:42 PM Milan Crha  wrote:
>
> On Wed, 2021-02-10 at 15:53 +0100, Fabio Valentini wrote:
> > On Wed, Feb 10, 2021 at 3:32 PM Milan Crha wrote:
> > > I'll create the side tag on Friday, ...
>
> Hi,
> this might be a stupid question, but I'll ask anyway: since there are
> f34 branches created already, should I create two side tags, one for
> the rawhide and one for the f34 branch? I guess I should. It'll double
> the work, somehow, but that's just due to a bad timing of the change.

Yes, you'll need two side tags and build everything twice. f34 and
f35/rawhide are separate now.
I can also use my provenpackager powers to help you with that, if needed.

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: [heads-up] soname version bump for evolution-data-server in rawhide

[Milan Crha]

On Wed, 2021-02-10 at 15:53 +0100, Fabio Valentini wrote:
> On Wed, Feb 10, 2021 at 3:32 PM Milan Crha wrote:
> > I'll create the side tag on Friday, ...

Hi,
this might be a stupid question, but I'll ask anyway: since there are
f34 branches created already, should I create two side tags, one for
the rawhide and one for the f34 branch? I guess I should. It'll double
the work, somehow, but that's just due to a bad timing of the change.
Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Mass Branching

[Matthew Miller]

On Wed, Feb 10, 2021 at 10:03:40AM -0500, Ben Cotton wrote:
> > I'll forward this link to Ben as Fedora Program Manager so he can update the
> > termionology in the schedule.
> Already done a release or two ago.

I guess it was me who didn't notice. :) I suppose it'll catch on more over
time. 

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

Stale provenpackagers to be removed from group

[Ben Cotton]

In accordance with the new FESCo policy[1] the following
provenpackagers will be submitted for removal in two weeks based on a
lack of builds submitted in the last six months. If you received this
directly, you can reply off-list to indicate you believe you should
still have provenpackager status.

This is the first time we have done a regular audit of the
provenpackagers group, so please be patient with any hiccups in the
process. This will be done regularly at the branch point in each
release.

[1] https://pagure.io/fesco/issue/2549

Checked 252 provenpackagers
The following 117 provenpackagers have not submitted a Koji build
since at least 2020-08-05 00:00:00:
alexl
alexlan
arg
athimm
atkac
ausil
averi
awjb
bernie
bkabrda
bpepple
c4chris
caillon
cebbert
chitlesh
codeblock
cweyl
cwickert
davej
dbhole
dcbw
denis
dgregor
dmalcolm
drago01
dsd
dwmw2
echevemaster
ecik
ensc
epienbro
fitzsim
gemi
hguemar
hubbitus
huzaifas
ianweller
iarnell
ilianaw
ishcherb
ivazquez
ixs
jcapik
jhogarth
jkeating
johnp
jpo
jreznik
jspaleta
jstanley
jsteffan
jwilson
kanarip
kasal
katzj
kay
ke4qqq
kengert
kyle
kylev
laxathom
lennart
lkundrak
lmacken
lutter
markmc
maxamillion
mbarnes
mclasen
mef
michich
mjakubicek
mjg59
mmahut
mmaslano
mmcgrath
msimacek
mstuchli
nalin
nim
npmccallum
overholt
paragn
patches
pertusus
pjp
praveenp
pravins
rakesh
rkuska
rvokal
s4504kr
scop
sdake
sdz
skvidal
smooge
sochotni
stahnma
steve
sundaram
thias
thomasvs
thozza
till
tomspur
toshio
tradej
tremble
tstclair
tuxbrewr
vakwetu
vicodan
wart
willb
wolfy
wtogami

The following 1 provenpackagers do not exist in Koji:
gdk


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

Stale provenpackagers to be removed from group

[Ben Cotton]

In accordance with the new FESCo policy[1] the following
provenpackagers will be submitted for removal in two weeks based on a
lack of builds submitted in the last six months. If you received this
directly, you can reply off-list to indicate you believe you should
still have provenpackager status.

This is the first time we have done a regular audit of the
provenpackagers group, so please be patient with any hiccups in the
process. This will be done regularly at the branch point in each
release.

[1] https://pagure.io/fesco/issue/2549

Checked 252 provenpackagers
The following 117 provenpackagers have not submitted a Koji build
since at least 2020-08-05 00:00:00:
alexl
alexlan
arg
athimm
atkac
ausil
averi
awjb
bernie
bkabrda
bpepple
c4chris
caillon
cebbert
chitlesh
codeblock
cweyl
cwickert
davej
dbhole
dcbw
denis
dgregor
dmalcolm
drago01
dsd
dwmw2
echevemaster
ecik
ensc
epienbro
fitzsim
gemi
hguemar
hubbitus
huzaifas
ianweller
iarnell
ilianaw
ishcherb
ivazquez
ixs
jcapik
jhogarth
jkeating
johnp
jpo
jreznik
jspaleta
jstanley
jsteffan
jwilson
kanarip
kasal
katzj
kay
ke4qqq
kengert
kyle
kylev
laxathom
lennart
lkundrak
lmacken
lutter
markmc
maxamillion
mbarnes
mclasen
mef
michich
mjakubicek
mjg59
mmahut
mmaslano
mmcgrath
msimacek
mstuchli
nalin
nim
npmccallum
overholt
paragn
patches
pertusus
pjp
praveenp
pravins
rakesh
rkuska
rvokal
s4504kr
scop
sdake
sdz
skvidal
smooge
sochotni
stahnma
steve
sundaram
thias
thomasvs
thozza
till
tomspur
toshio
tradej
tremble
tstclair
tuxbrewr
vakwetu
vicodan
wart
willb
wolfy
wtogami

The following 1 provenpackagers do not exist in Koji:
gdk


-- 
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: Schedule for Wednesday's FESCo Meeting (2021-02-10)

[Zbigniew Jędrzejewski-Szmek]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-02-10/fesco.2021-02-10-15.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-02-10/fesco.2021-02-10-15.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-02-10/fesco.2021-02-10-15.00.log.html

Meeting summary
---
* init process  (zbyszek, 15:00:27)

* #2572 Proposal: Abstain (0) votes should be split evenly between +1
  and -1 votes  (zbyszek, 15:03:49)
  * AGREED: REJECTED (+5, 0, 0)  (zbyszek, 15:09:35)

* Next week's chair  (zbyszek, 15:09:40)
  * ACTION: dcantrell will chair next meeting  (zbyszek, 15:10:54)

* Open Floor  (zbyszek, 15:10:58)
  * f34 branching is done, branched compose syncing now.  (nirik,
15:12:50)
  * LINK:
https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/
(sgallagh, 15:22:59)
  * LINK:

https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=fedora-systemd-request
(zbyszek, 15:23:39)
  * LINK: https://www.youtube.com/watch?v=lGOofzZOyl8   (dcantrell,
15:34:12)

Meeting ended at 15:37:37 UTC.


Action Items

* dcantrell will chair next meeting

People Present (lines said)
---
* zbyszek (54)
* sgallagh (28)
* zodbot (18)
* King_InuYasha (16)
* dcantrell (15)
* nirik (12)
* decathorpe (11)
* bcotton (7)
* mhroncok (4)
* cverna (3)
* ignatenkobrain (0)
* Conan_Kudo (0)
* Eighth_Doctor (0)
* Sir_Gallantmon (0)
* Son_Goku (0)
* Pharaoh_Atem (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

Re: [F34] wait-repo task has been opened for approx 2 hours

[Miro Hrončok]

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

You need a buildroot override, but the bodhi CLI will tell you:

"Invalid build.  It must be tagged as either candidate or testing."

But the web UI allows it :/


Correction. This part is not true, I had a typo in the build NEVR.

--
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: [F34] wait-repo task has been opened for approx 2 hours

[Miro Hrončok]

On 10. 02. 21 9:09, Zdenek Dohnal wrote:

Hi all,

I have started foomatic-db+foomatic chainbuild this morning for F34 and
it has been opened for 2 hours till now. Is it expected?

IIUC I don't need a buildroot override yet, since F34 hasn't been
enabled in bodhi. So the process should be the same as in rawhide.

Does anyone know what's going on?


The first build is left in pending until the freeze is over:

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#post-branch-freeze

https://bodhi.fedoraproject.org/updates/FEDORA-2021-2e2e2883c5

You need a buildroot override, but the bodhi CLI will tell you:

"Invalid build.  It must be tagged as either candidate or testing."

But the web UI allows it :/

Tip: You could have avoided the problem entirely by using side tags:

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages

--
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: [heads-up] soname version bump for evolution-data-server in rawhide

[Milan Crha]

On Wed, 2021-02-10 at 15:53 +0100, Fabio Valentini wrote:
> I'll build elementary-calendar + wingpanel-indicator-datetime once
> the side tag is ready, if you want.

Hi,
it'll help, yes. Thanks.

> Do you expect any of the listed packages to break because of the
> aforementioned API changes?

The API changes are on the WebDAV related code, namely functions
e_webdav_discover_content_get_selected(), e_webdav_resource_new().
The ABI changes will work just by a rebuild. I guess only a few
projects use either of the two functions (the former uses Evolution).
Thanks and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Mass Branching

[Ben Cotton]

On Wed, Feb 10, 2021 at 9:59 AM Matthew Miller  wrote:
>
> I'll forward this link to Ben as Fedora Program Manager so he can update the
> termionology in the schedule.
>
Already done a release or two ago.

-- 
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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Matthew Miller]

On Wed, Feb 10, 2021 at 03:50:06PM +0100, Fabio Valentini wrote:
> This is something we explicitly did not want on the git level, which
> is why there is a main → rawhide link, but no master → rawhide link.
> But it could possibly be done on the HTTP level in pagure, with a redirect?

Yeah, if not too much work this would be really beneficial. Lots of existing
links out there.

-- 
Matthew Miller

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

Re: Fedora 34 Mass Branching

[Matthew Miller]

On Wed, Feb 10, 2021 at 12:41:42AM +0100, Miro Hrončok wrote:
> This has been discussed at lengths and already solved.

This is the research scientist's definition of "already solved". :)

> Updates-testing Activation
> See 
> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updates-testing-activation

I'll forward this link to Ben as Fedora Program Manager so he can update the
termionology in the schedule.

-- 
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: [heads-up] soname version bump for evolution-data-server in rawhide

[Fabio Valentini]

On Wed, Feb 10, 2021 at 3:32 PM Milan Crha  wrote:
>
> Hello,
> the upcoming 3.39.2 release of the evolution-data-server contains a
> soname version bump for its libedataserver-1.2 and libedataserverui-1.2
> libraries due to API and ABI changes. The release is planned for this
> Friday. I'll build as many packages as I have commit rights to in a
> side tag and I'll merge it possibly in the middle of the next week,
> depending how things will go.
>
> I'll create the side tag on Friday, after the evolution core packages
> are released upstream and ready for the build in rawhide, and post its
> name here, thus others can run their rebuilds.
>
> The affected packages:
>
> $ dnf repoquery --whatrequires libedataserver-1.2.so* --alldeps
> almanah-0:0.12.0-6.fc34.x86_64
> bijiben-0:3.38.0-2.fc34.x86_64
> elementary-calendar-0:5.1.1-2.fc34.x86_64
> elementary-planner-1:2.6.7-2.fc34.x86_64
> evolution-0:3.39.1-2.fc34.x86_64
> evolution-chime-0:1.3-9.fc34.x86_64
> evolution-data-server-devel-0:3.39.1-3.fc34.x86_64
> evolution-data-server-tests-0:3.39.1-3.fc34.x86_64
> evolution-ews-0:3.39.1-2.fc34.x86_64
> evolution-mapi-0:3.39.1-2.fc34.x86_64
> evolution-pst-0:3.39.1-2.fc34.x86_64
> evolution-rspam-0:0.6.0-31.fc34.x86_64
> evolution-rss-1:0.3.96-5.fc34.x86_64
> evolution-spamassassin-0:3.39.1-2.fc34.x86_64
> folks-1:0.14.0-6.fc34.x86_64
> glabels-0:3.4.1-13.fc34.x86_64
> gnome-calendar-0:3.38.2-1.fc34.x86_64
> gnome-contacts-0:3.38.1-2.fc34.x86_64
> gnome-panel-0:3.38.0-2.fc34.x86_64
> gnome-phone-manager-0:0.69-34.fc34.x86_64
> gnome-shell-0:40.0~alpha.1.1-4.20210202git9ce666ac1.fc34.x86_64
> gnome-todo-0:3.28.1-11.fc34.x86_64
> syncevolution-libs-1:1.5.3-16.fc34.x86_64
> wingpanel-indicator-datetime-0:2.2.5-3.fc34.x86_64
>
> $ dnf repoquery --whatrequires libedataserverui-1.2.so* --alldeps
> elementary-calendar-0:5.1.1-2.fc34.x86_64
> evolution-0:3.39.1-2.fc34.x86_64
> evolution-chime-0:1.3-9.fc34.x86_64
> evolution-data-server-devel-0:3.39.1-3.fc34.x86_64
> evolution-ews-0:3.39.1-2.fc34.x86_64
> evolution-mapi-0:3.39.1-2.fc34.x86_64
> evolution-rspam-0:0.6.0-31.fc34.x86_64
> evolution-rss-1:0.3.96-5.fc34.x86_64
> gnome-calendar-0:3.38.2-1.fc34.x86_64
> gnome-contacts-0:3.38.1-2.fc34.x86_64
> gnome-todo-0:3.28.1-11.fc34.x86_64

Thanks for the heads-up, I'll build elementary-calendar +
wingpanel-indicator-datetime once the side tag is ready, if you want.

Do you expect any of the listed packages to break because of the
aforementioned API changes?

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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Fabio Valentini]

On Wed, Feb 10, 2021 at 3:03 PM Ian McInerney  wrote:
>
> I notice now that this change has broken web links to items in the master 
> branch of a repo - since there seems to be no forwarding to the rawhide 
> branch on the web UI. This is slightly annoying because sometimes links to 
> spec files are added in bug reports, and now those links end up on a page 
> cannot be found error. Is it possible to have a redirect from master -> 
> rawhide for the repositories that don't define a master branch on their own?

This is something we explicitly did not want on the git level, which
is why there is a main → rawhide link, but no master → rawhide link.
But it could possibly be done on the HTTP level in pagure, with a redirect?

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: dropping php-imap (was Re: Orphaned packages looking for new maintainers)

[Benson Muite]

On 2/10/21 5:00 PM, Kevin Kofler via devel wrote:

Joe Orton wrote:

In my view it makes sense to drop it from Fedora 35+ and take the pain
of disabling functionality until the various upstreams switch to
alternatives.  Hopefully Remi can comment on alternatives.


I guess https://dev.horde.org/imap_client/ would be the obvious alternative,
but Remi or other people actively involved with PHP might know more.

The real issue is probably not so much to find an alternative, but to get
all the code out there ported to it. I doubt there is a drop-in replacement
anywhere.

Maybe we should consider packaging only the C client library of uw-imap,
dropping the server? There are enough maintained IMAP servers out there.



There are a number of php-imap implementations such as:
https://github.com/barbushin/php-imap
https://github.com/Webklex/php-imap
Debian seems to just have the C client library though possibly this is 
an issue to bring up on the php mailing list since it may be worth 
updating the C client which is required by php:

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

[heads-up] soname version bump for evolution-data-server in rawhide

[Milan Crha]

Hello,
the upcoming 3.39.2 release of the evolution-data-server contains a
soname version bump for its libedataserver-1.2 and libedataserverui-1.2
libraries due to API and ABI changes. The release is planned for this
Friday. I'll build as many packages as I have commit rights to in a
side tag and I'll merge it possibly in the middle of the next week,
depending how things will go.

I'll create the side tag on Friday, after the evolution core packages
are released upstream and ready for the build in rawhide, and post its
name here, thus others can run their rebuilds.

The affected packages:

$ dnf repoquery --whatrequires libedataserver-1.2.so* --alldeps
almanah-0:0.12.0-6.fc34.x86_64
bijiben-0:3.38.0-2.fc34.x86_64
elementary-calendar-0:5.1.1-2.fc34.x86_64
elementary-planner-1:2.6.7-2.fc34.x86_64
evolution-0:3.39.1-2.fc34.x86_64
evolution-chime-0:1.3-9.fc34.x86_64
evolution-data-server-devel-0:3.39.1-3.fc34.x86_64
evolution-data-server-tests-0:3.39.1-3.fc34.x86_64
evolution-ews-0:3.39.1-2.fc34.x86_64
evolution-mapi-0:3.39.1-2.fc34.x86_64
evolution-pst-0:3.39.1-2.fc34.x86_64
evolution-rspam-0:0.6.0-31.fc34.x86_64
evolution-rss-1:0.3.96-5.fc34.x86_64
evolution-spamassassin-0:3.39.1-2.fc34.x86_64
folks-1:0.14.0-6.fc34.x86_64
glabels-0:3.4.1-13.fc34.x86_64
gnome-calendar-0:3.38.2-1.fc34.x86_64
gnome-contacts-0:3.38.1-2.fc34.x86_64
gnome-panel-0:3.38.0-2.fc34.x86_64
gnome-phone-manager-0:0.69-34.fc34.x86_64
gnome-shell-0:40.0~alpha.1.1-4.20210202git9ce666ac1.fc34.x86_64
gnome-todo-0:3.28.1-11.fc34.x86_64
syncevolution-libs-1:1.5.3-16.fc34.x86_64
wingpanel-indicator-datetime-0:2.2.5-3.fc34.x86_64

$ dnf repoquery --whatrequires libedataserverui-1.2.so* --alldeps
elementary-calendar-0:5.1.1-2.fc34.x86_64
evolution-0:3.39.1-2.fc34.x86_64
evolution-chime-0:1.3-9.fc34.x86_64
evolution-data-server-devel-0:3.39.1-3.fc34.x86_64
evolution-ews-0:3.39.1-2.fc34.x86_64
evolution-mapi-0:3.39.1-2.fc34.x86_64
evolution-rspam-0:0.6.0-31.fc34.x86_64
evolution-rss-1:0.3.96-5.fc34.x86_64
gnome-calendar-0:3.38.2-1.fc34.x86_64
gnome-contacts-0:3.38.1-2.fc34.x86_64
gnome-todo-0:3.28.1-11.fc34.x86_64

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: /usr/include/c++/11/type_traits:3164:1: error: template with C linkage

[Florian Weimer]

* Kevin Kofler via devel:

> Stephan Bergmann wrote:
>> Note that wrapping the header include in an extern declaration violates
>> C++ standard requirements.  ("A translation unit shall include a header
>> only outside of any declaration or definition", [using.headers]/3)
>
> Yet, it is absolutely necessary for many C library headers that do not 
> support C++ out of the box.
>
> I assume it was even the case for that particular GLib header at some point, 
> or we would not have so many projects #including it in an extern "C" block.

Or system headers included by glib headers.  I assume that glib has been
doing that properly for a long time, but it doesn't wrap system header
includes in this way.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: src.fedoraproject.org branch conversion to rawhide/main tomorrow

[Ian McInerney]

I notice now that this change has broken web links to items in the master
branch of a repo - since there seems to be no forwarding to the rawhide
branch on the web UI. This is slightly annoying because sometimes links to
spec files are added in bug reports, and now those links end up on a page
cannot be found error. Is it possible to have a redirect from master ->
rawhide for the repositories that don't define a master branch on their own?

-Ian

On Tue, Feb 2, 2021 at 11:09 PM Kevin Fenzi  wrote:

> Greetings everyone.
>
> We finally have everything in place and hopefully tested to make the
> switch tomorrow from master to rawhide/main branches for
> src.fedoraproject.org.
>
> At 13:30UTC we will adjust pagure to reject pushes to 'master' and then
> will be moving all the branches over to rawhide/main. As soon as all
> packages are done, we will be adjusting pdc/hooks/existing pr's.
>
> We will be sending an additional email once changes are complete and
> hopefully any downtime will be limited.
>
> Once the change is completed you will want to checkout rawhide/main
> instead of master and update/recreate any existing forks you have.
>
> See
> https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> for more information.
>
> Thanks,
>
> kevin
> ___
> 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: dropping php-imap (was Re: Orphaned packages looking for new maintainers)

[Kevin Kofler via devel]

Joe Orton wrote:
> In my view it makes sense to drop it from Fedora 35+ and take the pain
> of disabling functionality until the various upstreams switch to
> alternatives.  Hopefully Remi can comment on alternatives.

I guess https://dev.horde.org/imap_client/ would be the obvious alternative, 
but Remi or other people actively involved with PHP might know more.

The real issue is probably not so much to find an alternative, but to get 
all the code out there ported to it. I doubt there is a drop-in replacement 
anywhere.

Maybe we should consider packaging only the C client library of uw-imap, 
dropping the server? There are enough maintained IMAP servers out there.

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

Re: /usr/include/c++/11/type_traits:3164:1: error: template with C linkage

[Kevin Kofler via devel]

Stephan Bergmann wrote:
> Note that wrapping the header include in an extern declaration violates
> C++ standard requirements.  ("A translation unit shall include a header
> only outside of any declaration or definition", [using.headers]/3)

Yet, it is absolutely necessary for many C library headers that do not 
support C++ out of the box.

I assume it was even the case for that particular GLib header at some point, 
or we would not have so many projects #including it in an extern "C" block.

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

Re: Fedora 34 Mass Branching

[Pavel Raiskup]

On Wednesday, February 10, 2021 12:29:51 AM CET Kevin Fenzi wrote:
> On Tue, Feb 09, 2021 at 06:19:41PM -0500, Mohan Boddu wrote:
> > On Mon, Feb 8, 2021 at 7:18 PM Petr Menšík  wrote:
> > >
> > > Hi,
> > >
> > > I were unable to find time in the schedule, at which the new F35 GPG key
> > > would be activated to sign new builds.
> > 
> > It will be done a week before mass branching, but we are thinking of
> > doing it a bit earlier to give more time.
> 
> I think we should make the f36 key right now and add it to fedora-repos
> and push it out to all branches. Then, when we get to f35 branching, we
> make the f37 key (ie, we stay 6 months ahead). 
> 
> This way everyone has the new key already and there's no scrambling. 
> 
> (or this week, doesn't have to be today, just soon)

Yes please!  Something along those lines was proposed before, because it
significantly eases mock maintenance during the branching period.  E.g.
now, at the time of F34 branching we already have released
mock-core-configs (check updates-testing) with new F35 configuration and
everything should be working.

Sure, temporarily, the fedora-34-x86_64 chroot builds against 34 repos
(still equivalent to rawhide), fedora-35-x86_64 config is symlink to
rawhide, and builds against rawhide (still f34).  So the only thing users
will observe that 'fedora-rawhide-*' and 'fedora-35-*' are temporarily
producing RPMs with fc34 %dist tag and this will automatically change once
the mirrors are updated.

It works now because the gpg keys have been generated a bit in advance for
a few last fedora releases (in copr team we try to notify administrators
to do that), but having it 6 months in advance will be better (less rush).
I think we should dump this to the branching policy/howto documents so we
don't have to manually track that.  Finally, if we could document there
that updated distribution-gpg-keys and mock-core-configs packages should
be released, it would be an awesome help ...

Pavel


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

Re: Fedora 34 Mass Branching

[Mohan Boddu]

Hi All,

Fedora 34 has now been branched, please be sure to do a git pull
--rebase to pick up the new branch, as an additional reminder
rawhide/f35 has been completely isolated from previous releases, so
this means that anything you do for f34 you also have to do in the
rawhide branch and do a build there. There will be a Fedora 34 compose
and it'll appear in
http://dl.fedoraproject.org/pub/fedora/linux/development/34/ once
complete. Please be sure to check it out. Bodhi is currently not
active for Fedora 34, it will be enabled in a couple of weeks when we
hit Beta change freeze point in the Fedora 34 schedule[1].

Two things to remember:

1. The modules will be built for a new platform:f35
2. The signing of rpms is not done yet with the new f35 key.
3. F34/branched release is frozen right now until we get a successful
compose, expect that your f34 builds won't be available immediately.

Thanks for understanding.

[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html

On Mon, Feb 8, 2021 at 11:39 AM Mohan Boddu  wrote:
>
> Hello All,
>
> Fedora 34 will be branched from rawhide on Feb 09th 2021 as per the
> Fedora 34 schedule[1]. The process takes about a day and everything
> should be ready by Feb 10th 2021. You can still be able to build
> packages normally until then, but after the mass branching, rawhide
> and F34 will be separated.
>
> We will send another email once the branching is done.
>
> Thanks,
> Mohan Boddu.
>
> [1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
___
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

[Bug 1927271] New: perl-DBD-CSV-0.58 is available

[bugzilla]

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

Bug ID: 1927271
   Summary: perl-DBD-CSV-0.58 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DBD-CSV
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, ka...@ucw.cz,
p...@city-fan.org, perl-devel@lists.fedoraproject.org,
st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.58
Current version/release in rawhide: 0.57-2.fc34
URL: http://search.cpan.org/dist/DBD-CSV/

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


-- 
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: mesa 21.0.0-rc3 making rawhide really unstable?

[Fabio Valentini]

On Fri, Feb 5, 2021 at 9:00 AM Milan Crha  wrote:
>
> On Fri, 2021-02-05 at 16:17 +1000, David Airlie wrote:
> > Has anyone got a backtrace they could put in a bug? I'm not seeing a
> > crash with X.org here in my test VMs.
>
> Hi,
> I do not see any crash as such, Xorg simply fails to start with:
>
>   Fatal server error:
>   [32.661] (EE) no screens found(EE)
>
> I opened the following bug for further tracking:
> https://bugzilla.redhat.com/show_bug.cgi?id=1925423

For anyone affected by this but not following the bug report:
It seems the Xorg issues are caused not by mesa itself, but by DRI1
support removal in xserver, which broke the QXL driver.

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: New memory tester application potentially to replace memtest86+: PCMemTest

[Florian Weimer]

* Florian Weimer:

> * Neal Gompa:
>
>> None of this had to be this way. It is so by our own inaction, not by
>> the action of Microsoft.
>
> I agree.  No one but Microsoft stepped up and was willing to control the
> key material.
>
> I still wish we went the way of documenting how to disable Secure Boot
> in commonly used firmware implementations.  Secure Boot does not offer
> any benefit to a platform designed to be as malleable as Fedora is.  I
> tried to start that documentation, but I got the distinct impression it
> was unwanted.
>
> Instead run-time disabling of Secure Boot support without reboot comes
> and goes, particularly in downstream kernels.  Kernel modules are such
> an important diagnostic tool, and not everyone plans ahead and disables
> Secure Boot in case they need to load kernel modules later.

(“run-time disabling of kernel lockdown“ is more accurate—but of course
if there's an off switch for this feature, lockdown isn't very effective
in the first place.)

>>> And for the record, my computer's UEFI firmware is so old that
>>> "Secure Boot" cannot even be enabled at all, even if I wanted to.
>>
>> Meh. That means your computer was made before Microsoft started having
>> vendors require UEFI firmware to include their keys for Windows
>> certification (which was in 2006/2007). I'm surprised it still works.
>> More power to you, I guess?
>
> Last time I checked this, the Microsoft keys required for Windows
> certification were not those used to sign third-party binaries like the
> Fedora shim (the “Microsoft Corporation Third Party Marketplace Root”).
> You could see the difference in Hyper-V configurations, where the
> default Secure Boot configuration cannot boot Fedora.
>
> Thanks,
> Florian

-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New memory tester application potentially to replace memtest86+: PCMemTest

[Florian Weimer]

* Neal Gompa:

> None of this had to be this way. It is so by our own inaction, not by
> the action of Microsoft.

I agree.  No one but Microsoft stepped up and was willing to control the
key material.

I still wish we went the way of documenting how to disable Secure Boot
in commonly used firmware implementations.  Secure Boot does not offer
any benefit to a platform designed to be as malleable as Fedora is.  I
tried to start that documentation, but I got the distinct impression it
was unwanted.

Instead run-time disabling of Secure Boot support without reboot comes
and goes, particularly in downstream kernels.  Kernel modules are such
an important diagnostic tool, and not everyone plans ahead and disables
Secure Boot in case they need to load kernel modules later.

>> And for the record, my computer's UEFI firmware is so old that
>> "Secure Boot" cannot even be enabled at all, even if I wanted to.
>
> Meh. That means your computer was made before Microsoft started having
> vendors require UEFI firmware to include their keys for Windows
> certification (which was in 2006/2007). I'm surprised it still works.
> More power to you, I guess?

Last time I checked this, the Microsoft keys required for Windows
certification were not those used to sign third-party binaries like the
Fedora shim (the “Microsoft Corporation Third Party Marketplace Root”).
You could see the difference in Hyper-V configurations, where the
default Secure Boot configuration cannot boot Fedora.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-20210210.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp
Xfce raw-xz armhfp

Failed openQA tests: 104/183 (x86_64), 66/124 (aarch64)

ID: 772844  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/772844
ID: 772846  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/772846
ID: 772865  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/772865
ID: 772866  Test: x86_64 Server-dvd-iso mediakit_fileconflicts
URL: https://openqa.fedoraproject.org/tests/772866
ID: 772882  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/772882
ID: 772891  Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/772891
ID: 772892  Test: x86_64 Everything-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/772892
ID: 772947  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/772947
ID: 772953  Test: aarch64 Minimal-raw_xz-raw.xz release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/772953
ID: 772959  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/772959
ID: 772960  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/772960
ID: 772975  Test: aarch64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/772975
ID: 772977  Test: aarch64 Server-dvd-iso mediakit_fileconflicts@uefi
URL: https://openqa.fedoraproject.org/tests/772977
ID: 772987  Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/772987
ID: 772991  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/772991
ID: 773002  Test: aarch64 Server-raw_xz-raw.xz release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/773002
ID: 773008  Test: aarch64 Workstation-raw_xz-raw.xz 
release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/773008
ID: 773015  Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi
URL: https://openqa.fedoraproject.org/tests/773015
ID: 773016  Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/773016
ID: 773025  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/773025
ID: 773035  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/773035
ID: 773036  Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/773036
ID: 773037  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/773037
ID: 773038  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/773038
ID: 773041  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/773041
ID: 773042  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/773042
ID: 773043  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/773043
ID: 773044  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/773044
ID: 773050  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/773050
ID: 773051  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/773051
ID: 773052  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/773052
ID: 773053  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/773053
ID: 773054  Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/773054
ID: 773055  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/773055
ID: 773056  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/773056
ID: 773099  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/773099
ID: 773108  Test: aarch64 universal upgrade_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/773108
ID: 773109  Test: aarch64 universal upgrade_server_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/773109
ID: 773110  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/773110
ID: 773112  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/773112
ID: 773120  Test: aarch64 universal 

ACTION NEEDED: A regression was found and fixed in pyproject-rpm-macros wrt %pyproject_save_files

[Miro Hrončok]

Hello Pythonistas.

Unfortunately, we have found a regression in pyproject-rpm-macros wrt 
%pyproject_save_files.


The nested __pycache__ directories were not properly owned. E.g.:

/usr/lib/python3.9/site-packages/rope
/usr/lib/python3.9/site-packages/rope/__pycache__ - NOT OWNED
/usr/lib/python3.9/site-packages/rope/__pycache__/__init__.cpython-39.pyc

A fix is approaching in pyproject-rpm-macros-0-38.

Due to the mass rebuild, (close to) all packages using %pyproject_save_files 
have been affected in F34+. Only packages without Python directories in 
site-packages were immune to this bug.


Binary packages affected on Fedora 34+:

black
doge
ilua
marshalparser
mu
oraculum
python3-aioeafm
python3-aioflo
python3-aionotion
python3-aiosqlite
python3-arpeggio
python3-beniget
python3-bitcoinlib
python3-click
python3-colorzero
python3-crashtest
python3-distlib
python3-enturclient
python3-fastjsonschema
python3-gast
python3-guizero
python3-iniconfig
python3-junit_xml
python3-jupyter-client
python3-jupyter-core
python3-jupyter-kernel-test
python3-matrix-nio
python3-more-itertools
python3-nbformat
python3-niaaml
python3-noggin-messages
python3-numpydoc
python3-packaging
python3-parver
python3-pendulum
python3-pep517
python3-pipreqs
python3-plette
python3-poetry
python3-poetry-core
python3-pyairnow
python3-pyairvisual
python3-PyGithub
python3-pyglet
python3-pygments
python3-pyopenuv
python3-pytest-spec
python3-pytest-venv
python3-pytile
python3-requests
python3-rope
python3-rq
python3-ryu
python3-setuptools_scm
python3-shellingham
python3-sklearn-nature-inspired-algorithms
python3-sockjs-tornado
python3-sphinx-inline-tabs
python3-toml
python3-wtf-peewee
python3-yarg
pythran
tox

Packages on Fedora 32/33 might have been affected as well, I'll post the list(s) 
later today.


Since I assume the packages will be rebuilt for unrelated reasons in Fedora 34 
before GA, I won't do any targeted rebuild (yet anyway). If your package was 
affected, a rebuild is recommended (if another update/rebuild is not anticipated 
in the near future).


The fixed pyproject-rpm-macros is building. Ensure it is available for a given 
Fedora version 3X before you rebuild:


$ koji wait-repo f3X-build --build=pyproject-rpm-macros-0-38.fc3X

It is already available for rawhide (Fedora 35).

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

Fedora-Cloud-32-20210210.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-20210209.0):

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

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: our containers with alias vim=vi

[Zdenek Dohnal]

Hi,

just note - the functionality has been removed in the recent Vim package
for 2 reasons:

1) making it default breaks a default vim alias - vimdiff == vim -d ,
because diff functionality is not a part of small set of features 'vi'
is compiled with

2) making it optional via an environment variable (the way I thought it
could be possible) doesn't cover all use cases when the 'vim -> vi'
should work f.e. doesn't work with sudo. And it still requires an action
from user which wants the functionality to be enabled, so I don't see a
difference for user if the user needs to set 'alias vim=vi' or set
environment variable.

I'm sorry for inconvenience,


Zdenek

On 10/10/20 2:37 PM, clime wrote:
> Hello,
>
> could Fedora and CentOS containers for docker and podman come with
> `alias vim=vi` in ~/.bashrc?
>
> I would very much welcome it as I am used to type vim everywhere but
> if vi starts instead I am happy too. I know that the solution is to
> create a customized container but often I want to try something on
> vanilla containers from the whole range.
>
> Didn't want to write about this first but maybe there are more people
> with the same problem.
>
> clime
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C




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

[Test-Announce] Fedora 34 Branched 20210210.n.1 nightly compose nominated for testing

[rawhide]

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

Notable package version changes:
anaconda - 20210206.n.0: anaconda-34.23-1.fc34.src, 20210210.n.1: 
anaconda-34.24-1.fc34.src
lorax - 20210206.n.0: lorax-34.7-2.fc34.src, 20210210.n.1: lorax-34.8-1.fc34.src

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

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

https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210210.n.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210210.n.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210210.n.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210210.n.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210210.n.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210210.n.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210210.n.1_Security_Lab

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

[F34] wait-repo task has been opened for approx 2 hours

[Zdenek Dohnal]

Hi all,

I have started foomatic-db+foomatic chainbuild this morning for F34 and
it has been opened for 2 hours till now. Is it expected?

IIUC I don't need a buildroot override yet, since F34 hasn't been
enabled in bodhi. So the process should be the same as in rawhide.

Does anyone know what's going on?

Thank you in advance,


Zdenek

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C




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