date:20201116

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

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

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

[Bug 1898438] New: perl-Search-Xapian-1.2.25.3 is available

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

Bug ID: 1898438
   Summary: perl-Search-Xapian-1.2.25.3 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Search-Xapian
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr,
perl-devel@lists.fedoraproject.org,
rakesh.pan...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.2.25.3
Current version/release in rawhide: 1.2.25.2-7.fc33
URL: http://search.cpan.org/dist/Search-Xapian/

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


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

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

2020-11-16 Thread updates

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a4ade35d32   
java-latest-openjdk-15.0.1.9-1.rolling.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2aa68c5f5e   
tor-0.4.3.7-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-317c124dc0   
rpki-client-6.8p1-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6c93c61069   
pngcheck-2.4.0-2.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b3000c1eea   
seamonkey-2.53.5-2.el8


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

chromium-86.0.4240.198-1.el8
python-aioitertools-0.7.0-1.el8
python-aiolifx-0.6.8-1.el8

Details about builds:



 chromium-86.0.4240.198-1.el8 (FEDORA-EPEL-2020-5b5debb24b)
 A WebKit (Blink) powered web browser

Update Information:

Update to 86.0.4240.198. Fixes the following security issues:  CVE-2020-16013
CVE-2020-16016 CVE-2020-16017    Update to 86.0.4240.183.   Fixes the
following security issues: CVE-2020-16004 CVE-2020-16005 CVE-2020-16006
CVE-2020-16008 CVE-2020-16009  Also disables the very verbose output going to
stdout.    Update to Chromium 86. A few big things here:  1. Upstream has
made hardware accelerated video support (VAAPI) for Linux possible without
patches. One key difference is that the patchset used previously in Fedora
enabled it by default and upstream's approach disables it by default. To enable
Hardware accelerated video in chromium, open this link in chromium:
chrome://flags/#enable-accelerated-video-decode  Be sure it is turned on. Note
that not all GPUs are supported.  2. All the security fixes you expect with a
major release:  CVE-2020-15967 CVE-2020-15968 CVE-2020-15969 CVE-2020-15970
CVE-2020-15971 CVE-2020-15972 CVE-2020-15990  CVE-2020-15991 CVE-2020-15973
CVE-2020-15974 CVE-2020-15975 CVE-2020-15976 CVE-2020-6557  CVE-2020-15977
CVE-2020-15978 CVE-2020-15979 CVE-2020-15980 CVE-2020-15981 CVE-2020-15982
CVE-2020-15983 CVE-2020-15984  CVE-2020-15985 CVE-2020-15986 CVE-2020-15987
CVE-2020-15992 CVE-2020-15988 CVE-2020-15989 CVE-2020-16000  CVE-2020-16001
CVE-2020-16002 CVE-2020-16003  3. The EPEL-7 build no longer requires minizip,
because Red Hat removed that package in RHEL 7.9.  4. Without bats acting as
pollinators, agave and cacao plants would struggle. That means that bats are
responsible for tequila and chocolate.

ChangeLog:

* Thu Nov 12 2020 Tom Callaway  - 86.0.4240.198-1
- update to 86.0.4240.198
* Tue Nov 10 2020 Tom Callaway  - 86.0.4240.193-1
- update to 86.0.4240.193
* Wed Nov  4 2020 Tom Callaway  - 86.0.4240.183-1
- update to 86.0.4240.183
* Mon Nov  2 2020 Tom Callaway  - 86.0.4240.111-2
- fix conditional typo that was causing console logging to be turned on
* Wed Oct 21 2020 Tom Callaway  - 86.0.4240.111-1
- update to 86.0.4240.111
* Tue Oct 20 2020 Tom Callaway  - 86.0.4240.75-2
- use bundled zlib/minizip on el7 (thanks Red Hat. :P)
* Wed Oct 14 2020 Tom Callaway  - 86.0.4240.75-1
- update to 86.0.4240.75
* Mon Sep 28 2020 Tom Callaway  - 85.0.4183.121-2
- rebuild for libevent

References:

  [ 1 ] Bug #1885883 - CVE-2020-15967 chromium-browser: Use after free in 
payments
https://bugzilla.redhat.com/show_bug.cgi?id=1885883
  [ 2 ] Bug #1885884 - CVE-2020-15968 chromium-browser: Use after free in Blink
https://bugzilla.redhat.com/show_bug.cgi?id=1885884
  [ 3 ] Bug #1885885 - CVE-2020-15969 chromium-browser: Use after free in WebRTC
https://bugzilla.redhat.com/show_bug.cgi?id=1885885
  [ 4 ] Bug #1885886 - CVE-2020-15970 chromium-browser: Use after free in NFC
https://bugzilla.redhat.com/show_bug.cgi?id=1885886
  [ 5 ] Bug #1885887 - CVE-2020-15971 chromium-browser: Use after free in 
printing
https://bugzilla.redhat.com/show_bug.cgi?id=1885887
  [ 6 ] Bug #1885888 - CVE-2020-15972 chromium-browser: Use after free in audio
https://bugzilla.redhat.com/show_bug.cgi?id=1885888
  [ 7 ] Bug #1885889 - CVE-2020-15990 chromium-browser: Use after free in 
autofill
https://bugzilla.redhat.com/show_bug.cgi?id=1885889
  [ 8 ] Bug #1885890 - CVE-2020-15991 chromium-browser: Use after free in 
password manager
https://bugzilla.redhat.com/show_bug.cgi?id=1885890
  [ 9 ] Bug #1885891 - CVE-2020-15973 chromium-browser: Insufficient policy 
enforcement in extensions
https://bugzilla.redhat.com/show_bug.cgi?id=1885891
  [ 10 ] Bug #1885892 - CVE-2020-15974 chromium-browser: Integer overflow in 
Blink
https://bugzilla.redhat.com/show_bug.cgi?id=1885892
  [ 11 ] Bug #1885893 - CVE-2020-15975 chromium-browser:

Re: Self Introduction - Jason Edgecombe

2020-11-16 Thread Ken Dreyer

On Sun, Nov 15, 2020 at 5:13 PM Jason Edgecombe  wrote:
> In my personal time, I'm learning a little about fedora packaging in order
> to build some Fedora packages on RHEL8/CENTOS8 for my personal use. I'm
> somewhat familiar with RPM spec files and building RPMs.

Welcome Jason!

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

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

2020-11-16 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-339db397ad   
pngcheck-2.4.0-2.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d69636a383   
tor-0.3.5.12-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0fe15b3c39   
rpki-client-6.8p1-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-62ef58ec56   
openssl11-1.1.1g-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-46fc6c7982   
seamonkey-2.53.5-2.el7


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

chromium-86.0.4240.198-1.el7
python-ldap3-2.8.1-2.el7

Details about builds:



 chromium-86.0.4240.198-1.el7 (FEDORA-EPEL-2020-3097b2d5db)
 A WebKit (Blink) powered web browser

Update Information:

Update to 86.0.4240.198. Fixes the following security issues:  CVE-2020-16013
CVE-2020-16016 CVE-2020-16017    Update to 86.0.4240.183.   Fixes the
following security issues: CVE-2020-16004 CVE-2020-16005 CVE-2020-16006
CVE-2020-16008 CVE-2020-16009  Also disables the very verbose output going to
stdout.    Update to Chromium 86. A few big things here:  1. Upstream has
made hardware accelerated video support (VAAPI) for Linux possible without
patches. One key difference is that the patchset used previously in Fedora
enabled it by default and upstream's approach disables it by default. To enable
Hardware accelerated video in chromium, open this link in chromium:
chrome://flags/#enable-accelerated-video-decode  Be sure it is turned on. Note
that not all GPUs are supported.  2. All the security fixes you expect with a
major release:  CVE-2020-15967 CVE-2020-15968 CVE-2020-15969 CVE-2020-15970
CVE-2020-15971 CVE-2020-15972 CVE-2020-15990  CVE-2020-15991 CVE-2020-15973
CVE-2020-15974 CVE-2020-15975 CVE-2020-15976 CVE-2020-6557  CVE-2020-15977
CVE-2020-15978 CVE-2020-15979 CVE-2020-15980 CVE-2020-15981 CVE-2020-15982
CVE-2020-15983 CVE-2020-15984  CVE-2020-15985 CVE-2020-15986 CVE-2020-15987
CVE-2020-15992 CVE-2020-15988 CVE-2020-15989 CVE-2020-16000  CVE-2020-16001
CVE-2020-16002 CVE-2020-16003  3. The EPEL-7 build no longer requires minizip,
because Red Hat removed that package in RHEL 7.9.  4. Without bats acting as
pollinators, agave and cacao plants would struggle. That means that bats are
responsible for tequila and chocolate.

ChangeLog:

* Thu Nov 12 2020 Tom Callaway  - 86.0.4240.198-1
- update to 86.0.4240.198
* Tue Nov 10 2020 Tom Callaway  - 86.0.4240.193-1
- update to 86.0.4240.193
* Wed Nov  4 2020 Tom Callaway  - 86.0.4240.183-1
- update to 86.0.4240.183
* Mon Nov  2 2020 Tom Callaway  - 86.0.4240.111-2
- fix conditional typo that was causing console logging to be turned on
* Wed Oct 21 2020 Tom Callaway  - 86.0.4240.111-1
- update to 86.0.4240.111
* Tue Oct 20 2020 Tom Callaway  - 86.0.4240.75-2
- use bundled zlib/minizip on el7 (thanks Red Hat. :P)
* Wed Oct 14 2020 Tom Callaway  - 86.0.4240.75-1
- update to 86.0.4240.75
* Mon Sep 28 2020 Tom Callaway  - 85.0.4183.121-2
- rebuild for libevent

References:

  [ 1 ] Bug #1885883 - CVE-2020-15967 chromium-browser: Use after free in 
payments
https://bugzilla.redhat.com/show_bug.cgi?id=1885883
  [ 2 ] Bug #1885884 - CVE-2020-15968 chromium-browser: Use after free in Blink
https://bugzilla.redhat.com/show_bug.cgi?id=1885884
  [ 3 ] Bug #1885885 - CVE-2020-15969 chromium-browser: Use after free in WebRTC
https://bugzilla.redhat.com/show_bug.cgi?id=1885885
  [ 4 ] Bug #1885886 - CVE-2020-15970 chromium-browser: Use after free in NFC
https://bugzilla.redhat.com/show_bug.cgi?id=1885886
  [ 5 ] Bug #1885887 - CVE-2020-15971 chromium-browser: Use after free in 
printing
https://bugzilla.redhat.com/show_bug.cgi?id=1885887
  [ 6 ] Bug #1885888 - CVE-2020-15972 chromium-browser: Use after free in audio
https://bugzilla.redhat.com/show_bug.cgi?id=1885888
  [ 7 ] Bug #1885889 - CVE-2020-15990 chromium-browser: Use after free in 
autofill
https://bugzilla.redhat.com/show_bug.cgi?id=1885889
  [ 8 ] Bug #1885890 - CVE-2020-15991 chromium-browser: Use after free in 
password manager
https://bugzilla.redhat.com/show_bug.cgi?id=1885890
  [ 9 ] Bug #1885891 - CVE-2020-15973 chromium-browser: Insufficient policy 
enforcement in extensions
https://bugzilla.redhat.com/show_bug.cgi?id=1885891
  [ 10 ] Bug #1885892 - CVE-2020-15974 chromium-browser: Integer overflow in 
Blink
https://bugzilla.redhat.com/show_bug.cgi?id=1885892
  [ 11 ] Bug #1885893 - CVE-2020-15975 chromium-browser: Integer overflow in 
SwiftShader

Re: Fedora 34 Change proposal: Stratis 2.2.0 (Self-Contained Change)

2020-11-16 Thread Chris Murphy

On Mon, Nov 16, 2020 at 1:39 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Sun, Nov 15, 2020 at 04:28:36PM -0700, Chris Murphy wrote:
> > On Sun, Nov 15, 2020 at 4:12 AM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > On Wed, Nov 04, 2020 at 01:12:44PM -0500, Ben Cotton wrote:
> > > > * Name: [[User:dkeefe|Dennis Keefe]], [[User:mulhern|Anne Mulhern]],
> > > > [[User:jbaublitz|John Baublitz]]
> > > > * Email: dke...@redhat.com, amulh...@redhat.com, jbaubl...@redhat.com
> > >
> > > > == Upgrade/compatibility impact ==
> > > >
> > > > Stratis symlinks have moved.  Existing symlinks in /stratis/ > > > name>/ will need to be migrated to
> > > > /dev/stratis//.  This is accomplished by
> > > > running the migration script (stratis_migrate_symlinks.sh) that comes
> > > > with the
> > > > 2.2.0 release of Stratis or rebooting the system.  Any configurations
> > > > that make use of the old symlink locations will
> > > > need to be updated to use the new location.  So, if there has been
> > > > manual changes to systemd unit files or /etc/fstab
> > > > for automatically mounting Stratis filesystems, then these will need
> > > > to be updated to reflect the change.
> > >
> > > How large is the risk that systems that were using the old /stratis/foo
> > > paths will fail to mount the filesystems, and possibly fail to boot, after
> > > the upgrade? (Sorry, I have never used stratis, so I don't know how often
> > > those migration steps would be necessary.)
> > >
> > > Shouldn't /startis symlink be created for compatibility on *upgrades* ?
> >
> > It's not supported for booting yet. But if there's an fstab entry
> > using a path from /stratis, and also doesn't include the nofail or
> > noauto mount options, boot can fail waiting indefinitely on a file
> > system that won't ever appear
>
> Right, but the question is: how common is that? Do we even have any general
> idea how many people are using stratis?

No idea. But I think the feature and its release notes can adequately
inform users of the possibility of boot failure and whatever
workaround is needed.


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

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||cpanspec-1.78-27.el8
 Resolution|--- |ERRATA
Last Closed||2020-11-17 00:35:29



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


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

[Bug 1870743] EPEL8 Branch Request: perl-Data-Stream-Bulk

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Data-Stream-Bulk-0.11-
   ||23.el8
 Resolution|--- |ERRATA
Last Closed||2020-11-17 00:35:26



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


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

[Bug 1890937] Add perl-TestML to EPEL8

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-11-17 00:35:11



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


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

[Bug 1890908] Add perl-Inline to EPEL8

https://bugzilla.redhat.com/show_bug.cgi?id=1890908
Bug 1890908 depends on bug 1890937, which changed state.

Bug 1890937 Summary: Add perl-TestML to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1890937

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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

Unable to disable SysRq

2020-11-16 Thread Robert Marcano via devel

I am using a ThinkPad with one of these keyboards where the PrtScr key 
is between the right Alt and Ctrl, an awful position.


Two times in a week I have killed all processes trying to use Alt+i. Ts 
is to easy to press the Alt and the PrtScr at the same, starting that 
way the SysRq i command.


So before staring to write a kernel patch to add an option where the 
SysRq is only triggered by the Left Alt key. I decided to initially 
disable sysrq entirely.


My Fedora 33 kernel.sysrq value is 80, the default at 
/usr/lib/sysctl.d/50-default.conf say that it should be 16.


Created /etc/sysctl.d/99-local.conf with kernel.sysrq=0, but after boot 
the value is 64, only after a single user mode boot the value stays at 0.


Some other thing is enabling the 64 bit, Asked on IRC and another user 
has 80 on Fedora Workstation and 16 on Server.


I tried disabling all non default services on my installation but to no 
effect, the 64 bit is always enabled. Fedora 33 Live CD shows 16 as the 
default is configured.


How can I log what process is changing values on the sysctl variables? 
or anyone has aon idea of what is happening here?

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

Re: help wanted with modern Python packaging macros (%generate_buildrequires, %tox)

2020-11-16 Thread Felix Schwarz


Hi Miro,

just wanted to say thank you. It took me much longer than expected to actually 
try your suggestions but they were spot-on. :-)


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

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-16 Thread Adam Williamson

On Mon, 2020-11-16 at 22:07 +, Zbigniew Jędrzejewski-Szmek wrote:
> 
> I have no beef with using a spec file in the upstream repo for CI. I
> would do things differently myself, but that doesn't really matter.
> I'm only trying to push back against complaints about changes pushed to
> dist-git. The ability to have a canonical source for the spec file is
> crucial. And it's also crucial that this file is read-write, so that
> automated changes can be done across the distro.

Yeah, this is a better description of my position too. When I said I
wished projects wouldn't consider upstream spec files canonical, I
meant approximately this - the case I really dislike is when you touch
a spec file downstream and then get a complaint that you shouldn't have
done that, you should have sent a PR to some upstream repo instead.
Bonus annoyance points when the distro ("downstream") spec does not
reference the "upstream" spec at all so you could not possibly have
known it existed at all.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: NEEDINFO nag 2 days after bug creation?


On 11/16/20 11:31 PM, Richard Shaw wrote:
The logic behind the NEEDINFO stuff may need to be updated... The subject says 
it all and it's quite annoying.


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



The script runs every 3 weeks, on a Sunday. Sometimes, this happens to be right 
after the bug was opened. Sorry about that.


Sure, we *should* adapt that script to check the creation date of the bug. The 
script is here if you are interested to take a look:


https://pagure.io/releng/blob/master/f/scripts/ftbfs_weekly_reminder.py

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

NEEDINFO nag 2 days after bug creation?

2020-11-16 Thread Richard Shaw

The logic behind the NEEDINFO stuff may need to be updated... The subject
says it all and it's quite annoying.

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

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

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

On Mon, Nov 16, 2020 at 03:31:08PM -0500, Rob Crittenden wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Nov 16, 2020 at 09:01:15AM -0800, Adam Williamson wrote:
> >> On Mon, 2020-11-16 at 09:22 +, Zbigniew Jędrzejewski-Szmek wrote:
> >>>
> >>> (More generally: what would the point of keeping an "upstream" spec
> >>> file be?
> >>
> >> One common reason is to integrate maintenance and testing with code
> >> maintenance and testing, particularly to include package builds in CI
> >> runs.
> > 
> > That argument does sound somewhat reasonable, but I don't think it
> > actually holds much water.
> > 
> > Essentially, packages which do CI are packages which use modern build
> > systems. And with the modern build systems the spec file doesn't need to
> > be tweaked after each version bump. If a "modern" package needs the spec
> > file to be constantly adjusted just to build than something is very wrong.
> > 
> > I expect that the great majority of projects that do CI are just fine
> > with using the "downstream" spec file, which can be easily pulled in
> > from dist-git for the build. Doing this also has the obvious advantage
> > that you can do CI on more than one downstream platform, using different
> > spec files or debian control files or whatever arch has, as appropriate,
> > without polluting the upstream repo with a dozen of downstream-specific
> > build instructions.
> > 
> > Bt, even if it turns out that it's easier to keep the spec file in
> > upstream, the upstream can have copy of the spec file and that spec
> > file can diverge from the Fedora version. All that needs to happen is
> > that the changes are periodically synchronized (e.g. right before the
> > version bump in Fedora).
> 
> What you're missing with your "modern" build system argument is that the
> spec doesn't have to "constantly" be updated, but it is often ahead of
> downstream due to new files and dependencies.

For rust, python, go, ... we're moving towards a system where build
deps are expressed in package metadata. We're not there fully, but that's
clearly the direction with %generate_buildrequires.

For %files, most of the time we don't list most individual files either.
Many packages list maybe a binary or two and the top-level package data
directory. %license and %docs with relative paths takes care of the rest.

> I can't speak for all maintainers but I do exactly what you propose:
> re-sync before each downstream package release. Differences are
> purposely kept to a minimum for this reason, so that diffs are easy to
> understand to limit mistakes.
> 
> My project uses an upstream spec file for CI exactly as Adam describes.

OK, but than all's fine, no? You sync the changes, and the downstream
spec file is still canonical, as far as other Fedora maintainers are
concerned.

I have no beef with using a spec file in the upstream repo for CI. I
would do things differently myself, but that doesn't really matter.
I'm only trying to push back against complaints about changes pushed to
dist-git. The ability to have a canonical source for the spec file is
crucial. And it's also crucial that this file is read-write, so that
automated changes can be done across the distro.

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

[Bug 1283764] Use of uninitialized value in numeric eq (==) at /usr/share/perl5/vendor_perl/File/Tail.pm line 391

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



--- Comment #34 from Harald Reindl  ---
i wouldn't swear at the moment but it pretty sure looks like
perl-File-Tail-1.3-19.fc32.noarch is fixing the issue


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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

2020-11-16 Thread Simo Sorce

On Thu, 2020-11-05 at 07:58 -0500, Nico Kadel-Garcia wrote:
> On Thu, Nov 5, 2020 at 6:39 AM Petr Menšík  wrote:
> > No, no, NO again.
> > 
> > nscd has no important active bugs in Fedora. I am not sure what bugs are
> > mentioned, but just a few active bugs are on glibc component in Fedora.
> > Therefore it seems just fine no commits are good.
> > 
> > Just unlike systemd-resolved, which actively breaks some use cases. It
> > changes resolution order of search directive in resolv.conf, breaks
> > DNSSEC, breaks one label names resolution. It is famous among DNS
> > community [1].
> 
> sssd also breaks other LDAP setups, It's extremely broken with larger
> LDAP setups because it insists on caching *ALL* of the LDAP, barring
> being able to filter to only a smaller set of the LDAP. 

Sorry but this is simply not true, you can apply filters to reduce the
set to what you want.

> But because so
> many LDAP setups scatter group and user information in so many
> distinct parts of the LDAP layout, this never works and it *ALWAYS*
> times out in large, remot4e LDAP setups. It works for a few seconds at
> start time, then crashes and takes out *all* sssd based services.
> 
> The sophisticated setups available by hand-editing sssd are also
> *inevitably* overwritten by any use of the 'authconfig' command, which
> is used by various RPM '%post' operations. sssd's configuration
> options are so poor that they may as well be malicious. It is most
> effective in small and unsophisticated network environments. It
> suffers from the "systemd" style, sprawling universal management tool
> design principles and makes many straightforward operations very
> difficult if not impossible.

open bugs please.

> nscd is a lightweight and *far* more stable tool, and should be used
> in preference to sssd wherever possible. An indepent LDAP and Kerberos
> toolkit is *far* more stable than sssd.

It is also a very crude tool that fails in different scenarios.

If NSCD was a good caching tool I would not have had the need to invent
SSSD in the first place.

nscd has extremely bad failure modes that makes it completely unusable
for example for a laptop, or a server that can be disconnected from the
mothership for more than a network blip. SSSD can handle long
disconnection times instead as it has an offline mode concept.

Nothing is perfect, but NSCD is far from good as well.

> > Instead, I request again, split systemd-resolved into subpackage. I want
> > it removed on my system and so do more people. Also, when I disable it,
> > I have to fix /etc/resolv.conf by hand. I would think NetworkManager
> > restart would refresh classic /etc/resolv.conf, like in F32.
> 
> That's a separate issue. Maybe start a separate thread about that?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

2020-11-16 Thread Petr Menšík



On 11/15/20 4:31 PM, Lennart Poettering wrote:
> On So, 15.11.20 10:18, Marius Schwarz (fedora...@cloud-foo.de) wrote:
> 
>> Am 11.11.20 um 16:58 schrieb Lennart Poettering:
>>> So if you configure 4 DNS servers then each will still get roughly
>>> 1/4th of your requests? That's still quite a lot of info.
>> the more you use, and i did, the better it protects against tracking by the
>> dns cache owners.
Use stubby. 1/4 is not enough, more resolvers are necessary. Or just
find a trusted ISP and hide in his resolver crowd.
>>
>> How about putting this as a feature request in resolved?
> 
> Please file an RFE issue on github:
> 
> https://github.com/systemd/systemd/issues/new?template=Feature_request.md
> 
> Implementing this does not come without drawbacks though: right now
> resolved tries hard to use the same server if at all possible, since
> we want to use newer DNS features if possible, but many DNS servers
> (wifi routers, yuck) tend to support them quite badly. This means
> resolved has an elaborate scheme to learn about the feature set of the
> DNS servers it contacts. And that can be slow, in particular on
> servers where we step-by-step have to downgrade to the most minimal of
> DNS protocols. This learning phase is run only when first contacting
> some server (and after some grace period). 

Understood, learning about server features, especially weird ones that
use request drop instead of request refusal, can take some time. It
definitely should be cached for some time.

If we'd switch servers all
> the time, for every single lookup, then we'd start from zero every
> time, not knowing what the server supports, and thus having to learn
> about it over and over again. This would hence make all,
> *every*single* transaction pretty slow. And that sucks.

This is ridiculous. It might be limitation of current systemd-resolved
implementation, but it is not necessary. All DNS servers track info
about used remotes and their detected features. Even dnsmasq, which is
not full recursive server, just like systemd-resolved. It can learn
about each configured server and keep information about it cached for
some time. Just like TTL of cached records. It can also flush such cache
on interface configuration change, network errors from the server etc.

But it does not have to learn everything about a server, because it
switched the active one. If it has to, try to find way to store server
instance features per server IP, not per link.
> 
> It might be something to add as opt-in, and come with the warning that
> you better list DNS servers that aren't crap if you want to use that,
> so that we never have to downgrade protocol level, and thus the
> learning phase is short.

Sure enough, many router DNS implementations are bad or ugly. If it can
choose from full featured validated ISP resolver and crappy router
implementation, prefer the one with better features. Most likely it is
much better maintained as well.

However, some people rely on the order of used servers in resolv.conf.
First server might know some local names, which secondary backup does
not know about. Such situation is impossible to detect automatically,
but is not too uncommon. I miss some way to force first server always
first if possible. Something like --strict-order of dnsmasq.
> 
> (There have been suggestions to probe ahead-of-time, i.e. already
> before we have to dispatch the first lookup request to it, i.e. at the
> time the DNS server address is configured. However that is a privacy
> issue, too, since it means systems would suddenly start contacting DNS
> servers, even without anyone needing it.)
> 
>> It should of course use encrypted protocols first.
It is questionable, how much are encrypted protocols needed. Of course,
ISP can monitor all your traffic. They can usually monitor all your
queries. But if you seek protection for it, why don't you change your
ISP? Thanks to GDPR, they cannot just sell information about your
actions without your consent. And cannot force you to give the consent
too. If you connect to ISP's server, they can see your queries anyway.
Even encrypted. If you don't, they can see TLS info, which usually leaks
plaintext hostnames too. In the last resort, then can see targetted IPs
and can deduce from them a lot. In short, if you dont trust them, use
full VPN or change them altogether. Most of us living in a free world
can do that.

> It supports DoT since a longer time. Is currently opt-in on Fedora
> though, but we should change that.
> 
> DoT becomes efficient when we can reuse the established TCP/TLS connection
> for multiple lookups. But if we'd switch servers all the time, then of
> course there's no reuse of TCP/TLS connections possible.

I don't see a reason for it here as well. It should be perfectly
possible to have 3 connections to one server and 2 to another one. And
randomize queries to each connection. Reuse of TLS connection is
definitely wanted feature. Again, it might be limitation of current

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-16 Thread Rob Crittenden

Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Nov 16, 2020 at 09:01:15AM -0800, Adam Williamson wrote:
>> On Mon, 2020-11-16 at 09:22 +, Zbigniew Jędrzejewski-Szmek wrote:
>>>
>>> (More generally: what would the point of keeping an "upstream" spec
>>> file be?
>>
>> One common reason is to integrate maintenance and testing with code
>> maintenance and testing, particularly to include package builds in CI
>> runs.
> 
> That argument does sound somewhat reasonable, but I don't think it
> actually holds much water.
> 
> Essentially, packages which do CI are packages which use modern build
> systems. And with the modern build systems the spec file doesn't need to
> be tweaked after each version bump. If a "modern" package needs the spec
> file to be constantly adjusted just to build than something is very wrong.
> 
> I expect that the great majority of projects that do CI are just fine
> with using the "downstream" spec file, which can be easily pulled in
> from dist-git for the build. Doing this also has the obvious advantage
> that you can do CI on more than one downstream platform, using different
> spec files or debian control files or whatever arch has, as appropriate,
> without polluting the upstream repo with a dozen of downstream-specific
> build instructions.
> 
> Bt, even if it turns out that it's easier to keep the spec file in
> upstream, the upstream can have copy of the spec file and that spec
> file can diverge from the Fedora version. All that needs to happen is
> that the changes are periodically synchronized (e.g. right before the
> version bump in Fedora).

What you're missing with your "modern" build system argument is that the
spec doesn't have to "constantly" be updated, but it is often ahead of
downstream due to new files and dependencies.

I can't speak for all maintainers but I do exactly what you propose:
re-sync before each downstream package release. Differences are
purposely kept to a minimum for this reason, so that diffs are easy to
understand to limit mistakes.

My project uses an upstream spec file for CI exactly as Adam describes.

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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

On Mon, Nov 16, 2020 at 07:45:54AM -0500, Stephen John Smoogen wrote:
> On Sun, 15 Nov 2020 at 19:26, Chris Adams  wrote:
> 
> > Once upon a time, Stephen John Smoogen  said:
> > > Because a lot of networks use routing tricks to send traffic to
> > particular
> > > DNS server IP addresses. They may round robin, traffic route, or other
> > > methods to send you to different DNS servers with the same ip address.
> > Even
> > > if they are all the same 'model' device, they have different features
> > > turned on or are at different revisions.. so whatever you have cached is
> > > wrong.
> >
> > I'm pretty sure that's considered "their problem"... anycast servers are
> > expected to behave the same (or similar enough) in terms of features
> > supported.  Real DNS recursive servers like Unbound and BIND keep info
> > about particular servers by IP.
> >
> > However, using info that's being tracked as a reason to not to use
> > multiple servers is a rather weak argument... keeping track of info for
> > additional servers should not be difficult.

Currently resolved switches servers when it doesn't "like" the current
server (timeout, or not working as expected, etc). I think it'd be
fairly easy to implement a mode where the switch also happens on the basis
of time or the number of packets handled. In that mode, it should remember
what capabilities the given server had and just seamlessly restart later on.

OTOH, with two or three servers, the "privacy gains" are so tiny. It's
completely routine to resolve the same names over and over, so each server
has a large chance of capturing enough queries of interest. And also
often even one query is enough to determine a lot about what the user
is doing.

Overall, I think that the caching that is currently happening with resolved
does more for privacy, just by reducing the number of requests, than the
server rotation without cache.

So... I expect that this will be implemented, if somebody provides a patch
or if enough people express interest. I expect upstream to treat it as low
priority though.

(FWIW, a patch to do randomization of results delivered to
applications, even if the same cached upstream answer is being reused,
has been recently merged. This promotes random selection of a specific
address on the application side when a name resolves to more than
one. The justification was that it's simple to implement, and even if
the effect is weak, it *may* be useful in some scenarios.)

> Good point. However at what point to improving these features becomes where
> systemd "bloat. Systemd came up with an "ok" low level solution and then
> people keep nitpicking that it could do a better job and track more
> things.. and eventually you have systemd rewritten in eLISP and a native
> emacs mode. [Change to more appropriate languages for the 21st century..
> rewritten in javascript and a native Node-VSCode mode.]

So far we have resisted the urge do to plugins and extensions. Let's
say that elips or js support is unlikely ;]

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

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

On Mon, Nov 16, 2020 at 09:01:15AM -0800, Adam Williamson wrote:
> On Mon, 2020-11-16 at 09:22 +, Zbigniew Jędrzejewski-Szmek wrote:
> > 
> > (More generally: what would the point of keeping an "upstream" spec
> > file be?
> 
> One common reason is to integrate maintenance and testing with code
> maintenance and testing, particularly to include package builds in CI
> runs.

That argument does sound somewhat reasonable, but I don't think it
actually holds much water.

Essentially, packages which do CI are packages which use modern build
systems. And with the modern build systems the spec file doesn't need to
be tweaked after each version bump. If a "modern" package needs the spec
file to be constantly adjusted just to build than something is very wrong.

I expect that the great majority of projects that do CI are just fine
with using the "downstream" spec file, which can be easily pulled in
from dist-git for the build. Doing this also has the obvious advantage
that you can do CI on more than one downstream platform, using different
spec files or debian control files or whatever arch has, as appropriate,
without polluting the upstream repo with a dozen of downstream-specific
build instructions.

Bt, even if it turns out that it's easier to keep the spec file in
upstream, the upstream can have copy of the spec file and that spec
file can diverge from the Fedora version. All that needs to happen is
that the changes are periodically synchronized (e.g. right before the
version bump in Fedora).

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

Re: Fedora 32: systemd-homed started, but not enabled or needed

2020-11-16 Thread Vitaly Zaitsev via devel


On 16.11.2020 20:56, Marius Schwarz wrote:

Any ideas how to disable it permanently?


sudo systemctl disable systemd-homed.service
sudo systemctl mask systemd-homed.service


 Is masking the service file enough?


Yes. Masked service will never be enabled again.

--
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: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

2020-11-16 Thread Marius Schwarz


Am 16.11.20 um 00:36 schrieb Samuel Sieb:
DoT becomes efficient when we can reuse the established TCP/TLS 
connection

for multiple lookups. But if we'd switch servers all the time, then of
course there's no reuse of TCP/TLS connections possible.


Same thing here.  Would it be a problem to keep a connection open for 
each server?


I'm pretty sure, DNS Cache owners won't keep your connection open 
forever due to available sockets on a system.


So randomization may have it's limits, if used with DoT or DoH.  No 
limits for UDP transports here.


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

Fedora 32: systemd-homed started, but not enabled or needed

2020-11-16 Thread Marius Schwarz


Hi,

after upgrading from F31 to F32, systemd-homed was running, but 
according to systemctl it never got enabled and is referenced by static 
link of some kind:


...
    ├─systemd-homed
    ├─systemd-journal
    ├─systemd-logind
    ├─systemd-udevd
    ├─systemd-userdbd───3*[systemd-userwor]
...
[root ~]# systemctl stop systemd-homed
[root ~]# systemctl status  systemd-homed
● systemd-homed.service - Home Area Manager
 Loaded: loaded (/usr/lib/systemd/system/systemd-homed.service; 
*static*; vendor preset*: disabled*)


As this is a fedora  server, homed is not needed in any form. never. Any 
ideas how to disable it permanently?


Is masking the service file enough?

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

Java reviews (with swaps)

2020-11-16 Thread Jerry James

Hi all,

I would like to ask for some input from those of you with Java
packaging experience.  The jsonp package has been orphaned, but the
antlr4-project package (which I maintain) still needs it.  Since jsonp
has transitioned to the eclipse-ee4j project, I thought it best to let
the current jsonp package die, and replace it with a jakarta-jsonp
package.

The parent POM for jakarta-jsonp, org.eclipse.ee4j:project:pom:, has
not been packaged for Fedora.  Other packages with that parent have
simply added %pom_remove_parent to their spec files.  With
jakarta-jsonp, though, I'm running into some difficulties doing so.
The parent POM has default version numbers for various plugins.  Those
version numbers are not duplicated in the jakarta-jsonp POM.  This
leads to maven telling me that the missing version numbers invoke
deprecated functionality and that the project will stop building with
some future version of maven.  I could:

(1) add %pom_remove_parent and ignore maven until the project actually breaks;
(2) add %pom_remove_parent and then do some XPath gymnastics to add
the missing version numbers into the jakarta-jsonp POM; or
(3) package the parent POM and stop worrying.

I've chosen to do (3).  Tell me if you think this is wrong.

As for jakarta-jsonp itself, the latest version is 2.0.0, but it fails
to build because it needs jakarta-ws-rs 3.x and jakarta-annotations
2.x.  We have versions 2.1.6 and 1.3.5, respectively, in Rawhide right
now.  Therefore, I have gone with version 1.1.6 of jakarta-jsonp for
now.

Here's the next bit of input I need: why does "%pom_remove_plugin -r
org.apache.maven.plugins:maven-javadoc-plugin" only remove the plugin
from the top-level POM, in spite of the -r flag?  I have to manually
remove it from the subdirectory POMs.

Here are the actual review requests.  I'm happy to swap reviews.

https://bugzilla.redhat.com/show_bug.cgi?id=1898311 (ee4j-project)
https://bugzilla.redhat.com/show_bug.cgi?id=1898312 (jakarta-jsonp)

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

[Bug 1803711] perl-Tk-804.034-9.fc33 FTBFS: t/entry.t test fails

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



--- Comment #15 from Mauro Carvalho Chehab  ---
(In reply to Petr Pisar from comment #14)
> I doubt google-noto-sans-fonts is the cause. This package predates Noto
> font. Also you can see that the font is not listed in the installed package
> set
>  logs/x86_64/root.log> for the last successful build before the XFT was
> disabled. I'd rather bet on FontConfig cache not being updated or the
> metrics of the exhibited font being removed or moved to a different package.
> Also note that -adobe-courier-medium-r-normal--12-120-75-75-m-*-iso8859-1 is
> the old non-FT font specification. So if indeed that font was used, then no
> XFT was involved.

I tested installing xorg-x11-fonts-ISO8859-1-75dpi, which should be carrying
adobe-courier font, but installing it didn't make any change.

I agree that this could be due to FontConfig cache, but it could also be due to
some font replacement setup that would happen when this font is installed.

In either case, before coming up with this solution, I tried to install other
packages that would make more sense, but everything failed until this one got
installed. After installing it, mock was able to successfully the package on
both Fedora 33 and rawhide.


-- 
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 1803711] perl-Tk-804.034-9.fc33 FTBFS: t/entry.t test fails

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



--- Comment #14 from Petr Pisar  ---
I doubt google-noto-sans-fonts is the cause. This package predates Noto font.
Also you can see that the font is not listed in the installed package set

for the last successful build before the XFT was disabled. I'd rather bet on
FontConfig cache not being updated or the metrics of the exhibited font being
removed or moved to a different package. Also note that
-adobe-courier-medium-r-normal--12-120-75-75-m-*-iso8859-1 is the old non-FT
font specification. So if indeed that font was used, then no XFT was involved.


-- 
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: finding recursive builddeps

2020-11-16 Thread Pavel Raiskup

On Sunday, November 15, 2020 4:10:03 PM CET Jason Edgecombe wrote:
> Hi everyone,
> 
> I want to rebuild some of the fedora 33 packages for EL8 (vagrant, for
> example), but I'm having trouble getting all of the build dependencies
> right. I ran dnf to download the SRPMS with the --resolve option, but I'm
> still missing dependencies when I submit the builds to copr.
> 
> My current workflow is to download an RPM from Fedora 33, then submit it to
> copr to build on the EPEL8 image in my personal COPR projects, waiting for
> any library errors, then download those and build, repeat as needed.
> 
> That workflow is tedious and I feel like there must be a better way, but I
> don't know what that is. How can I recursively find all of the builddeps
> for packages?

If you already have it built in copr, there's package-build-order script
in copr-cli that could help you to reconstruct the order from the
repository.  It was created exactly for this purpose, but has not yet been
widely tested.

Pavel

> Ideally, I would like some type of (semi-)automated way to  track packages
> on Fedora and automatically build them on EL8, but I'm at a loss for how to
> do so.
> 
> Thanks,
> Jason
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1803711] perl-Tk-804.034-9.fc33 FTBFS: t/entry.t test fails

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



--- Comment #13 from Mauro Carvalho Chehab  ---
Created attachment 1729853
  --> https://bugzilla.redhat.com/attachment.cgi?id=1729853=edit
Re-enable TrueType support by adding a missing font


-- 
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 1803711] perl-Tk-804.034-9.fc33 FTBFS: t/entry.t test fails

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

Mauro Carvalho Chehab  changed:

   What|Removed |Added

 Status|CLOSED  |NEW
 Resolution|ERRATA  |---
   Keywords||Reopened



--- Comment #12 from Mauro Carvalho Chehab  ---
Found it!

events.t requires google-noto-sans-fonts in order to pass. I'll enclose a patch
on this BZ.


-- 
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 1818509] perl-Tk-804.035 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1818509
Bug 1818509 depends on bug 1803711, which changed state.

Bug 1803711 Summary: perl-Tk-804.034-9.fc33 FTBFS: t/entry.t test fails
https://bugzilla.redhat.com/show_bug.cgi?id=1803711

   What|Removed |Added

 Status|CLOSED  |NEW
 Resolution|ERRATA  |---




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

[Test-Announce] Proposal to CANCEL: all Fedora QA meetings in December

2020-11-16 Thread Adam Williamson

Hi folks! I'm going to be off work from December 7 to January 4 (got a
lot of unused vacation time to use up). December's generally slow
because of RH folks taking time off, and so I'm proposing in advance we
just skip all the QA meetings in the month - Dec 7, 14, 21 and 28. I'll
plan to schedule meetings on Nov 30 and Jan 4.

Of course, if anything urgent comes up we can re-schedule a meeting,
run by me or someone else. But otherwise I'm figuring we'll be OK
without them. Please yell if you think we're going to need one. Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-16 Thread Adam Williamson

On Mon, 2020-11-16 at 09:22 +, Zbigniew Jędrzejewski-Szmek wrote:
> 
> (More generally: what would the point of keeping an "upstream" spec
> file be?

One common reason is to integrate maintenance and testing with code
maintenance and testing, particularly to include package builds in CI
runs.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: review-stats bot spamming "failed to clear NEEDINFO" messages

2020-11-16 Thread Mattia Verga via devel

Il 16/11/20 09:29, Artur Frenszek-Iwicki ha scritto:
>> a) failing to check if the NEEDINFO flag is set for the *submitter*,
>>instead of a reviewer
>> b) failing to clear the NEEDINFO flag for the submitter
> Oops, I barely posted the message and I already spotted that I'm wrong.
>
> The NEEDINFO flag, in this case, is set to require action
> from "nob...@fedoraproject.org". The ticket never had an assignee specified;
> which basically makes "nob...@fedoraproject.org" the assignee.
> Yet the NEEDINFO flag is still not cleared.

Yeah, it's a bug, thanks for pointing that out. I'll fix it, for the 
moment I'll remove that odd needinfo flag.

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

[Bug 1803711] perl-Tk-804.034-9.fc33 FTBFS: t/entry.t test fails

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



--- Comment #11 from Mauro Carvalho Chehab  ---
Ok, with this small patch:

diff --git a/t/entry.t b/t/entry.t
index c9e99b87ab81..7192776685ad 100755
--- a/t/entry.t
+++ b/t/entry.t
@@ -677,6 +677,7 @@ eval { $e->destroy };
 $e = $mw->Entry(-font => $fixed, -bd => 2, -relief => "raised")->pack;
 $e->insert(end => "0123");
 $e->update;
+diag sprintf "Font: $fixed, Geometry data: %s", $e->geometry;
 is($e->index('@10'), 0, "index with raised relief");
 with_fixed_font { is($e->index('@11'), 0) };
 is($e->index('@12'), 1);

It can be seen the differences between a build on a machine with X11 properly
installed:

  $  perl -It -MTkTest -e 'checked_test_harness('\''./xt'\'', 0,
'\''blib/lib'\'', '\''blib/arch'\'')' t/entry.t
  t/entry.t .. 193/351 # Font:
-adobe-courier-medium-r-normal--12-120-75-75-m-*-iso8859-1, Geometry data:
150x23+0+0
  t/entry.t .. ok   
  All tests successful.
  Files=1, Tests=351,  2 wallclock secs ( 0.04 usr  0.01 sys +  1.95 cusr  0.03
csys =  2.03 CPU)
  Result: PASS

And a build with mock:

  + xvfb-run -a perl -It -MTkTest -e 'checked_test_harness('\''./xt'\'', 0,
'\''blib/lib'\'', '\''blib/arch'\'')' t/entry.t
  # 
  # 
  # Font: -adobe-courier-medium-r-normal--12-120-75-75-m-*-iso8859-1, Geometry
data: 170x25+0+0
  # 
  # 

  #   Failed test at t/entry.t line 684.
  #  got: '0'
  # expected: '1'

  #   Failed test at t/entry.t line 693.
  #  got: '0'
  # expected: '1'

  #   Failed test at t/entry.t line 746.
  #  got: '5'
  # expected: '6'

  #   Failed test at t/entry.t line 1219.
  #  got: '4'
  # expected: '5'
  # Looks like you failed 4 tests of 351.
  t/entry.t .. 
  Dubious, test returned 4 (wstat 1024, 0x400)
  Failed 4/351 subtests 
(less 39 skipped subtests: 308 okay)

I suspect that some additional packages are required for the adobe-currier
font, libXft and fontconfig to be properly installed/initialized inside mock
chroot.


-- 
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: Two questions on updates

2020-11-16 Thread Fabio Valentini

On Mon, Nov 16, 2020 at 5:14 PM Jerry James  wrote:
>
> On Mon, Nov 16, 2020 at 9:09 AM Fabio Valentini  wrote:
> > Normal updates need at *least* +2 karma so they can be pushed to
> > stable *manually*.
> > The default of +3 karma only makes bodhi push updates to stable
> > *earlier* automatically, instead of after 7 days.
>
> Gotcha.  Somehow I've missed that all this time.

It has confused me as well. For context:
https://github.com/fedora-infra/bodhi/issues/3842

I think the text in the UI is just misleading.
I guess it should say something like "This update now fulfils the
necessary requirements to be pushed to stable manually early"

> > No. Just push the "Actions" Button and then click "Push to testing" in
> > the dropdown.
> > They were created from side tags I assume (?), where bodhi doesn't
> > push updates to "testing" automatically (this is a bug, I assume).
>
> Yes, they were created from side tags.  I did expect them to be pushed
> to testing automatically.  I have now adjusted my expectations, but
> that's pretty nonintuitive.  Why would I want to create an update that
> goes nowhere?

Looks like this was fixed, but it's not deployed yet:
https://github.com/fedora-infra/bodhi/issues/4087

> Thanks, Fabio.  You're a life saver.

Ah, I'm just sharing my wisdom. It has no use when I keep it to myself :)

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

[389-devel] Please review: PR 4440 - Using ldifgen with --start-idx option fails with unsupported operand

2020-11-16 Thread Pierre Rogier

https://github.com/389ds/389-ds-base/pull/

-- 
--

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

Re: Two questions on updates

2020-11-16 Thread Jerry James

On Mon, Nov 16, 2020 at 9:09 AM Fabio Valentini  wrote:
> Normal updates need at *least* +2 karma so they can be pushed to
> stable *manually*.
> The default of +3 karma only makes bodhi push updates to stable
> *earlier* automatically, instead of after 7 days.

Gotcha.  Somehow I've missed that all this time.

> No. Just push the "Actions" Button and then click "Push to testing" in
> the dropdown.
> They were created from side tags I assume (?), where bodhi doesn't
> push updates to "testing" automatically (this is a bug, I assume).

Yes, they were created from side tags.  I did expect them to be pushed
to testing automatically.  I have now adjusted my expectations, but
that's pretty nonintuitive.  Why would I want to create an update that
goes nowhere?

Thanks, Fabio.  You're a life saver.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Two questions on updates

2020-11-16 Thread Fabio Valentini

On Mon, Nov 16, 2020, 16:54 Jerry James  wrote:
>
> I got email today telling me that this update can be pushed stable now:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-6960d09c20
>
> Question 1: why is that?  The update needs to be in testing for 7 days
> or receive karma of 3 or more.  It has been in testing for 4 days and
> has karma of 2.  Why is it eligible to be pushed stable?

Normal updates need at *least* +2 karma so they can be pushed to
stable *manually*.
The default of +3 karma only makes bodhi push updates to stable
*earlier* automatically, instead of after 7 days.

>
> I submitted these two updates on Thursday and Friday, respectively:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-f16abf2fb5
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-6994abfc21
>
> They are still in the pending state, while an update I submitted on
> Saturday has since been pushed to testing.  Question 2: Is something
> blocking these two updates?

No. Just push the "Actions" Button and then click "Push to testing" in
the dropdown.
They were created from side tags I assume (?), where bodhi doesn't
push updates to "testing" automatically (this is a bug, I assume).

Fabio

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

Two questions on updates

2020-11-16 Thread Jerry James

I got email today telling me that this update can be pushed stable now:

https://bodhi.fedoraproject.org/updates/FEDORA-2020-6960d09c20

Question 1: why is that?  The update needs to be in testing for 7 days
or receive karma of 3 or more.  It has been in testing for 4 days and
has karma of 2.  Why is it eligible to be pushed stable?

I submitted these two updates on Thursday and Friday, respectively:

https://bodhi.fedoraproject.org/updates/FEDORA-2020-f16abf2fb5
https://bodhi.fedoraproject.org/updates/FEDORA-2020-6994abfc21

They are still in the pending state, while an update I submitted on
Saturday has since been pushed to testing.  Question 2: Is something
blocking these two updates?

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

[Bug 1803711] perl-Tk-804.034-9.fc33 FTBFS: t/entry.t test fails

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



--- Comment #10 from Mauro Carvalho Chehab  ---
(In reply to Mauro Carvalho Chehab from comment #9)
> (In reply to Jitka Plesnikova from comment #3)
> > The problem is probably related to the fonts update. 
> 
> I don't think so. Building it by hand, with XFT=1 and either doing "make
> test" or running the unit test alone:
> 
> 
>$ perl -It -MTkTest -e "checked_test_harness('./xt', 0, 'blib/lib',
> 'blib/arch')"  t/entry.t 
>t/entry.t .. ok   
>All tests successful.
>Files=1, Tests=351,  2 wallclock secs ( 0.04 usr  0.01 sys +  2.10 cusr 
> 0.03 csys =  2.18 CPU)
>Result: PASS
> 
> Works.
> 
> The only difference I see is that, when building with mock, the output is
> not displayed. I'm starting to suspect that the unit test is failing due to
> some limitation at mock to emulate a X11/Wayland console, e. g. probably
> some incompatibility with xorg-x11-server-Xvfb.

Funny enough, running:

   xvfb-run -a perl -It -MTkTest -e "checked_test_harness('./xt', 0,
'blib/lib', 'blib/arch')"  t/entry.t

or

   xvfb-run -a make test

works fine too. Perhaps it requires some extra package for the tests to pass on
mock?


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

Fedora-IoT-34-20201116.0 compose check report

No missing expected images.

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

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

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

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

ID: 723405  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/723405
ID: 723417  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/723417
ID: 723421  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/723421
ID: 723423  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/723423
ID: 723425  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/723425
ID: 723426  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/723426
ID: 723429  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/723429

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

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
System load changed from 0.37 to 0.15
Previous test data: https://openqa.fedoraproject.org/tests/722861#downloads
Current test data: https://openqa.fedoraproject.org/tests/723406#downloads

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

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

Missing expected images:

Xfce raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 14/115 (aarch64), 14/177 (x86_64)

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

ID: 723164  Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/723164
ID: 723341  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/723341
ID: 723342  Test: x86_64 universal install_pxeboot
URL: https://openqa.fedoraproject.org/tests/723342
ID: 723344  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/723344

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

ID: 723110  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/723110
ID: 723117  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/723117
ID: 723118  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/723118
ID: 723120  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/723120
ID: 723156  Test: aarch64 Server-dvd-iso base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/723156
ID: 723160  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/723160
ID: 723171  Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/723171
ID: 723180  Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/723180
ID: 723194  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/723194
ID: 723240  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/723240
ID: 723295  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/723295
ID: 723307  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/723307
ID: 723320  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/723320
ID: 723323  Test: aarch64 universal install_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/723323
ID: 723336  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/723336
ID: 723337  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/723337
ID: 723338  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/723338
ID: 723339  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/723339
ID: 723340  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/723340
ID: 723343  Test: x86_64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/723343
ID: 723346  Test: aarch64 universal support_server@uefi
URL: https://openqa.fedoraproject.org/tests/723346
ID: 723348  Test: aarch64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/723348
ID: 723403  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/723403
ID: 723404  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/723404

Soft failed openQA tests: 8/177 (x86_64), 3/115 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 723233  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/723233
ID: 723257  Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/723257
ID: 723258  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/723258
ID: 723278  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/723278
ID: 723303  Test: aarch64 universal upgrade_2_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/723303
ID: 723321  Test: aarch64 universal upgrade_2_server_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/723321

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

ID: 723091  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/723091
ID: 723092  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/723092
ID: 723142  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/723142
ID: 723210  Test: aarch64

[Bug 1803711] perl-Tk-804.034-9.fc33 FTBFS: t/entry.t test fails

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

Mauro Carvalho Chehab  changed:

   What|Removed |Added

 CC||mche...@infradead.org



--- Comment #9 from Mauro Carvalho Chehab  ---
(In reply to Jitka Plesnikova from comment #3)
> The problem is probably related to the fonts update. 

I don't think so. Building it by hand, with XFT=1 and either doing "make test"
or running the unit test alone:


   $ perl -It -MTkTest -e "checked_test_harness('./xt', 0, 'blib/lib',
'blib/arch')"  t/entry.t 
   t/entry.t .. ok   
   All tests successful.
   Files=1, Tests=351,  2 wallclock secs ( 0.04 usr  0.01 sys +  2.10 cusr 
0.03 csys =  2.18 CPU)
   Result: PASS

Works.

The only difference I see is that, when building with mock, the output is not
displayed. I'm starting to suspect that the unit test is failing due to some
limitation at mock to emulate a X11/Wayland console, e. g. probably some
incompatibility with xorg-x11-server-Xvfb.


-- 
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: orphaning Taskotron-related packages


On 11/16/20 2:07 PM, Kamil Paral wrote:
I just know that sometimes the retirement process does not happen automatically 
and the packages linger


When that happens, please let me know. For the past ~2 years, I am the 
retirement process.


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

Fwd: Fedora python-lark-parser maintenance


Hello.

Does anybody know how to reach Thomas Andrejak (totol)?

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


 Forwarded Message 
Subject: Fedora python-lark-parser maintenance
Date: Mon, 2 Nov 2020 14:01:15 +0100
From: Miro Hrončok
Organization: Red Hat
To: Thomas Andrejak

Hello Thomas,

I have a pull request pending for python-lark-parser:

https://src.fedoraproject.org/rpms/python-lark-parser/pull-request/5

I'd be happy to help you co-maintain this package.

Please, let me know.
--
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 1853802] font selection is broken on perl-Tk-804.035-1.fc32.x86_64

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

Mauro Carvalho Chehab  changed:

   What|Removed |Added

Version|32  |33



--- Comment #2 from Mauro Carvalho Chehab  ---
Bug is still present on perl-Tk-804.035-4.fc33.x86_64


-- 
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: orphaning Taskotron-related packages

2020-11-16 Thread Kamil Paral

On Mon, Nov 16, 2020 at 8:27 AM František Zatloukal 
wrote:

> The "correct" way to do this is to use orphaning procedure. This way,
> anybody interested will have enough time to take over the to-be removed
> packages.
>

"When Fedora maintainers do not want or are not able to maintain a package
any longer, they can orphan or retire
 the
package. When they think that the package is still useful for Fedora, they
should orphan it. Then other maintainers that are interested in maintaining
it, can take ownership of this package. In case the package is no longer
useful for Fedora, e.g. because it was renamed, upstream does not exist
anymore, then it should be retired."
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers

As I said, I think it makes sense to go for orphaning in case of
mongoquery, and retiring for taskotron packages. But as you note:

>
> Also, all packages that are orphaned for 6+ weeks get retired. This will
> happen before F34, so there is no harm in doing this through orphans.
>

Yes, it should be the same anyway, if we do it right now. I just know that
sometimes the retirement process does not happen automatically and the
packages linger, and that's why I suggested retiring the upstream-dead
packages right away. I see no benefit in a two-step process, only potential
issues. But I don't care, really.

Anyway, what do you think about the actual proposal, and not the
technicalities?
Tim, Josef, do you have anything to say here?
Thanks.
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-16 Thread Vitaly Zaitsev via devel


On 16.11.2020 13:35, Felix Schwarz wrote:
The only point (though important imho) I want to make is that 
provenpackagers should not "circumvent" the package maintainer by 
default - even though I can imagine it is way faster just to push your 
change.


Most of casual packagers simply ignore all pull requests and don't even 
check their mail. It is much more easier to fix the package manually 
than waiting 2-3 weeks for a response.


--
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: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

2020-11-16 Thread Stephen John Smoogen

On Sun, 15 Nov 2020 at 19:26, Chris Adams  wrote:

> Once upon a time, Stephen John Smoogen  said:
> > Because a lot of networks use routing tricks to send traffic to
> particular
> > DNS server IP addresses. They may round robin, traffic route, or other
> > methods to send you to different DNS servers with the same ip address.
> Even
> > if they are all the same 'model' device, they have different features
> > turned on or are at different revisions.. so whatever you have cached is
> > wrong.
>
> I'm pretty sure that's considered "their problem"... anycast servers are
> expected to behave the same (or similar enough) in terms of features
> supported.  Real DNS recursive servers like Unbound and BIND keep info
> about particular servers by IP.
>
> However, using info that's being tracked as a reason to not to use
> multiple servers is a rather weak argument... keeping track of info for
> additional servers should not be difficult.
>

Good point. However at what point to improving these features becomes where
systemd "bloat. Systemd came up with an "ok" low level solution and then
people keep nitpicking that it could do a better job and track more
things.. and eventually you have systemd rewritten in eLISP and a native
emacs mode. [Change to more appropriate languages for the 21st century..
rewritten in javascript and a native Node-VSCode mode.]



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


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

Re: can't find the format file `latex.fmt' on Rawhide

2020-11-16 Thread Fabio Valentini

On Sun, Nov 15, 2020 at 11:25 PM Christoph Junghans  wrote:
>
> On Fri, Nov 13, 2020 at 8:19 AM Christoph Junghans  wrote:
> >
> > Hi,
> >
> > Using latex in Docker on Rawhide gives an "I can't find the format
> > file `latex.fmt'!" error.
> > I have seen this before but I don't recall how to fix it.
> >
> > Mini reproducer using the following Dockerfile:
> > FROM registry.fedoraproject.org/fedora:rawhide
> > RUN dnf -y update
> > RUN dnf -y install texlive
> > RUN printf 
> > '\\documentclass{article}\n\\begin{document}\ntest\n\\end{document}'
> > > test.tex
> > RUN latex test.tex
> >
> > Any ideas?
> I did some follow up research - summary here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1897839
> In short, same texlive version works fine in a F33 container, so it
> must be something else in Rawhide that triggers this.
>
> >
> > Thanks,
> >
> > Christoph

I found that sometimes, the order in which texlive packages are
installed makes them either work - or not. I suspect some scriptlet or
RPM file trigger is not being executed as needed in some cases. If you
are hitting the same issue, then "dnf reinstall"ing all texlive*
packages should fix the issue (I think).

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: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-16 Thread Felix Schwarz



Am 16.11.20 um 13:16 schrieb Vitaly Zaitsev via devel:
The main upstream for Fedora packages is the Fedora Package Sources. If the 
package need to be fixed, it must be fixed.


I agree with you here. The only point (though important imho) I want to make is 
that provenpackagers should not "circumvent" the package maintainer by default - 
even though I can imagine it is way faster just to push your change.


The main idea is that "everyone plays by the same rules" except for some special 
situations:

- pre-announced mass changes
- urgent fixes and maintainer does not react immediately

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

[Bug 1898112] New: perl-Inline-Python fails to build with Python 3.10: tests fail

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

Bug ID: 1898112
   Summary: perl-Inline-Python fails to build with Python 3.10:
tests fail
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Inline-Python
  Assignee: j.k.nil...@usit.uio.no
  Reporter: mhron...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: j.k.nil...@usit.uio.no, mhron...@redhat.com,
perl-devel@lists.fedoraproject.org,
thrnc...@redhat.com
Blocks: 1890881 (PYTHON3.10)
  Target Milestone: ---
Classification: Fedora



perl-Inline-Python fails to build with Python 3.10.0a2.

+ make test
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- Python.bs
blib/arch/auto/Inline/Python/Python.bs 644
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness"
"-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')"
t/*.t
t/00init.t  ok
Failed to autogenerate
/builddir/build/BUILD/Inline-Python-0.56/blib_test/config-x86_64-linux-thread-multi-5.032000.

 at t/01testpl.t line 6.
BEGIN failed--compilation aborted at t/01testpl.t line 6.
t/01testpl.t .. 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 8/8 subtests 
t/02testpl.t .. 
Failed 9/9 subtests 
t/03parse.t ... 
No subtests run 
t/04func.t  
Failed 3/3 subtests 
Failed to autogenerate
/builddir/build/BUILD/Inline-Python-0.56/blib_test/config-x86_64-linux-thread-multi-5.032000.

 at t/05JAxH.t line 7.
BEGIN failed--compilation aborted at t/05JAxH.t line 7.
t/05JAxH.t  
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 1/1 subtests 
Failed to autogenerate
/builddir/build/BUILD/Inline-Python-0.56/blib_test/config-x86_64-linux-thread-multi-5.032000.

 at t/06dict.t line 8.
BEGIN failed--compilation aborted at t/06dict.t line 8.
# Looks like your test exited with 2 before it could output anything.
t/06dict.t  
Dubious, test returned 2 (wstat 512, 0x200)
Failed 6/6 subtests 
Failed to autogenerate
/builddir/build/BUILD/Inline-Python-0.56/blib_test/config-x86_64-linux-thread-multi-5.032000.

 at t/07nherit.t line 4.
BEGIN failed--compilation aborted at t/07nherit.t line 4.
t/07nherit.t .. 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 5/5 subtests 
t/08ipyobj.t .. 
Failed 9/9 subtests 
t/09bind.t  
Failed 6/6 subtests 
t/10pyeval.t .. 
Failed 6/6 subtests 
Failed to autogenerate
/builddir/build/BUILD/Inline-Python-0.56/blib_test/config-x86_64-linux-thread-multi-5.032000.

 at t/11factor.t line 0.
INIT failed--call queue aborted,  line 1.
t/11factor.t .. 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 133/133 subtests 
Failed to autogenerate
/builddir/build/BUILD/Inline-Python-0.56/blib_test/config-x86_64-linux-thread-multi-5.032000.

 at t/12evnodd.t line 0.
INIT failed--call queue aborted,  line 1.
t/12evnodd.t .. 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 150/150 subtests 
t/13fibbon.t .. 
Failed 277/277 subtests 
t/14study.t ... 
Failed 14/14 subtests 
Failed to autogenerate
/builddir/build/BUILD/Inline-Python-0.56/blib_test/config-x86_64-linux-thread-multi-5.032000.

 at t/15anon.t line 0.
INIT failed--call queue aborted,  line 1.
t/15anon.t  
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 2/2 subtests 
t/16evalpy.t .. 
Failed 11/11 subtests 
Failed to autogenerate
/builddir/build/BUILD/Inline-Python-0.56/blib_test/config-x86_64-linux-thread-multi-5.032000.

 at t/17once.t line 0.
INIT failed--call queue aborted,  line 1.
t/17once.t  
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 1/1 subtests 
Failed to autogenerate
/builddir/build/BUILD/Inline-Python-0.56/blib_test/config-x86_64-linux-thread-multi-5.032000.

 at t/18newclass.t line 4.
BEGIN failed--compilation aborted at t/18newclass.t line 4.
t/18newclass.t  
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 5/5 subtests 
t/19testref.t . 
Failed 57/57 subtests 
Failed to autogenerate
/builddir/build/BUILD/Inline-Python-0.56/blib_test/config-x86_64-linux-thread-multi-5.032000.

 at t/20unicode.t line 11.
BEGIN failed--compilation aborted at t/20unicode.t line 11.
t/20unicode.t . 
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run 
t/21arrayref.t  
Failed 19/19 subtests 
t/22int.t . 
Failed 4/4 subtests 
t/23getattr.t . 
Failed 6/6 subtests 
t/24getitem.t . 
Failed 4/4 subtests 
Failed to autogenerate
/builddir/build/BUILD/Inline-Python-0.56/blib_test/config-x86_64-linux-thread-multi-5.032000.

 at t/25py_sub.t line 5.
BEGIN failed--compilation aborted at t/25py_sub.t line 5.
# Looks like your test

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-16 Thread Vitaly Zaitsev via devel


On 16.11.2020 11:33, Felix Schwarz wrote:
I think the main idea is that we try not to create artificial 
"hierarchies". Especially for a volunteer maintainer who maintains a few 
packages there might be a pretty strong emotional attachment to his 
packages which try to keep up to the highest packaging standards. If 
some provenpackager just goes into "his" package and seems to play by a 
different set of rules this can be pretty demotivating.


The main upstream for Fedora packages is the Fedora Package Sources. If 
the package need to be fixed, it must be fixed.


If the maintainer wants to maintain a separate external copy, they 
should manually backport changes made on the Fedora side.


IMO, proven packagers are doing the right thing.

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

Fedora rawhide compose report: 20201116.n.0 changes

2020-11-16 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20201115.n.0
NEW: Fedora-Rawhide-20201116.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   54
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   831.41 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20201115.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  AusweisApp2-1.20.2-10.fc34
Old package:  AusweisApp2-1.20.2-9.fc34
Summary:  Online identification with German ID card (Personalausweis)
RPMs: AusweisApp2 AusweisApp2-data AusweisApp2-doc
Size: 22.91 MiB
Size change:  9.75 KiB
Changelog:
  * Sun Nov 15 2020 Bj??rn Esser  - 1.20.2-10
  - Add runtime dependency on qt5-qtquickcontrols2


Package:  MUMPS-5.3.5-1.fc34
Old package:  MUMPS-5.3.4-1.fc34
Summary:  A MUltifrontal Massively Parallel sparse direct Solver
RPMs: MUMPS MUMPS-common MUMPS-devel MUMPS-examples MUMPS-mpich 
MUMPS-mpich-devel MUMPS-mpich-examples MUMPS-openmp MUMPS-openmp-devel 
MUMPS-openmp-examples MUMPS-openmpi MUMPS-openmpi-devel MUMPS-openmpi-examples 
MUMPS-srpm-macros
Size: 77.68 MiB
Size change:  -96.29 KiB
Changelog:
  * Sat Nov 14 2020 Antonio Trande  - 5.3.5-1
  - Release 5.3.5


Package:  R-magick-2.5.2-1.fc34
Old package:  R-magick-2.5.1-1.fc34
Summary:  Advanced Graphics and Image-Processing in R
RPMs: R-magick
Size: 23.52 MiB
Size change:  -43.00 KiB
Changelog:
  * Sun Nov 15 2020 Elliott Sales de Andrade  - 
2.5.2-1
  - Update to latest version (#1896455)


Package:  R-rprojroot-2.0.2-1.fc34
Old package:  R-rprojroot-1.3.2-9.fc33
Summary:  Finding Files in Project Subdirectories
RPMs: R-rprojroot
Size: 106.43 KiB
Size change:  16.25 KiB
Changelog:
  * Sun Nov 15 2020 Elliott Sales de Andrade  - 
2.0.2-1
  - Update to latest version (#1897908)
  - Rename check and with_doc conditions to bootstrap


Package:  R-showtext-0.9.1-1.fc34
Old package:  R-showtext-0.9-1.fc34
Summary:  Using Fonts More Easily in R Graphs
RPMs: R-showtext
Size: 1.38 MiB
Size change:  1.53 KiB
Changelog:
  * Sun Nov 15 2020 Elliott Sales de Andrade  - 
0.9.1-1
  - Update to latest version (#1897803)


Package:  antimicrox-3.1.3-1.fc34
Old package:  antimicrox-3.1.2-1.fc34
Summary:  Graphical program used to map keyboard buttons and mouse controls 
to a gamepad
RPMs: antimicrox antimicrox-libantilib antimicrox-libantilib-devel
Size: 7.13 MiB
Size change:  1.05 MiB
Changelog:
  * Sun Nov 15 2020 Gergely Gombos  - 3.1.3-1
  - 3.1.3, remove icons dependency, add % {arm} arch


Package:  awesome-4.3-7.fc34
Old package:  awesome-4.3-4.fc32
Summary:  Highly configurable, framework window manager for X. Fast, light 
and extensible
RPMs: awesome awesome-doc
Size: 5.07 MiB
Size change:  -6.41 KiB
Changelog:
  * Mon Jul 27 2020 Fedora Release Engineering  - 
4.3-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild

  * Sat Aug 01 2020 Fedora Release Engineering  - 
4.3-6
  - Second attempt - Rebuilt for
https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild

  * Sun Nov 15 2020 Thomas Moschny  - 4.3-7
  - Update for 
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds.


Package:  cozy-0.7.5-1.fc34
Old package:  cozy-0.7.3-1.fc34
Summary:  Modern audiobook player
RPMs: cozy
Size: 266.93 KiB
Size change:  -599 B
Changelog:
  * Sun Nov 15 2020 Artur Frenszek-Iwicki  - 0.7.5-1
  - Update to latest release


Package:  dummy-test-package-crested-0-2178
Old package:  dummy-test-package-crested-0-2175
Summary:  Dummy Test Package called Crested
RPMs: dummy-test-package-crested
Size: 140.07 KiB
Size change:  233 B
Changelog:
  * Sun Nov 15 2020 packagerbot  - 0-2176
  - rebuilt

  * Sun Nov 15 2020 packagerbot  - 0-2177
  - rebuilt

  * Sun Nov 15 2020 packagerbot  - 0-2178
  - rebuilt


Package:  dummy-test-package-gloster-0-2063.fc34
Old package:  dummy-test-package-gloster-0-2059.fc34
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 131.79 KiB
Size change:  235 B
Changelog:
  * Sun Nov 15 2020 packagerbot  - 0-2060
  - rebuilt

  * Sun Nov 15 2020 packagerbot  - 0-2061
  - rebuilt

  * Sun Nov 15 2020 packagerbot  - 0-2062
  - rebuilt

  * Mon Nov 16 2020 packagerbot  - 0-2063
  - rebuilt


Package:  dummy-test-package-rubino-0-2178
Old package:  dummy-test-package-rubino-0-2175
Summary:  Dummy Test Package called Rubino
RPMs: dummy-test-package-rubino
Size: 139.95 KiB
Size

Re: transmission-remote-gtk pull requests

2020-11-16 Thread Łukasz Patron

Thanks for the reply. Considering transmission-remote-gtk is about to get new 
release according to 
https://github.com/transmission-remote-gtk/transmission-remote-gtk/pull/109#issuecomment-727668394
 I'll wait a bit, redo my pull requests and open bugzilla report then.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: transmission-remote-gtk pull requests

2020-11-16 Thread Dan Čermák

Hi Łukasz,


Łukasz Patron  writes:

> Hi,
>
> I've been trying to get these two pull requests reviewed / merged 
> https://src.fedoraproject.org/rpms/transmission-remote-gtk/pull-request/1, 
> https://src.fedoraproject.org/rpms/transmission-remote-gtk/pull-request/2 but 
> I can't seem to get anyone to do that. I have tried [at]mention-ing package 
> maintainer on Pagure and also contacting them via email I've found on their 
> personal GitHub profile but I haven't got any answer. Could anyone please 
> take a look at these changes?
>

I'd recommend to open a bug in Bugzilla and if the maintainer does not
respond there, you should initiate the non-responsive maintainer
process[1].


Cheers,

Dan

Footnotes:
[1]  
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/



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

Next Open NeuroFedora Meeting: 1300 UTC on Monday, 16 November (today)

2020-11-16 Thread Ankur Sinha

Hello everyone,

Please join us at the next Open NeuroFedora team meeting today on
Monday 16 November at 1300UTC in #fedora-neuro on IRC (Freenode). The
meeting is a public meeting, and open for everyone to attend.

https://webchat.freenode.net/?channels=#fedora-neuro

The channel is bridged to Telegram, so you can also join us there on the
@NeuroFedora group:
https://t.me/NeuroFedora

You can convert the meeting time to your local time using this command
in a terminal:
$ date --date='TZ="UTC" 1300 today'

or you can use this link:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+Meeting=20201116T13=1440=1

The meeting will be chaired by @bt0dotninja. The agenda for the meeting
is:

- New introductions and roll call.
- Tasks from last week's meeting:
  
https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2020-11-02-13.01.html
- Open Pagure tickets:
  
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
- Open bugs check: https://tinyurl.com/neurofedora-bugs
- Koschei packages check:
  https://koschei.fedoraproject.org/groups/neuro-sig
- CompNeuro lab compose status check for F33/F34:
  https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
- Neuroscience query of the week
- Next meeting day, and chair.
- Open floor.

We hope to see you there!

You can learn more about NeuroFedora here:
https://neuro.fedoraproject.org

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Fedora-Cloud-31-20201116.0 compose check report

No missing expected images.

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

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-16 Thread Felix Schwarz



Am 16.11.20 um 10:28 schrieb Miro Hrončok:
If it is not urgent, provnpackagers should not go and make packaging changes 
without talking to the maintainer first.


+1

I think the main idea is that we try not to create artificial "hierarchies". 
Especially for a volunteer maintainer who maintains a few packages there might 
be a pretty strong emotional attachment to his packages which try to keep up to 
the highest packaging standards. If some provenpackager just goes into "his" 
package and seems to play by a different set of rules this can be pretty 
demotivating.


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

[Bug 1895570] perl-Tk-GraphViz-1.06 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Tk-GraphViz-1.06-1.fc3
   ||4
 Resolution|--- |RAWHIDE
   Assignee|lkund...@v3.sk  |jples...@redhat.com
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-11-16 10:17:29




-- 
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: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-16 Thread Vít Ondruch

Dne 16. 11. 20 v 10:22 Zbigniew Jędrzejewski-Szmek napsal(a):

On Mon, Nov 16, 2020 at 03:09:13AM -0500, Elliott Sales de Andrade wrote:

On Mon, 16 Nov 2020 at 03:06, Miroslav Suchý wrote:

Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a):

If you're going to have this kind of "upstream" spec file...well, I
wish you wouldn't. But if you do, *AT MINIMUM*, the "downstream" spec
files need to have a clear explanation that there is an "upstream" spec
file, with a justification as to why, and a link to it. At the very
top. Otherwise there is no chance any other Fedora packager is going to
find it.

This is actually a good idea. I have lots of such spec files.

Is it a good idea to document this in Packaging Guidelines?

It is already in the guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity

"If some maintainers are also attempting to keep copies of a spec in an
outside repository, they MUST be prepared to merge changes made to the
spec in Fedora’s repository, and MUST NOT overwrite those changes with
a copy from an external repository or using fedpkg import."

→ this means that in principle is OK to if a maintainer wants to keep
an "upstream" copy of the spec file, but it's their own problem to
ferry the changes back to that upstream copy. The rules only say that
they are not allowed to erase changes done by other packagers and releng.

If upstream provides SPEC files and your SPEC is a copy you should put on
top of SPEC
file:
# This SPEC file is a copy from upstream http://www.upstream.org/foo.spec

But that doesn't change much. First, such a comment is not machine readable

I should not propose this, because I agree with the points bellow. But
if we should have it, then:

~~~

Provides: upstream-spec(https://some.url/to/upstream/package.spec)

~~~

would be machine readable and it would give use some idea how common
this is.

Vít

But even if we apply some pattern matching, we hit the second problem: anyone
who is doing mass spec file updates (either releng or some provenpackager),
has now way to make use of this information. They are not going to
contact hundreds of upstreams to submit a cleanup fix. The only realistic
solution is what the guidelines say: it's up to the maintainer of the
package to ferry any changes back "upstream".

(More generally: what would the point of keeping an "upstream" spec
file be? Either the spec file is only used by one distro, in which
case everyone is better off if it's kept in the downstream repo. Or
it's used by multiple distros, in which case we either have an
über-complex spec file with %if-spaghetti or a spec file that doesn't
fit any distro well, and again, everyone would be better of if the
spec file were downstream.)

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

OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys

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

Re: Self Introduction - Jason Edgecombe

2020-11-16 Thread José Abílio Matos

On Monday, November 16, 2020 12:12:53 AM WET Jason Edgecombe wrote:
> Hello everyone,

Hi Jason,
  welcome to Fedora. :-)

> I'm a Linux admin at a university supporting  around 100+ EL7/8 and Ubuntu
> machines. I've been using Linux as a hobby since around 1994 and
> professionally  since 1999. My first Linux experience was installing
> Slackware from floppies on a computer with a 486DX processor (The
> predecessor to the Pentium chip)

My first experience was similar but with the DX2 (with an whooping 100 MHz). 
:-)

> In my personal time, I'm learning a little about fedora packaging in order
> to build some Fedora packages on RHEL8/CENTOS8 for my personal use. I'm
> somewhat familiar with RPM spec files and building RPMs.

Feel free to ask questions if you intend to submit packages for Fedora/EPEL.

> Sincerely,
> Jason

Regards,

PS: every time that by mistake I left the shift pressed for too long and write 
e.g. REgards it feels like I am applying a regular expression to something. 
Probably this is PTS . :-)
-- 
José Abílio___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: orphaning Taskotron-related packages


On 11/16/20 8:25 AM, František Zatloukal wrote:

Note: The email subject should have said "retiring" instead of
"orphaning".
There is little reason to orphan them, retiring is the right approach here.
Perhaps except for mongoquery, somebody else could be interested in
maintaining that, so that one should be orphaned instead.


The "correct" way to do this is to use orphaning procedure. This way, anybody 
interested will have enough time to take over the to-be removed packages.

Also, all packages that are orphaned for 6+ weeks get retired. This will happen 
before F34, so there is no harm in doing this through orphans.


Actually, if nothing requires it and it is upstream dead, retiring directly is 
fine. So is orphaning I guess.


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

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve


On 11/16/20 10:23 AM, Miroslav Suchý wrote:

Dne 16. 11. 20 v 9:09 Elliott Sales de Andrade napsal(a):

This is actually a good idea. I have lots of such spec files.

Is it a good idea to document this in Packaging Guidelines?

It is already in the guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity


Nope. This section describes what is the primary (canonical) location for 
**Fedora** and that it is maintainer
responsibilty to forward-port chenges from dist-git to upstream. When upstream 
of spec file exist.
But the section does not mention how to indicate that the upstream of SPEC file 
exists and that other maintainers MAY
send PR to that upstream if it is not urgent.


If it is not urgent, provnpackagers should not go and make packaging changes 
without talking to the maintainer first.


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

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-16 Thread Miroslav Suchý

Dne 16. 11. 20 v 9:09 Elliott Sales de Andrade napsal(a):
>> This is actually a good idea. I have lots of such spec files.
>>
>> Is it a good idea to document this in Packaging Guidelines?
> It is already in the guidelines:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity

Nope. This section describes what is the primary (canonical) location for 
**Fedora** and that it is maintainer
responsibilty to forward-port chenges from dist-git to upstream. When upstream 
of spec file exist.
But the section does not mention how to indicate that the upstream of SPEC file 
exists and that other maintainers MAY
send PR to that upstream if it is not urgent.

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

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

On Mon, Nov 16, 2020 at 03:09:13AM -0500, Elliott Sales de Andrade wrote:
> On Mon, 16 Nov 2020 at 03:06, Miroslav Suchý  wrote:
> >
> > Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a):
> > > If you're going to have this kind of "upstream" spec file...well, I
> > > wish you wouldn't. But if you do, *AT MINIMUM*, the "downstream" spec
> > > files need to have a clear explanation that there is an "upstream" spec
> > > file, with a justification as to why, and a link to it. At the very
> > > top. Otherwise there is no chance any other Fedora packager is going to
> > > find it.
> >
> > This is actually a good idea. I have lots of such spec files.
> >
> > Is it a good idea to document this in Packaging Guidelines?
> 
> It is already in the guidelines:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity

"If some maintainers are also attempting to keep copies of a spec in an
outside repository, they MUST be prepared to merge changes made to the
spec in Fedora’s repository, and MUST NOT overwrite those changes with
a copy from an external repository or using fedpkg import."

→ this means that in principle is OK to if a maintainer wants to keep
an "upstream" copy of the spec file, but it's their own problem to
ferry the changes back to that upstream copy. The rules only say that
they are not allowed to erase changes done by other packagers and releng.

> >   If upstream provides SPEC files and your SPEC is a copy you should put on 
> > top of SPEC
> >   file:
> >   # This SPEC file is a copy from upstream http://www.upstream.org/foo.spec

But that doesn't change much. First, such a comment is not machine readable
But even if we apply some pattern matching, we hit the second problem: anyone
who is doing mass spec file updates (either releng or some provenpackager),
has now way to make use of this information. They are not going to
contact hundreds of upstreams to submit a cleanup fix. The only realistic
solution is what the guidelines say: it's up to the maintainer of the
package to ferry any changes back "upstream".

(More generally: what would the point of keeping an "upstream" spec
file be? Either the spec file is only used by one distro, in which
case everyone is better off if it's kept in the downstream repo. Or
it's used by multiple distros, in which case we either have an
über-complex spec file with %if-spaghetti or a spec file that doesn't
fit any distro well, and again, everyone would be better of if the
spec file were downstream.)

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

Fedora-Cloud-32-20201116.0 compose check report

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

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

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

Re: Fedora 34 Change proposal: Stratis 2.2.0 (Self-Contained Change)

On Sun, Nov 15, 2020 at 04:28:36PM -0700, Chris Murphy wrote:
> On Sun, Nov 15, 2020 at 4:12 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Wed, Nov 04, 2020 at 01:12:44PM -0500, Ben Cotton wrote:
> > > * Name: [[User:dkeefe|Dennis Keefe]], [[User:mulhern|Anne Mulhern]],
> > > [[User:jbaublitz|John Baublitz]]
> > > * Email: dke...@redhat.com, amulh...@redhat.com, jbaubl...@redhat.com
> >
> > > == Upgrade/compatibility impact ==
> > >
> > > Stratis symlinks have moved.  Existing symlinks in /stratis/ > > name>/ will need to be migrated to
> > > /dev/stratis//.  This is accomplished by
> > > running the migration script (stratis_migrate_symlinks.sh) that comes
> > > with the
> > > 2.2.0 release of Stratis or rebooting the system.  Any configurations
> > > that make use of the old symlink locations will
> > > need to be updated to use the new location.  So, if there has been
> > > manual changes to systemd unit files or /etc/fstab
> > > for automatically mounting Stratis filesystems, then these will need
> > > to be updated to reflect the change.
> >
> > How large is the risk that systems that were using the old /stratis/foo
> > paths will fail to mount the filesystems, and possibly fail to boot, after
> > the upgrade? (Sorry, I have never used stratis, so I don't know how often
> > those migration steps would be necessary.)
> >
> > Shouldn't /startis symlink be created for compatibility on *upgrades* ?
> 
> It's not supported for booting yet. But if there's an fstab entry
> using a path from /stratis, and also doesn't include the nofail or
> noauto mount options, boot can fail waiting indefinitely on a file
> system that won't ever appear

Right, but the question is: how common is that? Do we even have any general
idea how many people are using stratis?

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

[Bug 1890933] Add perl-Pegex for EPEL8