Fedora-Cloud-33-20210224.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-20210223.0):

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

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

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

[Ondrej Dubaj]

Brian,

you are right there are some changes which are now backward compatible.
That's the reason why we need cross-component cooperation from other
maintainers to detect these pieces and potentially report them to upstream
and see if they are willing to fix them. Another option is also to create a
compat package for autoconf-2.69 for f35, but it can lead to a result,
where some of the maintainers/upstreams will never use autoconf-2.71.

If there are any packages, which are already orphaned, do not hesitate to
let me know and I will remove them. Also, if you are missing any package
there. Autoconf changes have a huge impact on the whole system, so it needs
to be properly tested and agreed.

Thanks for your cooperation!

Ondrej

On Wed, Feb 24, 2021 at 1:44 AM Jeff Law  wrote:

>
>
> On 2/23/21 4:54 PM, Jerry James wrote:
> > On Tue, Feb 23, 2021 at 4:52 PM Jeff Law  wrote:
> >> On 2/23/21 4:39 PM, Brian C. Lane wrote:
> >>> On Tue, Feb 23, 2021 at 11:37:42AM +0100, Ondrej Dubaj wrote:
>  [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/
> >>> Doesn't work, with or without :8080
> >> Not sure what you're referring to, it just worked fine for me.
> > As Ondrej said: "Attaching also results from a tester launched by Jeff
> > Law [2] (accessible only on Red Hat VPN)".  Those of us without access
> > to the Red Hat VPN cannot see those results.
> But Brian is (or can be) inside the VPN.  That's what I was referring to.
>
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] Fedora 34 bodhi activation point

[Tomas Hrcka]

Hi all,

Today's an important day on the Fedora 34 schedule[1], with several
significant cut-offs. First of all today is the Bodhi activation point [2].
That means that from now all Fedora 34 packages must be submitted to
updates-testing and pass the relevant requirements[3] before they will be
marked as 'stable' and moved to the fedora repository.

Today is also the Alpha freeze[4]. This means that only packages which fix
accepted blocker or freeze exception bugs[5][6] will be marked as 'stable'
and included in the Alpha composes. Other builds will remain in
updates-testing until the Alpha release is approved, at which point the
Alpha freeze is lifted and packages can move to 'stable' as usual until the
Beta freeze.

Today is also the Software String freeze[7], which means that strings
marked for translation in Fedora-translated projects should not now be
changed for Fedora 34.

Finally, today is the 'completion deadline' Change Checkpoint[8], meaning
that Fedora 34 Changes must now be 'feature complete or close enough to
completion that a majority of its functionality can be tested'.

Regards
Tomas Hrcka

[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
[8] https://fedoraproject.org/wiki/Changes/Policy


-- 
Tomas Hrcka
role: CPE Team - Senior Software Engineer
fas: humaton
freenode: jednorozec
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/24/report-389-ds-base-2.0.3-20210224git60e35aac5.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

[Bug 1932000] perl-Test-NoBreakpoints-0.17 is available

[bugzilla]

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



--- Comment #3 from Upstream Release Monitoring 
 ---
An HTTP error occurred downloading the package's new Source URLs: Getting
https://cpan.metacpan.org/authors/id/J/JF/JFITZ/Test-NoBreakpoints-0.17.tar.gz
to ./Test-NoBreakpoints-0.17.tar.gz


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

[Bug 1932000] perl-Test-NoBreakpoints-0.17 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Test-NoBreakpoints-0.1 |perl-Test-NoBreakpoints-0.1
   |6 is available  |7 is available



--- Comment #2 from Upstream Release Monitoring 
 ---
Latest upstream release: 0.17
Current version/release in rawhide: 0.15-26.fc34
URL: http://search.cpan.org/dist/Test-NoBreakpoints/

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


-- 
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 1893788] EPEL8 request: perl-Mail-IMAPClient

[bugzilla]

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

Nick Bebout  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 CC||n...@fedoraproject.org
 Resolution|--- |ERRATA
Last Closed||2021-02-24 02:51:57



--- Comment #3 from Nick Bebout  ---
This has been built for EPEL8


-- 
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: Please remove "-i" from "%forgemeta" templates on wiki

[Tim Landscheidt]

Otto Urpelainen  wrote:

> […]

> Like I said, I am not expert in forge macros, so if anybody thinks that
> my edit removal was a bad idea, wiki has an undo button.

Thanks!

Tim
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Please remove "-i" from "%forgemeta" templates on wiki

[Kevin Kofler via devel]

Otto Urpelainen wrote:
> Unfortunately, the Fedora wiki is a documentation trap, full of outdated
> or obsolete pages whose advice should not be followed. Mixed with other
> pages that have useful content that cannot be found elsewhere, so you
> cannot simply disregard the wiki either.

The move to docs.fedoraproject.org was really a mistake. Documentation is 
harder to keep up to date there, also harder for readers to find there, the 
duplication between old wiki pages and new docs.fedoraproject.org pages is a 
common issue, and some information is not on docs.fedoraproject.org at all 
(but in some old wiki page that is harder to find now that most 
documentation was moved off the wiki).

I really fail to see what value that move has brought us.

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

Re: help with building nextcloud-client

[Mukundan Ragavan]

On 2/22/21 9:33 PM, Jerry James wrote:


The compiler is telling you that it saw "#include " inside an
extern "C" block, but that glib.h ultimately pulls in headers with C++
definitions.  It looks like the glib headers already take care of
defining things correctly depending on whether they are being consumed
by a C compiler or a C++ compiler.  Tell upstream to move all #include
statements for glib headers out of extern "C" blocks.


Thank you! That helped. I am able to build successfully on mock. I will 
update this soon and submit the patch upstream.


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

License change: R-forcats - GPLv3 -> MIT

[Elliott Sales de Andrade]

Upstream has re-licensed to MIT.

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

[Jeff Law]

On 2/23/21 4:54 PM, Jerry James wrote:
> On Tue, Feb 23, 2021 at 4:52 PM Jeff Law  wrote:
>> On 2/23/21 4:39 PM, Brian C. Lane wrote:
>>> On Tue, Feb 23, 2021 at 11:37:42AM +0100, Ondrej Dubaj wrote:
 [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/
>>> Doesn't work, with or without :8080
>> Not sure what you're referring to, it just worked fine for me.
> As Ondrej said: "Attaching also results from a tester launched by Jeff
> Law [2] (accessible only on Red Hat VPN)".  Those of us without access
> to the Red Hat VPN cannot see those results.
But Brian is (or can be) inside the VPN.  That's what I was referring to.

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

License change: R-hms - GPLv3 -> MIT

[Elliott Sales de Andrade]

Upstream has relicensed, as in title. Due to requirements, this will
only be changed in F34+.

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

[Jerry James]

On Tue, Feb 23, 2021 at 4:52 PM Jeff Law  wrote:
> On 2/23/21 4:39 PM, Brian C. Lane wrote:
> > On Tue, Feb 23, 2021 at 11:37:42AM +0100, Ondrej Dubaj wrote:
> >> [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/
> > Doesn't work, with or without :8080
> Not sure what you're referring to, it just worked fine for me.

As Ondrej said: "Attaching also results from a tester launched by Jeff
Law [2] (accessible only on Red Hat VPN)".  Those of us without access
to the Red Hat VPN cannot see those results.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Jeff Law]

On 2/23/21 4:39 PM, Brian C. Lane wrote:
> On Tue, Feb 23, 2021 at 11:37:42AM +0100, Ondrej Dubaj wrote:
>> [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/
> Doesn't work, with or without :8080
Not sure what you're referring to, it just worked fine for me.

>
> parted is failing with a pile of newly obsolete things, and one error
> (as far as I can tell) with a missing build-aux/compile
Yes, partd falls down spectacularly.


http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/view/Failing/job/parted/216/consoleFull

Search for the first "autoreconf" and see all the diagnostics.

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

Re: OCaml 4.12

[Jerry James]

On Mon, Feb 22, 2021 at 10:21 AM Richard W.M. Jones  wrote:
> Thanks again.  Let's see what happens when 4.12 is finally released.

I have picked up ocaml-ocp-indent, which was orphaned recently,
because frama-c needs it.  I pushed some changes to the Rawhide branch
today but haven't rebuilt.  I'll let the OCaml 4.12 rebuilds take care
of that.  I'm going to do likewise with ocaml-menhir, probably in the
next 24 hours.

I am thinking of picking up ocaml-merlin, which is also orphaned.  I
have tried updating it to 4.1, but some tests are failing.  A little
debugging work revealed that merlin is trying to read standard library
*.cmt and *.cmti files, but we don't have them in our ocaml package.
I see this in ocaml.spec:

# Remove .cmt and .cmti files, for now.  We could package them later.
# See also: http://www.ocamlpro.com/blog/2012/08/20/ocamlpro-and-4.00.0.html
find $RPM_BUILD_ROOT \( -name '*.cmt' -o -name '*.cmti' \) -a -delete


Can we make "later" be when OCaml 4.12 is released?  They could go
into a separate subpackage, since most OCaml packages won't need them.
Thanks,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Brian C. Lane]

On Tue, Feb 23, 2021 at 11:37:42AM +0100, Ondrej Dubaj wrote:
> [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/

Doesn't work, with or without :8080

parted is failing with a pile of newly obsolete things, and one error
(as far as I can tell) with a missing build-aux/compile

I'm guessing I need to bootstrap the whole thing again, which leads me
to:

Are these changes backwards compatible? I am also an upstream maintainer
for parted, and unless the 2.71 changes will also work with 2.69 I won't
be able to apply them upstream until enough users have moved to the new
autoconf.

Thanks,

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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] Re: failed to build rpms

[William Brown]

Should we update the contributing/build docs to reflect these steps? 

> On 24 Feb 2021, at 07:10, Mark Reynolds  wrote:
> 
> You have to skip the npm audit check "SKIP_AUDIT_CI=1" for now, and the rust 
> stuff is a pain and it is hardcoded to be enabled. You always have to update 
> and download the latest Rust dependencies:
> 
> SKIP_AUDIT_CI=1 make -f rpm.mk update-cargo-dependencies 
> download-cargo-dependencies rpms
> 
> HTH,
> 
> Mark
> 
> On 2/23/21 1:40 PM, Ludwig Krispenz wrote:
>> Hi,
>> 
>> since a long time I was trying to build rpms and failed, here are the issues 
>> I run into:
>> 
>> 1] problem with npm/audit
>> 
>> I followed the suggestions here: 
>> https://www.port389.org/docs/389ds/contributing.html (pushd/npm fix/popd), 
>> but this didn't help, only commenting out audit-ci in 
>> src/cockpit/389-console/node_modules.mk got me over this
>> 
>> 2] rust
>> 
>> 2.1]
>> 
>> rpm build failed with:
>> 
>> error: failed to get `concread` as a dependency of package `librslapd v0.1.0 
>> (/home/elkris/DEV/gh/two/389-ds-base/rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/src/librslapd)`
>> 
>> Caused by:
>>   failed to load source for dependency `concread`
>> 
>> Caused by:
>>   Unable to update registry `https://github.com/rust-lang/crates.io-index`
>> 
>> Caused by:
>>   failed to update replaced source registry 
>> `https://github.com/rust-lang/crates.io-index`
>> 
>> Caused by:
>>   failed to read root of directory source: 
>> /home/elkris/DEV/gh/two/389-ds-base/rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/vendor
>> 
>> Caused by:
>>   No such file or directory (os error 2)
>> make[1]: *** [Makefile:12715: 
>> .../rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/rs/rslapd/release/librslapd.a]
>>  Error 101
>> 
>> 
>> ,
>> 
>> It was right that there wasno rs/rslapd/release/librslapd.a file, not even 
>> the directory rs existed. After configuring --enable-rust the directory was 
>> created and populated.
>> 
>> Q1: why does it try to pack rust stuff if it is not enabled ?
>> 
>> 2.2] Now the directory was there, but I still did get the same error. A 
>> closer look showed that it was looking for 
>> .../rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/rs/rslapd/release/librslapd.a
>>  ,but what existed was 
>> .../rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/rs/rslapd/debug/librslapd.a.
>>  Note "debug" -- "release". configure was run with --enable-debug
>> 
>> Q2: Is there somewhere a hardcoded/default assumpion of "release" ? in the 
>> cargo spec?
>> 
>> Thanks for any suggestions
>> 
>> 
>> Regards,
>> 
>> Ludwig
>> ___
>> 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
> 
> -- 
> 
> 389 Directory Server Development Team
> ___
> 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

—
Sincerely,

William Brown

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

License correction: R-shiny GPLv3 -> GPLv3 and BSD and MIT and OFL

[Elliott Sales de Andrade]

Since jqueryui is no longer packaged, I've re-bundled it in R-shiny. I
went through the bundled JavaScript libraries and corrected the
License field, as above.

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

Re: [Fedora-packaging] Re: Python extras: underscore supported?

[Miro Hrončok]

On 20. 02. 21 12:53, Miro Hrončok wrote:

I'll submit a fix shortly.


https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/88


The fix should be in here:

F33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-4afa5ada33
F34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-7aa3f311d5
F35: https://bodhi.fedoraproject.org/updates/FEDORA-2021-56ad871a72

It is available in the buildroot (build with --enablerepo=local if using mock).

See also: https://src.fedoraproject.org/rpms/python-webscrapbook/pull-request/1

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

Re: CentOS Stream : No matching package to install: 'python3-pytest-runner'

[Miro Hrončok]

On 23. 02. 21 22:19, Chris wrote:

Hi all,

I get the following error with CentOS Stream builds on COPR:

No matching package to install: 'python3-pytest-runner'
Not all dependencies satisfied
Error: Some packages could not be found.

Source:
https://download.copr.fedorainfracloud.org/results/lead2gold/apprise/centos-stream-x86_64/02014893-python-apprise/builder-live.log.gz 



It works great for EL8 and EL7.


The package is available in EPEL, not in RHEL.

The CentOS Stream Copr roots don't have EPEL enabled, presumably because there 
is no EPEL for CentOS Stream yet.


I was just curious what is involved in getting 
this package added to the upstream repository?


To get the package into CentOS Stream, it needs to be added to RHEL.
To add a package to RHEL, a customer ticket should be opened, or a bugzilla. (As 
one of the Python Maintainers, I strongly suspect that python3-pytest-runner 
won't be added to RHEL without a strong customer case.)


Instead, you may want to query about EPEL Next (EPEL for CentOS Stream) on the 
EPEL mailing list:


https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/thread/NYXQNQFAY44RNCJTP6WLYUGJSQX5XSIX/

Or you may want to ask for an experimental Copr root with CentOS Stream and EPEL 
enabled (an unsupported combination that may break, but would work for your case):


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

CentOS Stream : No matching package to install: 'python3-pytest-runner'

[Chris]

Hi all,

I get the following error with CentOS Stream builds on COPR:

No matching package to install: 'python3-pytest-runner'
Not all dependencies satisfied
Error: Some packages could not be found.

Source:
https://download.copr.fedorainfracloud.org/results/lead2gold/apprise/centos-stream-x86_64/02014893-python-apprise/builder-live.log.gz

It works great for EL8 and EL7.  I was just curious what is involved in
getting this package added to the upstream repository?

Thoughts/Advice?

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

[Mark Reynolds]

You have to skip the npm audit check "SKIP_AUDIT_CI=1" for now, and the 
rust stuff is a pain and it is hardcoded to be enabled. You always have 
to update and download the latest Rust dependencies:


SKIP_AUDIT_CI=1 make -f rpm.mk update-cargo-dependencies 
download-cargo-dependencies rpms


HTH,

Mark

On 2/23/21 1:40 PM, Ludwig Krispenz wrote:

Hi,

since a long time I was trying to build rpms and failed, here are the 
issues I run into:


1] problem with npm/audit

I followed the suggestions here: 
https://www.port389.org/docs/389ds/contributing.html (pushd/npm 
fix/popd), but this didn't help, only commenting out audit-ci in 
src/cockpit/389-console/node_modules.mk got me over this


2] rust

2.1]

rpm build failed with:

error: failed to get `concread` as a dependency of package `librslapd 
v0.1.0 
(/home/elkris/DEV/gh/two/389-ds-base/rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/src/librslapd)`


Caused by:
  failed to load source for dependency `concread`

Caused by:
  Unable to update registry 
`https://github.com/rust-lang/crates.io-index`


Caused by:
  failed to update replaced source registry 
`https://github.com/rust-lang/crates.io-index`


Caused by:
  failed to read root of directory source: 
/home/elkris/DEV/gh/two/389-ds-base/rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/vendor


Caused by:
  No such file or directory (os error 2)
make[1]: *** [Makefile:12715: 
.../rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/rs/rslapd/release/librslapd.a] 
Error 101



,

It was right that there wasno rs/rslapd/release/librslapd.a file, not 
even the directory rs existed. After configuring --enable-rust the 
directory was created and populated.


Q1: why does it try to pack rust stuff if it is not enabled ?

2.2] Now the directory was there, but I still did get the same error. 
A closer look showed that it was looking for 
.../rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/rs/rslapd/release/librslapd.a 
,but what existed was 
.../rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/rs/rslapd/debug/librslapd.a. 
Note "debug" -- "release". configure was run with --enable-debug


Q2: Is there somewhere a hardcoded/default assumpion of "release" ? in 
the cargo spec?


Thanks for any suggestions


Regards,

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


--

389 Directory Server Development Team
___
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

Re: Please remove "-i" from "%forgemeta" templates on wiki

[Otto Urpelainen]

Tim Landscheidt kirjoitti 23.2.2021 klo 18.16:

Hi,

using "%forgemeta" with the "-i" option causes debug infor-
mation to be output which leads to %changelog entries being
garbled:

(snip)

Therefore, the templates at
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_using_forges_hosted_revision_control
use "%forgemeta" without options and note:

| #  – remove  “-i” and “-v” before commit

However, the templates on the wiki page at
https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation#Packaging_examples
use "%forgemeta -i" and do not clarify that this needs to be
amended before committing.

It would be nice if the wiki page could be updated to avoid
luring packagers into using these templates, perhaps with a
hatnote that the content is historical (?) and only the tem-
plates in the packaging guidelines should be used.


Hi Tim,

Unfortunately, the Fedora wiki is a documentation trap, full of outdated
or obsolete pages whose advice should not be followed. Mixed with other
pages that have useful content that cannot be found elsewhere, so you
cannot simply disregard the wiki either.

In this case, the wiki page contains a draft whose final version is in
the packaging guidelines. Even though I am not very familiar with the
forge macros, I took the liberty to add an easy to spot link from the
wiki page to the guidelines and removed the examples that misled you.
As far as I can tell, the examples did not have anything that cannot be
read from the examples in the guidelines. It could be that the whole
page could be removed, but since it contains a collection of links, some
parameters that are not mentioned in the guidelines and discussion on
how to extend the macros, I left it there.

Like I said, I am not expert in forge macros, so if anybody thinks that
my edit removal was a bad idea, wiki has an undo button.

Otto
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: systemd-resolved fallback DNS servers: usability vs. GDPR

[Zbigniew Jędrzejewski-Szmek]

On Tue, Feb 23, 2021 at 01:18:08PM +0100, Marius Schwarz wrote:
> Am 22.02.21 um 11:17 schrieb Zbigniew Jędrzejewski-Szmek:
> >>1) Use different defaults for different Fedora editions, e.g. container
> >>and cloud images include the fallback DNS servers list while
> >>workstation (and similar) images don't.
> >Yes, I think this would be the way to go.
> Everything, that is not prepresenting a person, is not regulated by
> GDPR, therefor it does not "need" to comply.

No. GDPR is about "personally identifying information". In particular,
it talks about information which may be combined with other information
(now or in the future) to identify a specific person. And an IP address
falls into this category in the general case.

The scenario we are considering here is e.g. a company which provides
computers with Fedora installed to its employees or customers. Whatever
resolver is used gets the source IP information which as described
above can be identifying (depending on the network setup and other
circumstances). By removing the fallback, we're removing a possible
information expose and violation of the law by the company.

> About fallbacks in general:
> 
> Es the example shows cleary to me, having fallback dns means, that
> you do not see, that your dns config is faulty
> and will fail in unexpected ways.

The issue was logged at warning level. So "do not see" is relative —
it certainly was possible to "see", though maybe not very visible.

Zbyszek

P.S. I like to do 'journalctl -b -p notice' after upgrades to look for
such issues, but sadly there is so much noise in the logs that issues
get lost. I would love to reach a state where any entry in the logs
(at notice or above) that shouldn't be there is treated as a bug to fix.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: systemd-resolved fallback DNS servers: usability vs. GDPR

[Tadej Janež]

On Tue, 2021-02-23 at 08:19 -0600, Michael Catanzaro wrote:
> On Tue, Feb 23, 2021 at 10:37 am, Tadej Janež  wrote:
> > I guess this is a simple solution that would work, but from what I
> > understand it would also disable the use of systemd-resolved?
> 
> Nah, it should just switch systemd-resolved into a consumer mode,
> where 
> it reads configuration from /etc/resolv.conf and uses that as its 
> source of truth. Applications using glibc for name resolution (i.e. 
> almost everything) will still talk to systemd-resolved and ignore 
> /etc/resolv.conf.

Oh, I see. Thanks for the explanation.

> That's not the default configuration in Fedora, though. Writing to a 
> /etc/systemd/resolved.conf.d/*cloud-init.conf would be better though,
> since it would avoid major changes to how systemd-resolved works.

Agreed.



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

Schedule for Wednesday's FESCo Meeting (2021-02-24)

[Clement Verna]

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

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

or run:
   date -d '2021-02-24 15:00 UTC'


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

= Discussed and Voted in the Ticket =

= Followups =

Fedora 34 incomplete changes
https://pagure.io/fesco/issue/2576

Preset Request: google-guest-agent.service google-startup-scripts.service
google-shutdown-scripts.service
https://pagure.io/fesco/issue/2578

= Open Floor =

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

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

[389-devel] failed to build rpms

[Ludwig Krispenz]

Hi,

since a long time I was trying to build rpms and failed, here are the 
issues I run into:


1] problem with npm/audit

I followed the suggestions here: 
https://www.port389.org/docs/389ds/contributing.html (pushd/npm 
fix/popd), but this didn't help, only commenting out audit-ci in 
src/cockpit/389-console/node_modules.mk got me over this


2] rust

2.1]

rpm build failed with:

error: failed to get `concread` as a dependency of package `librslapd 
v0.1.0 
(/home/elkris/DEV/gh/two/389-ds-base/rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/src/librslapd)`


Caused by:
  failed to load source for dependency `concread`

Caused by:
  Unable to update registry `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to update replaced source registry 
`https://github.com/rust-lang/crates.io-index`


Caused by:
  failed to read root of directory source: 
/home/elkris/DEV/gh/two/389-ds-base/rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/vendor


Caused by:
  No such file or directory (os error 2)
make[1]: *** [Makefile:12715: 
.../rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/rs/rslapd/release/librslapd.a] 
Error 101



,

It was right that there wasno rs/rslapd/release/librslapd.a file, not 
even the directory rs existed. After configuring --enable-rust the 
directory was created and populated.


Q1: why does it try to pack rust stuff if it is not enabled ?

2.2] Now the directory was there, but I still did get the same error. A 
closer look showed that it was looking for 
.../rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/rs/rslapd/release/librslapd.a 
,but what existed was 
.../rpmbuild/BUILD/389-ds-base-2.0.3.20210223gitbda2c53d0/rs/rslapd/debug/librslapd.a. 
Note "debug" -- "release". configure was run with --enable-debug


Q2: Is there somewhere a hardcoded/default assumpion of "release" ? in 
the cargo spec?


Thanks for any suggestions


Regards,

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

[Bug 1932000] perl-Test-NoBreakpoints-0.16 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
An HTTP error occurred downloading the package's new Source URLs: Getting
https://cpan.metacpan.org/authors/id/J/JF/JFITZ/Test-NoBreakpoints-0.16.tar.gz
to ./Test-NoBreakpoints-0.16.tar.gz


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

[Bug 1932000] New: perl-Test-NoBreakpoints-0.16 is available

[bugzilla]

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

Bug ID: 1932000
   Summary: perl-Test-NoBreakpoints-0.16 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test-NoBreakpoints
  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: 0.16
Current version/release in rawhide: 0.15-26.fc34
URL: http://search.cpan.org/dist/Test-NoBreakpoints/

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


-- 
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: PA module support in PipeWire

[Kevin Kofler via devel]

Neal Gompa wrote:
> What are you talking about? I seem to be able to select devices and
> such. The only thing I don't seem to be able to do is do "advanced
> audio settings" which is grayed out and says it requires the
> PulseAudio gsettings module.

It turns out that the relevant settings have already been hidden by the 
Plasma developers a couple years ago, by removing them from System Settings:
https://phabricator.kde.org/D22616
and moving them to the standalone phononsettings executable:
https://invent.kde.org/libraries/phonon/-/commits/master/settings
which is now installed by phonon-qt5 (but has no menu entry, in violation of 
the packaging guidelines).

So run:
phononsettings
(which should still be installed by default by the Spin, it's in the main 
phonon-qt5 package after all) to see what I mean.

But it looks like this is already broken with PulseAudio, I get only:
PulseAudio Sound Server
as the only device there. That is what happens when you hide things, nobody 
tests them anymore. Sigh… :-(

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

[Bug 1931967] New: perl-App-cpm-0.997003 is available

[bugzilla]

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

Bug ID: 1931967
   Summary: perl-App-cpm-0.997003 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-App-cpm
  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
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.997003
Current version/release in rawhide: 0.997.002-1.fc34
URL: http://search.cpan.org/dist/App-cpm/

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


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

Fedora 34 Bodhi updates-testing Activation and Beta Freeze

[Mohan Boddu]

Hi all,

Today's an important day on the Fedora 34 schedule[1], with several
significant cut-offs. First of all today is the Bodhi updates-testing
activation point [2]. That means that from now all Fedora 34 packages
must be submitted to updates-testing and pass the relevant
requirements[3] before they will be marked as 'stable' and moved to
the fedora repository.

Today is also the Beta freeze[4]. This means that only packages which
fix accepted blocker or freeze exception bugs[5][6] will be marked as
'stable' and included in the Beta composes. Other builds will remain
in updates-testing until the Beta release is approved, at which point
the Beta freeze is lifted and packages can move to 'stable' as usual
until the Final freeze.

Today is also the Software String freeze[7], which means that strings
marked for translation in Fedora-translated projects should not now be
changed for Fedora 34.

Finally, today is the 'completion deadline' Change Checkpoint[8],
meaning that Fedora 34 Changes must now be 'feature complete or close
enough to completion that a majority of its functionality can be
tested'. All tracking bugs should be on ON_QA state or later to
reflect this.

Regards
Mohan Boddu

[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
[8] https://fedoraproject.org/wiki/Changes/Policy
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora 34 Bodhi updates-testing Activation and Beta Freeze

[Mohan Boddu]

Hi all,

Today's an important day on the Fedora 34 schedule[1], with several
significant cut-offs. First of all today is the Bodhi updates-testing
activation point [2]. That means that from now all Fedora 34 packages
must be submitted to updates-testing and pass the relevant
requirements[3] before they will be marked as 'stable' and moved to
the fedora repository.

Today is also the Beta freeze[4]. This means that only packages which
fix accepted blocker or freeze exception bugs[5][6] will be marked as
'stable' and included in the Beta composes. Other builds will remain
in updates-testing until the Beta release is approved, at which point
the Beta freeze is lifted and packages can move to 'stable' as usual
until the Final freeze.

Today is also the Software String freeze[7], which means that strings
marked for translation in Fedora-translated projects should not now be
changed for Fedora 34.

Finally, today is the 'completion deadline' Change Checkpoint[8],
meaning that Fedora 34 Changes must now be 'feature complete or close
enough to completion that a majority of its functionality can be
tested'. All tracking bugs should be on ON_QA state or later to
reflect this.

Regards
Mohan Boddu

[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
[8] https://fedoraproject.org/wiki/Changes/Policy
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Please remove "-i" from "%forgemeta" templates on wiki

[Tim Landscheidt]

Hi,

using "%forgemeta" with the "-i" option causes debug infor-
mation to be output which leads to %changelog entries being
garbled:

| [tim@passepartout ~/.cache/rpm-specs]$ grep -l '^.*%forgemeta.\+$' *.spec | 
xargs -r fgrep 'Packaging variables read or set by %forgemeta'
| ddiskit.spec:* Tue Jan 26 2021 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| ddiskit.spec:* Mon Jul 27 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| ddiskit.spec:* Tue May 26 2020 Miro Hrončok  - Packaging 
variables read or set by %forgemeta
| ddiskit.spec:* Tue Jan 28 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| gmediarender.spec:* Sat Aug 01 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| gmediarender.spec:* Mon Jul 27 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| kabi-dw.spec:* Tue Jan 26 2021 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| kabi-dw.spec:* Tue Jul 28 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| kabi-dw.spec:* Wed Jan 29 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| libindi.spec:* Tue Feb 02 2021 Christian Dersch  - 
Packaging variables read or set by %forgemeta
| libindi.spec:* Tue Jan 26 2021 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| libindi.spec:* Sat Aug 01 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| libindi.spec:* Tue Jul 28 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| libpqxx.spec:* Mon Feb 08 2021 Pavel Raiskup  - 
Packaging variables read or set by %forgemeta
| libpqxx.spec:* Tue Jan 26 2021 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| libpqxx.spec:* Sat Aug 01 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| libpqxx.spec:* Tue Jul 28 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| [tim@passepartout ~/.cache/rpm-specs]$

Therefore, the templates at
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_using_forges_hosted_revision_control
use "%forgemeta" without options and note:

| #  – remove  “-i” and “-v” before commit

However, the templates on the wiki page at
https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation#Packaging_examples
use "%forgemeta -i" and do not clarify that this needs to be
amended before committing.

It would be nice if the wiki page could be updated to avoid
luring packagers into using these templates, perhaps with a
hatnote that the content is historical (?) and only the tem-
plates in the packaging guidelines should be used.

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

[Neal Gompa]

On Tue, Feb 23, 2021 at 10:35 AM Daniel P. Berrangé  wrote:
>
> On Tue, Feb 23, 2021 at 09:28:34AM -0500, Matthew Miller wrote:
> > On Mon, Feb 22, 2021 at 10:09:54AM -0800, Kevin Fenzi wrote:
> > > > - Get rid of manually open and manage Bugzilla tickets. Have the ticket
> > > > filed in a web form (or maybe by CLI), and have the ticket workflow
> > > > managed automatically.
> > >
> > > Could we do away with using bugzilla entirely and just keep info in app?
> >
> > I have mixed feelings here... on the one hand, bugzilla is awkward,
> > intimidating, and creaky. But, it's nice to have all that review history in
> > a consistent archive. If we move to a dedicated app, maybe it could at least
> > do a one-way sync to bugzilla for the record?
>
> I tend to thing Fedora's new package process needs something more
> radical to bring it into the modern age.  Lack of automation in the
> review process is an issue, but I think the problems are much broader
> and more fundamental than that. Fedora has always had rather a split
> personality where the workflow and tools for new packages process is
> completely distinct from the workflow and tools for ongoing package
> maint.
>
> Both new package process and ongoing maint look quite dated by modern
> development standards but we have slowly been pulling dist-git into a
> slightly more modern world with the ability to have merge requests.
> I think we need todo the same with new package review process and
> make it align with the way ongoing package maint works, using the
> same set of tools and modern processes.
>
> Creating a new standalone review app IMHO re-inforces the division
> between initial review work and post-acceptance maint work. Automation
> is good of course, but most of the automation tasks done at package
> review and also things that  should be done on an ongoing basis for
> existing packages and their merge requests. IOW, any new automation
> ought to tackle both use cases, rather than re-inforcing our historical
> mistake of having new package review be completely distinct from
> everything else.
>
> IOW, I would like to see us bring package review process into the
> modern world, such that the first step is the user creating their
> own personal repo containing the new package. Then opening a merge
> review to request it graduate into official dist-git. Any automated
> tools and processes (legal review blockers), should be associated
> with the merge request, so everything is tracked in one place, in
> the same way it does after acceptance. Using git lets reviewers
> see how the spec file gets changed by the contributor after each
> round of feedback. We can give comments on specific lines in the
> spec, instead of having to copy + paste quoted text into BZ or
> another tool to give context. There's so much more potential for
> creating a positive review experiance if we start with a modern
> foundation, than continuing to hack stuff onto our historic
> process.
>
> I can't take credit for the idea of this kind of approach. It is
> something I experienced when contributing applications to FlatHub,
> and was pleasantly surprised at how much slicker it is than Fedora's
> new package process.
>
>   https://github.com/flathub/flathub/wiki/App-Submission
>

This is also how openSUSE's package process works too with the
openSUSE Build Service. Pierre-Yves and I had discussed the idea of
supporting an extension to Pagure to offer this workflow right in the
application.

As for the legal review aspect that Ben brought up, I think bringing
in openSUSE's Cavil[1] application into Fedora and leveraging that as
part of this pipeline would be a much better way to handle this. I
have been slowly working on packaging this so that we can run it for
this purpose.

Pagure + new package review extension + cavil would allow us to
finally get rid of fedora-review and all the other weird things we use
and unify our new package workflow with our ongoing maintenance
workflow.

Pagure's ability to take PRs sourced from other Git servers also means
that we don't need to figure out how to deal with storing code before
it's been accepted into Fedora, too.

[1]: https://github.com/openSUSE/cavil




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

Re: Automatizing package review process

[Daniel P . Berrangé]

On Tue, Feb 23, 2021 at 09:28:34AM -0500, Matthew Miller wrote:
> On Mon, Feb 22, 2021 at 10:09:54AM -0800, Kevin Fenzi wrote:
> > > - Get rid of manually open and manage Bugzilla tickets. Have the ticket
> > > filed in a web form (or maybe by CLI), and have the ticket workflow
> > > managed automatically.
> > 
> > Could we do away with using bugzilla entirely and just keep info in app?
> 
> I have mixed feelings here... on the one hand, bugzilla is awkward,
> intimidating, and creaky. But, it's nice to have all that review history in
> a consistent archive. If we move to a dedicated app, maybe it could at least
> do a one-way sync to bugzilla for the record?

I tend to thing Fedora's new package process needs something more
radical to bring it into the modern age.  Lack of automation in the
review process is an issue, but I think the problems are much broader
and more fundamental than that. Fedora has always had rather a split
personality where the workflow and tools for new packages process is
completely distinct from the workflow and tools for ongoing package
maint. 

Both new package process and ongoing maint look quite dated by modern
development standards but we have slowly been pulling dist-git into a
slightly more modern world with the ability to have merge requests.
I think we need todo the same with new package review process and
make it align with the way ongoing package maint works, using the
same set of tools and modern processes.

Creating a new standalone review app IMHO re-inforces the division
between initial review work and post-acceptance maint work. Automation
is good of course, but most of the automation tasks done at package
review and also things that  should be done on an ongoing basis for
existing packages and their merge requests. IOW, any new automation
ought to tackle both use cases, rather than re-inforcing our historical
mistake of having new package review be completely distinct from
everything else.

IOW, I would like to see us bring package review process into the
modern world, such that the first step is the user creating their
own personal repo containing the new package. Then opening a merge
review to request it graduate into official dist-git. Any automated
tools and processes (legal review blockers), should be associated
with the merge request, so everything is tracked in one place, in
the same way it does after acceptance. Using git lets reviewers
see how the spec file gets changed by the contributor after each
round of feedback. We can give comments on specific lines in the
spec, instead of having to copy + paste quoted text into BZ or
another tool to give context. There's so much more potential for
creating a positive review experiance if we start with a modern
foundation, than continuing to hack stuff onto our historic
process.

I can't take credit for the idea of this kind of approach. It is
something I experienced when contributing applications to FlatHub,
and was pleasantly surprised at how much slicker it is than Fedora's
new package process.

  https://github.com/flathub/flathub/wiki/App-Submission

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Automatizing package review process

[Matthew Miller]

On Mon, Feb 22, 2021 at 10:09:54AM -0800, Kevin Fenzi wrote:
> > - Get rid of manually open and manage Bugzilla tickets. Have the ticket
> > filed in a web form (or maybe by CLI), and have the ticket workflow
> > managed automatically.
> 
> Could we do away with using bugzilla entirely and just keep info in app?

I have mixed feelings here... on the one hand, bugzilla is awkward,
intimidating, and creaky. But, it's nice to have all that review history in
a consistent archive. If we move to a dedicated app, maybe it could at least
do a one-way sync to bugzilla for the record?



-- 
Matthew Miller

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

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Neal Gompa]

On Tue, Feb 23, 2021 at 9:20 AM Michael Catanzaro  wrote:
>
> On Tue, Feb 23, 2021 at 11:18 am, Petr Menšík 
> wrote:
> > Who uses cloud-init to prepare containers? Is it end user on his
> > system?
>
> cloud-init is designed for VPS systems. I don't think it's expected to
> be used in containers. I'm sympathetic to your view that running
> systemd-resolved in containers is not very useful, but that seems like
> another topic entirely. (Does it really get run in containers today?
> That would require systemd to be pid 1 in the container, right?)
>

nspawn containers typically behave a lot like VMs, just using the
shared kernel. So they would start init and activate login and such.



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

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Michael Catanzaro]

On Tue, Feb 23, 2021 at 11:18 am, Petr Menšík  
wrote:
Who uses cloud-init to prepare containers? Is it end user on his 
system?


cloud-init is designed for VPS systems. I don't think it's expected to 
be used in containers. I'm sympathetic to your view that running 
systemd-resolved in containers is not very useful, but that seems like 
another topic entirely. (Does it really get run in containers today? 
That would require systemd to be pid 1 in the container, right?)


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

[Michael Catanzaro]

On Tue, Feb 23, 2021 at 10:37 am, Tadej Janež  wrote:

I guess this is a simple solution that would work, but from what I
understand it would also disable the use of systemd-resolved?


Nah, it should just switch systemd-resolved into a consumer mode, where 
it reads configuration from /etc/resolv.conf and uses that as its 
source of truth. Applications using glibc for name resolution (i.e. 
almost everything) will still talk to systemd-resolved and ignore 
/etc/resolv.conf.


That's not the default configuration in Fedora, though. Writing to a 
/etc/systemd/resolved.conf.d/*cloud-init.conf would be better though, 
since it would avoid major changes to how systemd-resolved works.


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

[Wim Taymans]

On Tue, Feb 23, 2021 at 3:13 PM Neal Gompa  wrote:

> On Tue, Feb 23, 2021 at 8:16 AM Kevin Kofler via devel
>  wrote:
> >
> > Lóránt Perger wrote:
> > > I suppose I should have looked a bit more into this before opening this
> > > thread, but oh well, no use crying over spilled milk. I looked into
> how PW
> > > replicates PA's module loading... and turns out it doesn't (
> > >
> https://github.com/PipeWire/pipewire/blob/master/src/modules/module-protocol-pulse/module.c#L146
> > > ). It simply uses an strcmp to check for a single module, which it then
> > > replicates.
> >
> > I also see that the device manager extension is not supported:
> >
> https://github.com/PipeWire/pipewire/blob/master/src/modules/module-protocol-pulse/extension.c#L44
> > so configuring output and input devices in the Phonon KCM (in KDE/Plasma
> > System Settings) is not going to work with PipeWire.
> >
>
> What are you talking about? I seem to be able to select devices and
> such. The only thing I don't seem to be able to do is do "advanced
> audio settings" which is grayed out and says it requires the
> PulseAudio gsettings module. If there's additional functionality
> missing, please file an issue at
> https://gitlab.freedesktop.org/pipewire/pipewire/-/issues.
>
>
> There is already an issue for this and some discussion about that is
missing:

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/771

Wim

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

Re: PA module support in PipeWire

[Neal Gompa]

On Tue, Feb 23, 2021 at 8:16 AM Kevin Kofler via devel
 wrote:
>
> Lóránt Perger wrote:
> > I suppose I should have looked a bit more into this before opening this
> > thread, but oh well, no use crying over spilled milk. I looked into how PW
> > replicates PA's module loading... and turns out it doesn't (
> > https://github.com/PipeWire/pipewire/blob/master/src/modules/module-protocol-pulse/module.c#L146
> > ). It simply uses an strcmp to check for a single module, which it then
> > replicates.
>
> I also see that the device manager extension is not supported:
> https://github.com/PipeWire/pipewire/blob/master/src/modules/module-protocol-pulse/extension.c#L44
> so configuring output and input devices in the Phonon KCM (in KDE/Plasma
> System Settings) is not going to work with PipeWire.
>

What are you talking about? I seem to be able to select devices and
such. The only thing I don't seem to be able to do is do "advanced
audio settings" which is grayed out and says it requires the
PulseAudio gsettings module. If there's additional functionality
missing, please file an issue at
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues.



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

[Bug 1929916] perl-Log-Any-1.709 is available

[bugzilla]

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

Xavier Bachelot  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
   Assignee|ticot...@gmail.com  |xav...@bachelot.org
   Doc Type|--- |If docs needed, set a value
Last Closed||2021-02-23 14:06:51




-- 
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: Donate 1 minute of your time to test upgrades from F33 to F34

[Geraldo Simião Kutz]

I tried here on a F33 kde spin (on bare metal Acer/intel notebook) and it
worked fine, just as expected:
Instalar48 Pacotes
Atualizar 2019 Pacotes
Remover  5 Pacotes
Desatualizar 2 Pacotes
Tamanho total do download: 1.8 G

regards
Geraldo

FAS: geraldosimiao


Em sáb., 20 de fev. de 2021 às 06:49, Miroslav Suchý 
escreveu:

> Do you want to make Fedora 34 better? Please spend 1 minute of your time
> and try to run:
>
># Run this only if you use default Fedora modules
># next time you run any DNF command default modules will be enabled
> again
>sudo dnf module reset '*'
>
>sudo dnf --releasever=34 --setopt=module_platform_id=platform:f34 \
>  --enablerepo=updates-testing --enablerepo=updates-testing-modular \
>  distro-sync
>
> This command does not replace `dnf system-upgrade`, but it will reveal
> potential problems. You may also run `dnf
> upgrade` before running this command.
>
> If you have have rdma-core.i686 installed you have to pass
> `--allowerasing`.
> https://bugzilla.redhat.com/show_bug.cgi?id=1919864
>
>
> If you get this prompt:
>
>...
>Total download size: XXX M
>Is this ok [y/N]:
>
> you can answer N and nothing happens, no need to test the actual upgrade.
>
> But very likely you get some dependency problem now. In that case, please
> report it against the appropriate package. Or
> against fedora-obsolete-packages if that package should be removed in
> Fedora 34. Please check existing reports against
> fedora-obsolete-packages first:
>https://red.ht/2kuBDPu
> and also there is already bunch of "Fails to install" reports:
>https://bugzilla.redhat.com/show_bug.cgi?id=F34FailsToInstall
>
> Thank you
>
> P.S. sent from workstation successfully upgraded to F34 :)
>
> --
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager, Community Packaging Tools, #brno,
> #fedora-buildsys
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Lennart Poettering]

On Mo, 22.02.21 09:45, Michael Catanzaro (mcatanz...@gnome.org) wrote:
65;6201;1c
> On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz  wrote:
> > 3) Configure DNS resolvers if you want to use DNS.
> > Or dig deeper: why cloud-init disabled DNS on your installation?
>
> I'm pretty sure cloud-init just doesn't know how to configure
> systemd-resolved at all. So I suspect this is a cloud-init bug. See:
> https://pagure.io/fedora-server/issue/10.
>
> I have no strong opinion on whether the fallback should have been removed or
> not. The fallback was only hiding the real problem, after all.

BTW, just to say this clearly. I think this argument is bogus and very
user unfriendly. I think it's generally better to complain to the logs
and still make things work automatically with a fallback than to just
say "Nope, I was given invalid configuration and now I refuse to
work". Because originally this is what resolved did: we had a
last-resort fallback to provide DNS via a bunch of public DNS servers
if nothing else is available, and we log if we are given invalid
config. We use the fallback only as ultimate fallback, when the other
option is to not work at all.

The thing is that if DNS is fucked, then this is a pretty nasty
problem: you need an extremely high level of understanding computers
to be able to fix this. And you can't even get help, because, well,
your DNS is down, you are not getting online.

Hence, it's inherently a *good* thing to have a fallback in place, and
I think it's a disserve to users to turn this off, as it makes systems
much harder to fix.

And yeah, call me a hypocrite, but if I have the choice between having
no Internet at all or using some public DNS servers for DNS, and
leaking a tiny bit of information to those DNS server providers then I
am definitely preferring to have Internet, thank you very much.

One could even go further: the privacy level using those public DNS
servers might actually be higher than using the DHCP-provided ones in
many cases, simple because we can use DoT on the former (admittedly
not yet the default in resolved though, but hopefully soon), but
almost never can on the latter, and what's worse the latter are
usually provided by crappy edge networks like Internet Cafés and such
where the fact we send stuff unencrypted is just awful.

Now, Fedora made its choice here, and I'll accept that, but I still
think it's a bad one, that trades a misunderstood concept of privacy
against a major step forward in userfriendliness. i.e. I am not sure
it's a good choice to limit Fedora's userspace needlessly to people
who can fix their DNS configuration. It's a pretty tiny elite group of
people to be in after all...

(Oh, and I don't appreciate those people at all, who claim that
"resolved sends all DNS lookups" to Google because it's a lie, we
never did that, we only did that in case no better DNS configuration
was available, i.e. as *last* *resort*, one step before giving up
entirely).

Lennart

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

Re: PA module support in PipeWire

[Kevin Kofler via devel]

Lóránt Perger wrote:
> I suppose I should have looked a bit more into this before opening this
> thread, but oh well, no use crying over spilled milk. I looked into how PW
> replicates PA's module loading... and turns out it doesn't (
> https://github.com/PipeWire/pipewire/blob/master/src/modules/module-protocol-pulse/module.c#L146
> ). It simply uses an strcmp to check for a single module, which it then
> replicates.

I also see that the device manager extension is not supported:
https://github.com/PipeWire/pipewire/blob/master/src/modules/module-protocol-pulse/extension.c#L44
so configuring output and input devices in the Phonon KCM (in KDE/Plasma 
System Settings) is not going to work with PipeWire.

IMHO, PipeWire is not ready to be the default at all.

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

Re: Automatizing package review process

[Ben Cotton]

On Mon, Feb 22, 2021 at 1:16 PM Kevin Fenzi  wrote:
>
> Could we do away with using bugzilla entirely and just keep info in app?
>
No. Well, "yes, but with some considerations." The main thing with the
Bugzilla workflow is the ability to block the FE-LEGAL bug when a
package needs a license or patent review. So any changed workflow
would need:

1. A good way to notify the Fedora Legal Liaison that review is needed
2. A good way to indicate that the review can't be finalized until it
has been given an explicit go-ahead on any legal questions

I have a lot of thoughts about Bugzilla versus not-Bugzilla generally,
but the two above are the ones important to this particular
discussion. Someday when we can go places again, catch me over a
coffee or beer if you want to hear the Extended Thoughts™.

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

Re: PA module support in PipeWire

[Lóránt Perger]

> Well, if the modules can work with PipeWire's PulseAudio replacement, then 
> they ought to be in a subpackage of pulseaudio, yes. (But are they
> binary-compatible or do they actually need to be rebuilt against
> pipewire-pulseaudio?)
>  
> Kevin Kofler

I suppose I should have looked a bit more into this before opening this thread, 
but oh well, no use crying over spilled milk. I looked into how PW replicates 
PA's module loading... and turns out it doesn't ( 
https://github.com/PipeWire/pipewire/blob/master/src/modules/module-protocol-pulse/module.c#L146
 ). It simply uses an strcmp to check for a single module, which it then 
replicates. 

However, I'm genuinely weirded out by this because I have been successfully 
able to load and use the previously mentioned echo cancel module on both Debian 
and Arch and looking into their package source, nothing seems to be that 
functionally different from Fedora's. I fear this means the issue falls way 
outside the jurisdiction of the project, because even if the modules were 
decoupled, one would still have no way of loading them, so I guess I'll really 
just swallow the pill and go back to PA. Nonetheless, if someone feels very 
adventurous and has a better grasp on things than me, I'd love to understand 
what do those packages have that this doesn't, because perhaps then whatever 
this is could be incorporated in this package too.

Lóránt
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 proposal: POWER 4k page size (System-Wide Change proposal)

[Justin Forbes]

On Mon, Feb 22, 2021 at 1:53 PM Alex Perez  wrote:
>
>
>
> Daniel Pocock wrote on 2/22/21 10:41 AM:
> > I feel that you underestimate the impact of the GPU driver issue
> >
> > If the GPU driver doesn't work, people can't even log in and get started
> >
> > If the GPU vendors don't test their code on ppc64le (and aarch64) then
> > those platforms will always lag behind x86.  Users will experience
> > issues that have been fixed in the development phase for x86.
> >
> > Personally, I'm not opposed to the 64k page size in principle: my
> > concerns are about the practical issues.
> >
> > If both 4k and 64k can be supported, if users can choose between
> > installers for either page size, then the severity of the issue is reduced
>
> How practical/impractical would it be to simply compile the ppc64le
> kernel for both page sizes, and then add a boot entry to GRUB for 4k
> page sizes, which is not the default.
>
> Another option could be an official ppc64le-4K Fedora Spin.

Not practical at all. This is not just a simple matter of building
another flavor of kernel, though even that is a lot to ask, and
honestly, we have turned off flavors that had more users than I expect
ppc64le workstation will have any time soon.  But you still have the
issue of writing special casing code for dnf at the very least.  To be
a full solution you would also need such code in anaconda and image
building tools.

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

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Marius Schwarz]

Am 22.02.21 um 11:17 schrieb Zbigniew Jędrzejewski-Szmek:

1) Use different defaults for different Fedora editions, e.g. container
and cloud images include the fallback DNS servers list while
workstation (and similar) images don't.

Yes, I think this would be the way to go.
Everything, that is not prepresenting a person, is not regulated by 
GDPR, therefor it does not "need" to comply.


About fallbacks in general:

Es the example shows cleary to me, having fallback dns means, that you 
do not see, that your dns config is faulty

and will fail in unexpected ways.

Best regards,
Marius


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

Thanks for your note, I will look at the dependent packages (they were
selected ~1 month ago). But technically, it does not disturb us if some
package does not require on autoconf and builds successfully. We have to
focus on failed builds and investigate where the problem is.

Ondrej

On Tue, Feb 23, 2021 at 12:55 PM Ian McInerney 
wrote:

> On Tue, Feb 23, 2021 at 10:38 AM Ondrej Dubaj  wrote:
>
>> Hello,
>>
>> please see attached rebuild of autoconf-dependencies [1]. I would like to
>> ask maintainers of the dependent packages to check if their packages are
>> buildable with autoconf-2.71. It seems that lots of packages are checking
>> for exactly version 2.69, which blocks the build and there might be no
>> problem with version 2.71. Also there are some minor issues (unresolved
>> dependencies, failure in %check phase,...), which can be resolved by a
>> small fix. Please investigate the appropriate copr builds. If your fix is
>> ready, just push it to the rawhide branch and it will be automatically
>> rebuilt with the new autoconf-2.71 in copr. Most of the packages are
>> successfully built with autoconf (~1450 from ~1600), so there are ~150
>> packages to investigate.
>>
>> Attaching also results from a tester launched by Jeff Law [2] (accessible
>> only on Red Hat VPN) which shows changes of packages with autoconf-2.69 and
>> autoconf-2.71. This may help to understand the changes better.
>>
>> Thank you for your cooperation!
>>
>> Ondrej.
>>
>> [1]
>> https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/
>> [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/
>>
>>
> How did you find the dependent packages? I would suggest updating the
> dependent packages list again, since audacity can be removed from the list
> of packages needing a rebuild since you are using 2.4.2. That release
> switched to CMake from autotools because upstream unceremoniously removed
> the entire autotools build system in the patch release.
>
> -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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Ian McInerney]

On Tue, Feb 23, 2021 at 10:38 AM Ondrej Dubaj  wrote:

> Hello,
>
> please see attached rebuild of autoconf-dependencies [1]. I would like to
> ask maintainers of the dependent packages to check if their packages are
> buildable with autoconf-2.71. It seems that lots of packages are checking
> for exactly version 2.69, which blocks the build and there might be no
> problem with version 2.71. Also there are some minor issues (unresolved
> dependencies, failure in %check phase,...), which can be resolved by a
> small fix. Please investigate the appropriate copr builds. If your fix is
> ready, just push it to the rawhide branch and it will be automatically
> rebuilt with the new autoconf-2.71 in copr. Most of the packages are
> successfully built with autoconf (~1450 from ~1600), so there are ~150
> packages to investigate.
>
> Attaching also results from a tester launched by Jeff Law [2] (accessible
> only on Red Hat VPN) which shows changes of packages with autoconf-2.69 and
> autoconf-2.71. This may help to understand the changes better.
>
> Thank you for your cooperation!
>
> Ondrej.
>
> [1] https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/
> [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/
>
>
How did you find the dependent packages? I would suggest updating the
dependent packages list again, since audacity can be removed from the list
of packages needing a rebuild since you are using 2.4.2. That release
switched to CMake from autotools because upstream unceremoniously removed
the entire autotools build system in the patch release.

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

Re: Fedora's GPG key in DNS(SEC)

[Petr Menšík]

On 2/23/21 9:30 AM, Miroslav Suchý wrote:
> Dne 22. 02. 21 v 21:11 Petr Menšík napsal(a):
>> as a bind-utils maintainer, I have to ask. Why is dig -t TYPE61 used,
>> when all stable Fedora supports dig -t OPENPGPKEY just fine. Type61
>> might be used as fallback for older releases
> 
> Because I did not knew that -t OPENPGPKEY can be used. :) No other reason.
> 
Every type it can display on output is accepted also in input. Only
types printed as TYPEX, where it does not know them, have to be used
with numbered types.

It can be emulated by dig +unknownformat for any known type too.

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



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

Re: Donate 1 minute of your time to test upgrades from F33 to F34

[Zbigniew Jędrzejewski-Szmek]

On Tue, Feb 23, 2021 at 09:27:45AM +0100, Miroslav Suchý wrote:
> Dne 23. 02. 21 v 1:15 Nathanael D. Noblet napsal(a):
> >Error:
> >  Problem: package empathy-1:3.12.14-7.fc29.x86_64 requires
> >libfolks.so.25()(64bit), but none of the providers can be installed
> >   - folks-1:0.14.0-5.fc33.x86_64 does not belong to a distupgrade
> >repository
> >   - problem with installed package empathy-1:3.12.14-7.fc29.x86_64
> >(try to add '--skip-broken' to skip uninstallable packages)
> 
> If the package cause problem during an upgrade we are removing it
> using fedora-obsolete-packages (please open an issue there).
> If it does not cause a problem during an upgrade we are just leaving it 
> behind.

fedora-obsolete-packages-34-14 will remove it.

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

Re: Automatizing package review process

[Miroslav Suchý]

Dne 22. 02. 21 v 19:09 Kevin Fenzi napsal(a):

- When all tests pass, have the package repository automatically created
in git, import the srpm and fire the build in Rawhide. This will ensure
that what is approved is what is packaged - later changes will be
tracked and noted. It will also avoid users to create releng tickets and
releng folks waste their precious time handling those tickets.

Perhaps you could leverage copr here for all the building and git?
Then you just need to import from copr-dist-git and it handles all the
building,etc.


FYI https://pagure.io/copr/copr/pull-request/1676
This has been merged and will be in the next release of Copr.

If we miss any API call you need, just let me know.

--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Tadej Janež]

On Tue, 2021-02-23 at 11:18 +0100, Petr Menšík wrote:
> Sure, this part is more complex. But only this part can fix this
> problem
> from inside the container IMO. Ie. we could fix it faster for any
> involved parties.
> 
> I don't really run any container on any cloud service so this is just
> my
> guess. Who uses cloud-init to prepare the container? If it is used by
> cloud provider, I would expect slow updates and conservative
> behavior.
> Even if we fix it immediately, how fast would appear on the service?
> I
> think the fix from within can be much sooner be used by users.

I think there might be a slight confusion here.

The use case I'm talking about doesn't involve any containers and how
DNS resolving is performed therein.

I'm thinking in terms of a vanilla Fedora Cloud image being used to
provision a new VM and cloud-init performing its configuration and
initialization.
This use case is currently broken (i.e. DNS resolution is broken),
since cloud-init doesn't properly configure DNS servers and fallback
DNS servers have been removed.

To fix this use case, we would just need to patch cloud-init as you
described in your 1. solution:

cloud-init would check the symlink and target of etc/resolv.conf. If it
points to /run/systemd/resolve/*, write DNS=x y into
/etc/systemd/resolved.conf.d/*cloud-init.conf

And then propose the patch to cloud-init upstream and include it in
Fedora's cloud-init package for Fedora 34.

As I see it, this could be fixed by Fedora itself and is not blocked on
any cloud provider or other external party?



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

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

[Ondrej Dubaj]

Hello,

please see attached rebuild of autoconf-dependencies [1]. I would like to
ask maintainers of the dependent packages to check if their packages are
buildable with autoconf-2.71. It seems that lots of packages are checking
for exactly version 2.69, which blocks the build and there might be no
problem with version 2.71. Also there are some minor issues (unresolved
dependencies, failure in %check phase,...), which can be resolved by a
small fix. Please investigate the appropriate copr builds. If your fix is
ready, just push it to the rawhide branch and it will be automatically
rebuilt with the new autoconf-2.71 in copr. Most of the packages are
successfully built with autoconf (~1450 from ~1600), so there are ~150
packages to investigate.

Attaching also results from a tester launched by Jeff Law [2] (accessible
only on Red Hat VPN) which shows changes of packages with autoconf-2.69 and
autoconf-2.71. This may help to understand the changes better.

Thank you for your cooperation!

Ondrej.

[1] https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/
[2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/

On Fri, Feb 12, 2021 at 11:00 PM David Cantrell 
wrote:

> Sounds good.  Just find me on IRC or by email and let me know what you
> would like help on.  I can help run/monitor scripts of builds and help
> script reporting to BZ for things that fail.
>
> Thanks,
>
> On Thu, Feb 11, 2021 at 03:55:41PM +0100, Ondrej Dubaj wrote:
> >Thank you for your advice and willingness to help with testing. There is a
> >plan to create a side tag and test appropriate changes there.
> >
> >Changed category to system-wide change.
> >
> >Ondrej
> >
> >On Thu, Feb 11, 2021 at 3:42 PM David Cantrell 
> wrote:
> >
> >> On Wed, Feb 10, 2021 at 12:30:20PM -0700, 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.
> >>
> >> +1
> >>
> >> autoconf changes are a big build impact and [most?] maintainers like
> >> to avoid surprises here.
> >>
> >> >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.
> >>
> >> This is a good idea.  But really, I would like to see packages that
> >> run autoconf during build to be checked.  I do not think it is
> >> sufficient to just check a subset of packages or even one particular
> >> use case.  I think to do this with minimal impact, we kind of need to
> >> make sure everything using autoconf has incorporated the necessary
> >> changes for autoconf-2.71.  In many cases, things may be ready to go.
> >> But I don't think we can assume that.
> >>
> >> The approach mhroncok@ and others have used for major Python changes I
> >> think could be applied here.  As an autoconf user [under duress, but
> >> still, I have to rely on it], I would like the opportunity to have an
> >> autoconf-2.71 side tag to verify my packages build there before we
> >> update rawhide with 2.71.  We could automate builds to test things out
> >> and file bugs for package maintainers for failures.  I know this is 

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Petr Menšík]

Hi Tadej,

thanks for confirmation.

On 2/23/21 10:37 AM, Tadej Janež wrote:
> Petr,
> 
> thanks for looking into this.
> 
> On Mon, 2021-02-22 at 18:30 +0100, Petr Menšík wrote:
>> After a quick glance at cloud-init code, it seems to me it does not
>> check /etc/resolv.conf for symlinks.
>>
>> It just reads /etc/resolv.conf if it is a file, then writes its own
>> nameservers into target. I have seen no rm of original
>> /etc/resolv.conf,
>> so I guess it rewritten target of symlink on Fedora 33:
>> /run/systemd/resolve/stub-resolv.conf
> 
> Indeed, cloud-init just "blindly" amends the /etc/resolv.conf file
> which is a symlink to /run/systemd/resolve/stub-resolv.conf and hence
> gets overwritten by systemd-resolved.
> 
> Here are the relevant snippets from a DigitalOcean instance's
> /var/log/cloud-init.log:
> 
> ... trimmed ...
>  digitalocean.py[DEBUG]: added dns servers: ['67.207.67.2',
> '67.207.67.3']
> ... trimmed ...
> __init__.py[DEBUG]: Selected renderer 'sysconfig' from priority list:
> None
> util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth1 -
> wb: [644] 212 bytes
> util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
> scripts/ifcfg-eth1 (recursive=False)
> util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
> scripts/ifcfg-eth1 (recursive=False)
> util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth0 -
> wb: [644] 287 bytes
> util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
> scripts/ifcfg-eth0 (recursive=False)
> util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
> scripts/ifcfg-eth0 (recursive=False)
> util.py[DEBUG]: Reading from /etc/resolv.conf (quiet=False)
> util.py[DEBUG]: Read 729 bytes from /etc/resolv.conf
> util.py[DEBUG]: Writing to /etc/resolv.conf - wb: [644] 846 bytes
> util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub-
> resolv.conf (recursive=False)
> util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub-
> resolv.conf (recursive=False)
> util.py[DEBUG]: Writing to /etc/NetworkManager/conf.d/99-cloud-
> init.conf - wb: [644] 89 bytes
> util.py[DEBUG]: Restoring selinux mode for
> /etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False)
> util.py[DEBUG]: Restoring selinux mode for
> /etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False)
> util.py[DEBUG]: Writing to /etc/udev/rules.d/70-persistent-net.rules -
> wb: [644] 192 bytes
> util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70-
> persistent-net.rules (recursive=False)
> util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70-
> persistent-net.rules (recursive=False)
> ... trimmed ...
> 
>> I think there are two possible fixes:
>> * cloud-init would check the symlink and target of etc/resolv.conf.
>> If
>> it points to /run/systemd/resolve/*, write DNS=x y into
>> /etc/systemd/resolved.conf.d/*cloud-init.conf
> 
> I think this option would be preferred.
> 
>> * clound-init would always delete etc/resolv.conf before it writes
>> into
>> it, if it was symlink.
> 
> I guess this is a simple solution that would work, but from what I
> understand it would also disable the use of systemd-resolved?

Well, partially. It wouldn't disable systemd-resolved service, but would
not direct DNS messages to resolved. It would still cache requests done
via nss, typically via getaddrinfo() or gethostbyname() function. That
was intention of cloud-init anyway. Personally I would prefer cache on
the host instead of in each container.
> 
>> * systemd-resolved would check contents of link target of
>> /etc/resolv.conf on startup. If it leads to systemd, try parsing its
>> contents. If it does not look like managed contents of systemd,
>> assume
>> it might be misdirected resolv.conf configuration. Store it and wait
>> for
>> DHCP configuration. If no better configuration arrives, use
>> nameservers
>> from misdirected file. Would have to restore original resolv.conf on
>> shutdown to keep working after restarts. Should move it to
>> fallback.conf
>> and use it instead of built-in fallbacks?
> 
> This seems too complex and error prone.
> 
> Regards,
> Tadej
It could just always move file without its own header to
/run/systemd/resolved/fallback.conf (or maybe some permanent). When no
better configuration was set, use this file as nameservers source,
instead of built-in defaults. It would omit saving that files.

Sure, this part is more complex. But only this part can fix this problem
from inside the container IMO. Ie. we could fix it faster for any
involved parties.

I don't really run any container on any cloud service so this is just my
guess. Who uses cloud-init to prepare the container? If it is used by
cloud provider, I would expect slow updates and conservative behavior.
Even if we fix it immediately, how fast would appear on the service? I
think the fix from within can be much sooner be used by users.

Who uses cloud-init to prepare containers? Is it end user on his system?

Re: Donate 1 minute of your time to test upgrades from F33 to F34

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 22, 2021 at 11:36:45AM -0500, Solomon Peachy wrote:
> >   sudo dnf module reset '*'
> > 
> >   sudo dnf --releasever=34 --setopt=module_platform_id=platform:f34 \
> >     --enablerepo=updates-testing --enablerepo=updates-testing-modular \
> >     distro-sync
> 
> F32 x86_64 server:
> 
> Error: 
>  Problem 1: package python3-blindspin-2.0.1-9.fc32.noarch requires 
> python(abi) = 3.8, but none of the providers can be installed
>   - python3-3.8.7-2.fc32.x86_64 does not belong to a distupgrade repository
>   - problem with installed package python3-blindspin-2.0.1-9.fc32.noarch

It got retired after being orphaned for 6+ weeks. I'll add to
fedora-obsolete-packages.

> F33 x86_64 workstation #1:
> 
> Error: 
>  Problem 1: problem with installed package 
> gr-fcdproplus-3.8.0-3.20200807git06069c2e.fc33.x86_64
>   - package gr-fcdproplus-3.8.0-3.20200807git06069c2e.fc34.x86_64 requires 
> libgnuradio-pmt.so.3.8.2()(64bit), but none of the providers can be installed

gnuradio has libgnuradio-pmt.so.3.9.0()(64bit), gr-fcdproplus needs a rebuild.

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

Re: Donate 1 minute of your time to test upgrades from F33 to F34

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 22, 2021 at 10:41:01AM +, Sven Kieske wrote:
> Error: 
>  Problem: package gnome-tour-40~beta-3.fc34.x86_64 obsoletes 
> gnome-getting-started-docs < 3.38.1-2 provided by 
> gnome-getting-started-docs-3.38.0-2.fc34.noarch
>   - package gnome-initial-setup-40~beta-1.fc34.x86_64 requires gnome-tour, 
> but none of the providers can be installed
>   - package gnome-getting-started-docs-de-3.38.0-2.fc34.noarch requires 
> gnome-getting-started-docs = 3.38.0-2.fc34, but none of the providers can be 
> installed
>   - problem with installed package gnome-initial-setup-3.36.4-1.fc32.x86_64
>   - problem with installed package 
> gnome-getting-started-docs-de-3.36.2-1.fc32.noarch
>   - gnome-initial-setup-3.36.4-1.fc32.x86_64 does not belong to a distupgrade 
> repository
>   - gnome-getting-started-docs-de-3.36.2-1.fc32.noarch does not belong to a 
> distupgrade repository
> (try to add '--skip-broken' to skip uninstallable packages)

https://src.fedoraproject.org/rpms/gnome-tour/c/665b7da52787e1caa06256a34e1be3f68d39ef76
Building in rawhide now.

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

[Bug 1931789] perl-Clipboard-0.28 is available

[bugzilla]

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

Xavier Bachelot  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
   Assignee|mkre...@gmail.com   |xav...@bachelot.org
   Doc Type|--- |If docs needed, set a value
Last Closed||2021-02-23 09:44:45




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

Fedora-Cloud-32-20210223.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-20210222.0):

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

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

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Tadej Janež]

Petr,

thanks for looking into this.

On Mon, 2021-02-22 at 18:30 +0100, Petr Menšík wrote:
> After a quick glance at cloud-init code, it seems to me it does not
> check /etc/resolv.conf for symlinks.
> 
> It just reads /etc/resolv.conf if it is a file, then writes its own
> nameservers into target. I have seen no rm of original
> /etc/resolv.conf,
> so I guess it rewritten target of symlink on Fedora 33:
> /run/systemd/resolve/stub-resolv.conf

Indeed, cloud-init just "blindly" amends the /etc/resolv.conf file
which is a symlink to /run/systemd/resolve/stub-resolv.conf and hence
gets overwritten by systemd-resolved.

Here are the relevant snippets from a DigitalOcean instance's
/var/log/cloud-init.log:

... trimmed ...
 digitalocean.py[DEBUG]: added dns servers: ['67.207.67.2',
'67.207.67.3']
... trimmed ...
__init__.py[DEBUG]: Selected renderer 'sysconfig' from priority list:
None
util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth1 -
wb: [644] 212 bytes
util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
scripts/ifcfg-eth1 (recursive=False)
util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
scripts/ifcfg-eth1 (recursive=False)
util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth0 -
wb: [644] 287 bytes
util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
scripts/ifcfg-eth0 (recursive=False)
util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
scripts/ifcfg-eth0 (recursive=False)
util.py[DEBUG]: Reading from /etc/resolv.conf (quiet=False)
util.py[DEBUG]: Read 729 bytes from /etc/resolv.conf
util.py[DEBUG]: Writing to /etc/resolv.conf - wb: [644] 846 bytes
util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub-
resolv.conf (recursive=False)
util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub-
resolv.conf (recursive=False)
util.py[DEBUG]: Writing to /etc/NetworkManager/conf.d/99-cloud-
init.conf - wb: [644] 89 bytes
util.py[DEBUG]: Restoring selinux mode for
/etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False)
util.py[DEBUG]: Restoring selinux mode for
/etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False)
util.py[DEBUG]: Writing to /etc/udev/rules.d/70-persistent-net.rules -
wb: [644] 192 bytes
util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70-
persistent-net.rules (recursive=False)
util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70-
persistent-net.rules (recursive=False)
... trimmed ...

> I think there are two possible fixes:
> * cloud-init would check the symlink and target of etc/resolv.conf.
> If
> it points to /run/systemd/resolve/*, write DNS=x y into
> /etc/systemd/resolved.conf.d/*cloud-init.conf

I think this option would be preferred.

> * clound-init would always delete etc/resolv.conf before it writes
> into
> it, if it was symlink.

I guess this is a simple solution that would work, but from what I
understand it would also disable the use of systemd-resolved?

> * systemd-resolved would check contents of link target of
> /etc/resolv.conf on startup. If it leads to systemd, try parsing its
> contents. If it does not look like managed contents of systemd,
> assume
> it might be misdirected resolv.conf configuration. Store it and wait
> for
> DHCP configuration. If no better configuration arrives, use
> nameservers
> from misdirected file. Would have to restore original resolv.conf on
> shutdown to keep working after restarts. Should move it to
> fallback.conf
> and use it instead of built-in fallbacks?

This seems too complex and error prone.

Regards,
Tadej



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

Re: Automatizing package review process

[Mattia Verga via devel]

Il 22/02/21 19:09, Kevin Fenzi ha scritto:
> On Sun, Feb 21, 2021 at 05:24:06PM +, Mattia Verga via devel wrote:
>> Hello folks,
>>
>> during the last winter holidays I've started to write a new flask app to
>> automatize the new package submission process. The goals of this app
>> would be:
> Awesome. Thanks for working on it!
>
>> - Get rid of manually open and manage Bugzilla tickets. Have the ticket
>> filed in a web form (or maybe by CLI), and have the ticket workflow
>> managed automatically.
> Could we do away with using bugzilla entirely and just keep info in app?

Yes, I meant "get rid of the whole BZ workflow", by managing tickets in
the new system (like Bodhi).

Mattia

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

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Clipboard-0.28-1.fc32.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=62566166


-- 
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 1931789] perl-Clipboard-0.28 is available

[bugzilla]

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



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


-- 
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 1931789] New: perl-Clipboard-0.28 is available

[bugzilla]

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

Bug ID: 1931789
   Summary: perl-Clipboard-0.28 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Clipboard
  Keywords: FutureFeature, Triaged
  Assignee: mkre...@gmail.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: c...@alum.wpi.edu, iarn...@gmail.com,
mkre...@gmail.com, perl-devel@lists.fedoraproject.org,
xav...@bachelot.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.28
Current version/release in rawhide: 0.27-1.fc35
URL: http://search.cpan.org/dist/Clipboard/

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


-- 
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 1931380] perl-Term-ReadLine-Gnu-1.40 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Term-ReadLine-Gnu-1.39 |perl-Term-ReadLine-Gnu-1.40
   |is available|is available



--- Comment #2 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.40
Current version/release in rawhide: 1.37-2.fc34
URL: http://search.cpan.org/dist/Term-ReadLine-Gnu/

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


-- 
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: Fedora's GPG key in DNS(SEC)

[Miroslav Suchý]

Dne 22. 02. 21 v 21:11 Petr Menšík napsal(a):

as a bind-utils maintainer, I have to ask. Why is dig -t TYPE61 used,
when all stable Fedora supports dig -t OPENPGPKEY just fine. Type61
might be used as fallback for older releases


Because I did not knew that -t OPENPGPKEY can be used. :) No other reason.

--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Donate 1 minute of your time to test upgrades from F33 to F34

[Miroslav Suchý]

Dne 22. 02. 21 v 23:52 Zbigniew Jędrzejewski-Szmek napsal(a):

Error: Unknown repo: 'updates-testing-modular'

That's not an error really. You don't have 'fedora-repos-modular'
package installed, so this repository is not available. Miroslav's
command simply assumes that you have modules enabled.



*nod* Previously, it was part of fedora-repos and you could not remove it. Just 
disable.
Now you can remove it.
I will ammend fedora-upgrade script and next time the email.
Nice catch.

--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Donate 1 minute of your time to test upgrades from F33 to F34

[Miroslav Suchý]

Dne 23. 02. 21 v 1:15 Nathanael D. Noblet napsal(a):

Error:
  Problem: package empathy-1:3.12.14-7.fc29.x86_64 requires
libfolks.so.25()(64bit), but none of the providers can be installed
   - folks-1:0.14.0-5.fc33.x86_64 does not belong to a distupgrade
repository
   - problem with installed package empathy-1:3.12.14-7.fc29.x86_64
(try to add '--skip-broken' to skip uninstallable packages)


If the package cause problem during an upgrade we are removing it using fedora-obsolete-packages (please open an issue 
there).

If it does not cause a problem during an upgrade we are just leaving it behind.

--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Donate 1 minute of your time to test upgrades from F33 to F34

[Miroslav Suchý]

Dne 22. 02. 21 v 16:47 Marián Konček napsal(a):

Error:
  Problem 2: rdma-core-33.0-2.fc33.i686 has inferior architecture
   - rdma-core-33.0-2.fc33.x86_64 does not belong to a distupgrade repository
   - problem with installed package rdma-core-33.0-2.fc33.i686




If you have have rdma-core.i686 installed you have to pass `--allowerasing`.
https://bugzilla.redhat.com/show_bug.cgi?id=1919864


^ This.

--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

License change: R-withr GPLv2+ -> MIT

[Elliott Sales de Andrade]

As in title; updates will be made to all releases.

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