Re: Fedora 34 Change: Remove Python2 RPM Macros (Self-Contained Change proposal)

[Nico Kadel-Garcia]

On Sat, Jan 16, 2021 at 2:50 AM Miro Hrončok  wrote:
>
> On 15. 01. 21 22:49, Neal Gompa wrote:
> > I would really rather not have this happen until we're going to retire
> > Python 2 entirely. The Python 2 macros are already separate from the
> > Python 3 ones, so we could just leave them alone until we're ready to
> > just remove Python 2 entirely.
>
> My point here is that I want to keep Python 2 much longer (for developers who
> unfortunately still need to support it, e.g. for RHEL 7) than I'd like to keep
> allowing packages to buiid with it.

May I suggest "don't bother". The ongoing requirement of python2 for
RPM in RHEL 7 should not hinder any other work. Tools published using
python 2 should, in almost all cases, be upgraded to to python 3 for
stability and supportability. I'm particularly staring at tools in
EPEL, such as awscli and ansible.

> Similarly there are no macros for Python 3.5 or 3.7 in Fedora, but the Pythons
> are available.

And it's a problem for people who use EPEL and who use Amazon Linux 2,
which chose to jump to python 3.7 as the base for python 3 rather than
python 3.6 as RHEL 7 and RHEL 8 did.

> I'd also like to stop worrying about compatibility of the Python RPM 
> generators
> with Python 2 packages (it gets extremely hard to test, as the real word
> scenarios in Fedora are currently almost non-existent).

Yeah, especially when you start trying to chase down the dependency
chains. Don't get me started on the circular dependencies for subtly
distinct versions of "sphinx" expanding those dependency chains.Or get
me going on the unwelcome and unnecessary "bundling of three distinct
AWS published modules into the "s3transfer" package.

> > Moving the Python 2 macro files (and the python2-rpm-macros package)
> > from the python-rpm-macros package to the python27 package would also
> > simplify this eventual retirement.
>
> That might be the way if the proposal is rejected (or reduced to generators
> only), I'll keep that in mind, thanks.
>
> On 15. 01. 21 22:59, Igor Raits wrote:
>  > Fully agree here, unless we are really going to drop python2 stuff 
> completely
>  > from distribution.
>
> We are really removing the Python 2 "stuff" (except for the interpreter 
> itself)
> from the distribution, slowly but steadily. This change does not in general
> impact packages that happen to need Python 2 to build only, it only impacts a
> dozen of "Python 2 packages".
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How to build CPM.cmake packages?

[Bob Hepple]

Thanks Vitaly,

I'll follow up on that this week.

Cheers


Bob

On Sat, 16 Jan 2021 at 20:45, Vitaly Zaitsev via devel
 wrote:
>
> On 16.01.2021 08:57, Bob Hepple wrote:
> > Any ideas how to overcome this?
>
> UPD: CPM can use packaged versions[1]. You just need to forward
> -DCPM_USE_LOCAL_PACKAGES:BOOL=TRUE.
>
> Example:
>
> %build
> %cmake \
>  -DCPM_USE_LOCAL_PACKAGES:BOOL=TRUE \
>  -DCPM_LOCAL_PACKAGES_ONLY:BOOL=TRUE
>
> [1]: https://github.com/TheLartians/CPM.cmake#cpm_use_local_packages
>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bd945e3b55   
adplug-2.3.3-1.el8 audacious-plugins-4.0.5-3.el8
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e976495093   
coturn-4.5.2-1.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-47ea069c76   
chromium-87.0.4280.141-1.el8


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

castxml-0.4.2-1.el8
preproc-0.5-1.el8

Details about builds:



 castxml-0.4.2-1.el8 (FEDORA-EPEL-2021-1e2f276b60)
 C-family abstract syntax tree XML output tool

Update Information:

CastXML 0.4.2.

ChangeLog:

* Sat Jan 16 2021 Mattias Ellert  - 0.4.2-1
- Update to version 0.4.2
* Thu Jan 14 2021 Mattias Ellert  - 0.4.1-1
- Update to version 0.4.1
* Thu Jan 14 2021 Mattias Ellert  - 0.4.0-1
- Update to version 0.4.0
- Fix expected test output on 32-bit architectures (i686/armv7hl)

References:

  [ 1 ] Bug #1915610 - castxml-0.4.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1915610
  [ 2 ] Bug #1916976 - castxml-0.4.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1916976




 preproc-0.5-1.el8 (FEDORA-EPEL-2021-e725ad2cb1)
 Simple text preprocessor

Update Information:

Adds tests to building process

ChangeLog:

* Sat Jan 16 2021 clime  0.5-1
- we need to sed python version also in %check section of spec
* Sat Jan 16 2021 clime  0.4-1
- fix tests, add correct requires and buildrequires
* Sun Jan  3 2021 clime  0.3-1
- test preproc when building


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

Re: Fedora 34 Mass Rebuild

[Daniel Pocock]

On 15/01/2021 20:31, Mohan Boddu wrote:
> Hi all,
> 
> Per the Fedora 34 schedule[1] we will start a mass rebuild for Fedora 34
> on Jan 20th 2021. We will run a mass rebuild for Fedora 34 for the
> changes listed in:
> 
> https://pagure.io/releng/issues?status=Open=mass+rebuild


The ppc64le 4k page size is listed there, do you need any pull request
from me to adapt the ppc64le kernel config or anything else or it is
already in hand?

Feel free to reply here or through the Pagure issue

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

Re: [ELN] How to handle RHEL-specific changes when it fails in ELN?

[Nico Kadel-Garcia]

On Sat, Jan 16, 2021 at 4:54 PM Kevin Kofler via devel
 wrote:
>
> Miro Hrončok wrote:
> > See also:
> > https://src.fedoraproject.org/rpms/rust-bootupd/c/c6cf7f6492e0d943e8471f86719df89eed587f6a?branch=master
>
> This is a blatant violation of Fedora packaging guidelines and ought to be
> reverted immediately.
>
> Kevin Kofler

And where and how, precisely, does "rhel require this". Having the
provenance of the source tarballs or git repos is wise and sensible,
and random tarballs with no provenance are a problem for everybody, so
that part is a good idea. But I'm not aware of it as a requirement. Is
anyone else?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1837975] CVE-2020-10543 perl: heap-based buffer overflow in regular expression compiler leads to DoS

[bugzilla]

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

cwarf...@redhat.com changed:

   What|Removed |Added

 CC||cwarf...@redhat.com




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

[Bug 1837988] CVE-2020-10878 perl: corruption of intermediate language state of compiled regular expression due to integer overflow leads to DoS

[bugzilla]

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

cwarf...@redhat.com changed:

   What|Removed |Added

 CC||cwarf...@redhat.com




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

[Bug 1838000] CVE-2020-12723 perl: corruption of intermediate language state of compiled regular expression due to recursive S_study_chunk() calls leads to DoS

[bugzilla]

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

cwarf...@redhat.com changed:

   What|Removed |Added

 CC||cwarf...@redhat.com




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

Re: Fedora 34 Mass Rebuild

[Miro Hrončok]

On 16. 01. 21 20:46, Kevin Fenzi wrote:

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

I've noticedhttps://pagure.io/releng/issue/9829  is not listed here.
Could you please not start the build until make is removed?

Yes, as mentioned in that ticket we are planning on removing make from
the mass rebuild side tag before starting it, and then remove it from
the main buildroot after the mass rebuild if all looks good.


I've only pointed it out because the issue is not tagged with mass-rebuild, so I 
was afraid it might be forgotten. Could somebody with permissiond please tag it?


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

[Bug 1917053] New: perl-ExtUtils-Manifest-1.73 is available

[bugzilla]

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

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



Latest upstream release: 1.73
Current version/release in rawhide: 1.72-457.fc33
URL: http://search.cpan.org/dist/ExtUtils-Manifest/

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


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

Re: [ELN] How to handle RHEL-specific changes when it fails in ELN?

[Kevin Kofler via devel]

Miro Hrončok wrote:
> See also:
> https://src.fedoraproject.org/rpms/rust-bootupd/c/c6cf7f6492e0d943e8471f86719df89eed587f6a?branch=master

This is a blatant violation of Fedora packaging guidelines and ought to be 
reverted immediately.

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

Re: pkg build @ COPR succeeds for F32 chroot, FAILS for F33. .spec issue, or problem in buildenv?

[Fabio Valentini]

On Sat, Jan 16, 2021 at 9:14 PM PGNet Dev  wrote:
>
> On 1/16/21 12:35 PM, PGNet Dev wrote:
> >  + /usr/lib/rpm/brp-strip /usr/bin/strip
> >  /usr/bin/strip: unable to copy file 
> > '/builddir/build/BUILDROOT/dhcpcd-9.4.0-0.pgnd_20210116_172904.fc33.x86_64/usr/local/dhcpcd/sbin/dhcpcd';
> >  reason: Permission denied
> >  error: Bad exit status from /var/tmp/rpm-tmp.3UY5yu (%install)

Other than the file path being weird (/usr/local/dhcpcd/sbin/dhcpcd
???) , have you tried looking at the file permissions on that file?
The error message sounds suspiciously like if the upstream build
system removed read or write access for root from it, or something
like that.
I'm not sure how that would be different on F33 than on F32, but it
can't hurt to check.

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

Re: pkg build @ COPR succeeds for F32 chroot, FAILS for F33. .spec issue, or problem in buildenv?

[PGNet Dev]

On 1/16/21 12:35 PM, PGNet Dev wrote:

 + /usr/lib/rpm/brp-strip /usr/bin/strip
 /usr/bin/strip: unable to copy file 
'/builddir/build/BUILDROOT/dhcpcd-9.4.0-0.pgnd_20210116_172904.fc33.x86_64/usr/local/dhcpcd/sbin/dhcpcd';
 reason: Permission denied
 error: Bad exit status from /var/tmp/rpm-tmp.3UY5yu (%install)



disabling stripping in the rpm spec by adding

%global __os_install_post %{nil}

per,

 "Stripping Binary files in rpmbuild
"
   
https://livecipher.blogspot.com/2012/06/disable-binary-stripping-in-rpmbuild.html


gets past the problem ... both F32 & F33 chroot target builds now succeed

https://copr.fedorainfracloud.org/coprs/pgfed/dhcpcd/build/1885367/

So that's a workaround.

As to _why_ strip has an issue on F33 chroot, dunno yet.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Appdata file location and the packaging guidelines

[Ian McInerney]

I noticed due to an upstream bug report for a project I am on that the Fedora 
packaging guidelines still say that GUI applications should install their files 
as appdata.xml files and not metainfo.xml files 
(https://docs.fedoraproject.org/en-US/packaging-guidelines/AppData/). The 
upstream spec for the appstream says that everything should be installed as 
metainfo.xml files and there are no more appdata.xml files.

I found that there was an issue opened to the packaging committee a year ago 
(https://pagure.io/packaging-committee/issue/944), but there has been no 
comment/follow-up since then. Should the Fedora guidelines be updated to match 
the current spec?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Mass Rebuild

[Kevin Fenzi]

On Sat, Jan 16, 2021 at 08:39:17AM +0100, Miro Hrončok wrote:
> On 15. 01. 21 20:31, Mohan Boddu wrote:
> > Hi all,
> > 
> > Per the Fedora 34 schedule[1] we will start a mass rebuild for Fedora 34
> > on Jan 20th 2021. We will run a mass rebuild for Fedora 34 for the
> > changes listed in:
> > 
> > https://pagure.io/releng/issues?status=Open=mass+rebuild
> 
> I've noticed https://pagure.io/releng/issue/9829 is not listed here.
> Could you please not start the build until make is removed?

Yes, as mentioned in that ticket we are planning on removing make from
the mass rebuild side tag before starting it, and then remove it from
the main buildroot after the mass rebuild if all looks good. 

> Also, https://pagure.io/releng/issue/9910 was rejected.

Right, thanks for the reminder. 

kevin


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

Re: Fedora 34 Mass Rebuild

[Kevin Fenzi]

On Sat, Jan 16, 2021 at 12:43:56AM +0100, Fabio Valentini wrote:
> 
> What system will be used to run the mass rebuild script?

They run on compose-x86-01 I think. 

> If it's a fedora 33 system, I suggest modifying the script to invoke
> rpmdev-bumpspec with the "-D" flag for better compatibiltiy with older
> RPM versions (for people who care about that sort of thing, e.g.
> maintainers who merge specs back into epel branches).

It's currently f32, but we were going to upgrade it. 
We could do that and add this in I think...

Thanks for the suggestion!

kevin


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

pkg build @ COPR succeeds for F32 chroot, FAILS for F33. .spec issue, or problem in buildenv?

[PGNet Dev]

 I'm building a pkg @ COPR, 'dhcpcd',

https://copr.fedorainfracloud.org/coprs/pgfed/dhcpcd/build/1885349/

for both F32 & F33 chroot targets.

The F32 build succeeds, pkg installs & execs OK,


https://download.copr.fedorainfracloud.org/results/pgfed/dhcpcd/fedora-32-x86_64/01885349-dhcpcd/builder-live.log.gz

The concurrent F33 build, with same .spec, FAILs,


https://download.copr.fedorainfracloud.org/results/pgfed/dhcpcd/fedora-33-x86_64/01885349-dhcpcd/builder-live.log.gz

@

...
install -m 0444 dhcpcd-run-hooks.8 
/builddir/build/BUILDROOT/dhcpcd-9.4.0-0.pgnd_20210116_172904.fc33.x86_64/usr/local/dhcpcd/share/man/man8
make[1]: Leaving directory 
'/builddir/build/BUILD/dhcpcd-dhcpcd-9.4.0/hooks'
+ /usr/bin/mkdir -p 
/builddir/build/BUILDROOT/dhcpcd-9.4.0-0.pgnd_20210116_172904.fc33.x86_64/usr/local/etc/dhcpcd
+ find 
/builddir/build/BUILDROOT/dhcpcd-9.4.0-0.pgnd_20210116_172904.fc33.x86_64 -name 
'*.la' -delete -print
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-ldconfig
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip /usr/bin/strip
/usr/bin/strip: unable to copy file 
'/builddir/build/BUILDROOT/dhcpcd-9.4.0-0.pgnd_20210116_172904.fc33.x86_64/usr/local/dhcpcd/sbin/dhcpcd';
 reason: Permission denied
error: Bad exit status from /var/tmp/rpm-tmp.3UY5yu (%install)


RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.3UY5yu (%install)
Finish: rpmbuild dhcpcd-9.4.0-0.pgnd_20210116_172845.fc33.src.rpm
Finish: build phase for dhcpcd-9.4.0-0.pgnd_20210116_172845.fc33.src.rpm
INFO: chroot_scan: 3 files copied to 
/var/lib/copr-rpmbuild/results/chroot_scan
INFO: 
/var/lib/mock/fedora-33-x86_64-1610818126.163401/root/var/log/dnf.rpm.log

/var/lib/mock/fedora-33-x86_64-1610818126.163401/root/var/log/dnf.librepo.log
/var/lib/mock/fedora-33-x86_64-1610818126.163401/root/var/log/dnf.log
ERROR: 
Exception(/var/lib/copr-rpmbuild/results/dhcpcd-9.4.0-0.pgnd_20210116_172845.fc33.src.rpm)
 Config(fedora-33-x86_64) 0 minutes 27 seconds
INFO: Results and/or logs in: /var/lib/copr-rpmbuild/results
INFO: Cleaning up build root ('cleanup_on_failure=True')
Start: clean chroot
INFO: unmounting tmpfs.
Finish: clean chroot
INFO: unmounting tmpfs.
ERROR: Command failed:
# /usr/bin/systemd-nspawn -q -M 1e25f0a21cae4984b852a89713f1da74 -D 
/var/lib/mock/fedora-33-x86_64-1610818126.163401/root -a -u mockbuild --capability=cap_ipc_lock 
--rlimit=RLIMIT_NOFILE=10240 --capability=cap_ipc_lock 
--bind=/tmp/mock-resolv.qfqx7vr9:/etc/resolv.conf --bind=/dev/btrfs-control --bind=/dev/loop-control 
--bind=/dev/loop0 --bind=/dev/loop1 --bind=/dev/loop2 --bind=/dev/loop3 --bind=/dev/loop4 
--bind=/dev/loop5 --bind=/dev/loop6 --bind=/dev/loop7 --bind=/dev/loop8 --bind=/dev/loop9 
--bind=/dev/loop10 --bind=/dev/loop11 --console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash 
--setenv=HOME=/builddir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin 
--setenv=PROMPT_COMMAND=printf "\033]0;\007" 
--setenv=PS1= \s-\v\$  --setenv=LANG=C.UTF-8 --resolv-conf=off bash --login -c 
/usr/bin/rpmbuild -bb --target x86_64 --nodeps /builddir/build/SPECS/dhcpcd.spec

Copr build error: Build failed

So far, I've no idea what F33-chroot-specific issue is causing the problem, 
whether something in my .spec, or in the COPR build env.

Any hints/suggestions as to the cause, and a 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

Re: GNOME Shell startup app issue with /tmp

[Michael Schwendt]

On Sat, 16 Jan 2021 08:44:54 -0600, Michael Catanzaro wrote:

> > Most likely you want to use $XDG_RUNTIME_DIR instead, which is private
> > to your user, and not shared with other users. Use glib's
> > g_get_user_runtime_dir() as a wrapper for accessing that variable.  
> 
> Or g_dir_make_tmp()

No. The created tmp directory must be known to any other CM instances,
and using a mkdtemp variant is not applicable in that case. But Lennart's
suggest of g_get_user_runtime_dir() is plausible. I've sent a question
about that to upstream devs.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: GNOME Shell startup app issue with /tmp

[Michael Schwendt]

On Sat, 16 Jan 2021 15:34:44 +0100, Lennart Poettering wrote:

> Regardless of the actual issue ran into: taking a predictable name
> like that in /tmp/ is a DoS vulnerability. /tmp/ is a shared
> namespace, any local program can take any name in there, and hence
> block you out from starting Claws mail — simply by creating a file or
> directory by that name there under their own ownership.

That would be a mostly theoretical/academical attack vector, since
Claws Mail refusing to start and printing an error message would alert
the user, and the user could take proper action against the attacker.

> Most likely you want to use $XDG_RUNTIME_DIR instead, which is private
> to your user, and not shared with other users. Use glib's
> g_get_user_runtime_dir() as a wrapper for accessing that variable.

From the Claws Mail FAQ:

| Why does Claws Mail allow me to open more than one instance at the same
| time for the same user on a network?
| 
| Claws Mail opens a Unix-domain socket using a name constucted from your
| TMPDIR path plus your UID. This socket is used to arbitrate multiple
| instances on a given machine. In Linux, at least, named Unix-domain
| sockets are known only locally, to the creating machine. Pointing your
| TMPDIR environment variable to /home/yours/tmp doesn't have the desired
| effect, as the socket definition would need to be propagated across the
| LAN and isn't.
| 
| Setting an alternate configuration directory (--alternate-config-dir
| option) overrides TMPDIR value and places the socket under the alternate
| directory.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: GNOME Shell startup app issue with /tmp

[Michael Catanzaro]

On Sat, Jan 16, 2021 at 3:34 pm, Lennart Poettering 
 wrote:

Most likely you want to use $XDG_RUNTIME_DIR instead, which is private
to your user, and not shared with other users. Use glib's
g_get_user_runtime_dir() as a wrapper for accessing that variable.


Or g_dir_make_tmp()

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

Re: GNOME Shell startup app issue with /tmp

[Lennart Poettering]

On Sa, 16.01.21 13:56, Michael Schwendt (mschwe...@gmail.com) wrote:

> Noticed that when setting Claws Mail to become a startup app in F33
> GNOME Shell, it doesn't create its /tmp/claws-mail-$UID directory.

Regardless of the actual issue ran into: taking a predictable name
like that in /tmp/ is a DoS vulnerability. /tmp/ is a shared
namespace, any local program can take any name in there, and hence
block you out from starting Claws mail — simply by creating a file or
directory by that name there under their own ownership.

Most likely you want to use $XDG_RUNTIME_DIR instead, which is private
to your user, and not shared with other users. Use glib's
g_get_user_runtime_dir() as a wrapper for accessing that variable.

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

Re: [ELN] How to handle RHEL-specific changes when it fails in ELN?

[Neal Gompa]

On Sat, Jan 16, 2021 at 2:28 AM Miro Hrončok  wrote:
>
> On 15. 01. 21 20:34, Igor Raits wrote:
> > Hello,
> >
> > My friendly co-maintainers pushed
> > https://src.fedoraproject.org/rpms/stratisd/c/32d87697075a846f9a3feb9ee66058287a91ccde?branch=master
> > 
> > that claims that it makes spec compatible with RHEL (ignore parts that they
> > violate packaging guidelines).
> >
> > However, it might make it RHEL compatible but for sure not ELN compatible.
> > Moreover, I am not aware of any announcements that ELN SIG wants to not 
> > have any
> > rust-* packages for RHEL 9.
>
> Side note: Don't hold a grudge against the co-maintainer, they might have been
> told that this is the way. I suppose that if changes like this have been
> promoted internally, I'd be arguing to have a conversation in Fedora instead,
> without success.
>
> See also:
> https://src.fedoraproject.org/rpms/rust-bootupd/c/c6cf7f6492e0d943e8471f86719df89eed587f6a?branch=master
>

Oh lovely, vendored sources *without* bundled() Provides and full
license information. :(




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

Re: Fedora 34 Change: Remove Python2 RPM Macros (Self-Contained Change proposal)

[Neal Gompa]

On Sat, Jan 16, 2021 at 2:50 AM Miro Hrončok  wrote:
>
> On 15. 01. 21 22:49, Neal Gompa wrote:
> > I would really rather not have this happen until we're going to retire
> > Python 2 entirely. The Python 2 macros are already separate from the
> > Python 3 ones, so we could just leave them alone until we're ready to
> > just remove Python 2 entirely.
>
> My point here is that I want to keep Python 2 much longer (for developers who
> unfortunately still need to support it, e.g. for RHEL 7) than I'd like to keep
> allowing packages to buiid with it.
>
> Similarly there are no macros for Python 3.5 or 3.7 in Fedora, but the Pythons
> are available.
>
> I'd also like to stop worrying about compatibility of the Python RPM 
> generators
> with Python 2 packages (it gets extremely hard to test, as the real word
> scenarios in Fedora are currently almost non-existent).
>
> > Moving the Python 2 macro files (and the python2-rpm-macros package)
> > from the python-rpm-macros package to the python27 package would also
> > simplify this eventual retirement.
>
> That might be the way if the proposal is rejected (or reduced to generators
> only), I'll keep that in mind, thanks.
>

I am okay with disabling the generator for Python 2, since that just
reverts us to the state before we integrated my generator into Fedora
by default (which really wasn't that long ago). But removing the
macros is a step too far for my taste.

The only reason we don't have macros for building against alternate
Python 3 versions is because our macros make that difficult to automate.
One day, maybe we'll be able to fix that...

That said, running the generator on Python 3 doesn't mean it can't
read Python 2 module metadata. The format hasn't actually *changed* to
break that...




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

Re: GNOME Shell startup app issue with /tmp

[Zbigniew Jędrzejewski-Szmek]

On Sat, Jan 16, 2021 at 01:56:26PM +0100, Michael Schwendt wrote:
> Claws Mail relies on g_get_tmp_dir() for retrieval of the path, so it seems
> when the program is launched, either /tmp doesn't exist yet or there are
> problems creating files in it.

systemd sets up the file system very early on, so at the time when a
user session is running, /tmp has been in place for a while.

> /tmp/claws-mail-$UID

I filed a separate bug, https://bugzilla.redhat.com/show_bug.cgi?id=1917005.

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

GNOME Shell startup app issue with /tmp

[Michael Schwendt]

Noticed that when setting Claws Mail to become a startup app in F33
GNOME Shell, it doesn't create its /tmp/claws-mail-$UID directory.

Claws Mail relies on g_get_tmp_dir() for retrieval of the path, so it seems
when the program is launched, either /tmp doesn't exist yet or there are
problems creating files in it.

Has anything changed related to the GNOME startup app procedure?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: protobuf 3.14 update coming to rawhide

[Adrian Reber]

With the upcoming mass rebuild I created a request to have it merged
just now:

https://bodhi.fedoraproject.org/updates/FEDORA-2021-3229c37a83

Adrian

On Fri, Jan 15, 2021 at 12:15:44PM +0100, Petr Menšík wrote:
> Hi Adrian,
> 
> I would like to rebuild new BIND 9.16, once this tag is merged.
> I guess building significant rebase into your tag is not welcome.
> 
> Is there any ETA, when it could be merged? Could you please send me a
> mail, once it is merged? Is there any bug for the rebase I can watch?
> 
> Thanks,
> Petr
> 
> On 1/15/21 10:28 AM, Adrian Reber wrote:
> > On Fri, Jan 15, 2021 at 10:15:11AM +0100, Dan Čermák wrote:
> >> Adrian Reber  writes:
> >>
> >>> On Thu, Jan 07, 2021 at 10:18:37AM +0100, Adrian Reber wrote:
> >>>
> >>> All rebuilds are done, but I have not merged the side tag yet.
> >>
> >> What's the name of the side tag?
> > 
> > Right, I should have mentioned that: f34-build-side-35763
> > 
> > Adrian
> 
> -- 
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemen...@redhat.com
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> 


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

Re: How to build CPM.cmake packages?

[Vitaly Zaitsev via devel]

On 16.01.2021 08:57, Bob Hepple wrote:

Any ideas how to overcome this?


UPD: CPM can use packaged versions[1]. You just need to forward 
-DCPM_USE_LOCAL_PACKAGES:BOOL=TRUE.


Example:

%build
%cmake \
-DCPM_USE_LOCAL_PACKAGES:BOOL=TRUE \
-DCPM_LOCAL_PACKAGES_ONLY:BOOL=TRUE

[1]: https://github.com/TheLartians/CPM.cmake#cpm_use_local_packages

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

Re: How to build CPM.cmake packages?

[Vitaly Zaitsev via devel]

On 16.01.2021 08:57, Bob Hepple wrote:

One of my packages has started to use CPM.cmake
(https://github.com/TheLartians/CPM.cmake) which is a "Setup-free
CMake dependency management" addon script for cmake.


You should ask upstream to make this optional (allow forwarding the 
special configuration flag, for example -DDISABLE_CPM:BOOL=TRUE).



Any ideas how to overcome this?


If the upstream refuses, you will need to manually unbundle, patch and 
remove all CPM functions calls and then start using Cmake's native 
find_package(FOO REQUIRED) instead.


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