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

2020-10-03 Thread updates 
The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ea01d505c9   
pdns-4.1.14-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a37e7c643e   
xawtv-3.107-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-98b234afda   
libuv-1.40.0-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-bd6a96cd24   
python34-3.4.10-7.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9eaf8d2e11   
prosody-0.11.7-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-50425dd33f   
rubygem-kramdown-1.9.0-2.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1eeb530261   
python3-urllib3-1.25.6-2.el7


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

nordugrid-arc-5.4.4-4.el7
nordugrid-arc6-6.7.0-2.el7
root-6.22.02-3.el7
xrdcl-http-5.0.2-1.el7
xrootd-5.0.2-1.el7
xrootd-compat-4.12.4-1.el7

Details about builds:



 nordugrid-arc-5.4.4-4.el7 (FEDORA-EPEL-2020-44ad46e846)
 Advanced Resource Connector Grid Middleware

Update Information:

xrootd 5

ChangeLog:

* Fri Aug 28 2020 Mattias Ellert  - 5.4.4-4
- xrootd 5 compatibility




 nordugrid-arc6-6.7.0-2.el7 (FEDORA-EPEL-2020-44ad46e846)
 Advanced Resource Connector Middleware

Update Information:

xrootd 5

ChangeLog:

* Fri Aug 28 2020 Mattias Ellert  - 6.7.0-2
- xrootd 5 compatibility




 root-6.22.02-3.el7 (FEDORA-EPEL-2020-44ad46e846)
 Numerical data analysis framework

Update Information:

xrootd 5

ChangeLog:

* Fri Oct  2 2020 Mattias Ellert  - 6.22.02-3
- Drop obsolete patch root-add-flexiblas-detection.patch (cmake's
  FindBLAS.cmake supports flexiblas now)
- Drop the workaround for the bug in doxygen causing different results
  on 32 and 64 bit architectures (use doxygen < 1.8.17 or >= 1.8.20-3)
- Build require xrootd 5 (Fedora 33+, EPEL 7+)
* Sun Aug 30 2020 Mattias Ellert  - 6.22.02-2
- Adapt to xrootd 5 (Fedora 33+, EPEL 7+)
  - Don't build the old proof client (xproofd)
  - Don't build the old NetX module




 xrdcl-http-5.0.2-1.el7 (FEDORA-EPEL-2020-44ad46e846)
 HTTP client plug-in for XRootD

Update Information:

xrootd 5

ChangeLog:

* Fri Sep 18 2020 Mattias Ellert  - 5.0.2-1
- Update to version 5.0.2
- Drop patches (accepted upstream or previously backported)
* Thu Aug 27 2020 Mattias Ellert  - 5.0.1-1
- Update to version 5.0.1
- Don't use versioned plugin names in configuration
- Backport plugin version change from git master
* Sat Aug  1 2020 Fedora Release Engineering  - 
4.12.2-3
- Second attempt - Rebuilt for
  https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Wed Jul 29 2020 Fedora Release Engineering  - 
4.12.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild




 xrootd-5.0.2-1.el7 (FEDORA-EPEL-2020-44ad46e846)
 Extended ROOT file server

Update Information:

xrootd 5

ChangeLog:

* Fri Sep 18 2020 Mattias Ellert  - 1:5.0.2-1
- Update to version 5.0.2
- Drop patches (accepted upstream or previously backported)
- Obsolete xrdhttpvoms in xrootd-voms package
* Thu Aug 27 2020 Mattias Ellert  - 1:5.0.1-1
- Update to version 5.0.1
- Remove conditionals for building on EPEL 6
- Drop patches (accepted upstream or previously backported)
- Fix 32 bit compilation (format error)
- Fix compilation on ARM, PPC and S390X (char is unsigned)

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

2020-10-03 Thread updates 
The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1790461e43   
chromium-85.0.4183.121-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0f2bfced63   
prosody-0.11.7-1.el8


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

darktable-3.2.1-7.el8
nordugrid-arc-6.7.0-4.el8
root-6.22.02-3.el8
xrdcl-http-5.0.2-1.el8
xrootd-5.0.2-1.el8

Details about builds:



 darktable-3.2.1-7.el8 (FEDORA-EPEL-2020-9b6ed35a25)
 Utility to organize and develop raw images

Update Information:

Enabled bundled Lua.    3.2.1 release resumed OpenMP on ppc64le aarch64
resumed OpenCL on ppc64le    3.2.1 release   Feedback concerning following
ticket would be appreciated https://github.com/darktable-
org/darktable/issues/5916

ChangeLog:

* Sat Oct  3 2020 Germano Massullo  - 3.2.1-7
- enabled bundled Lua, because darktable does not support Lua 5.4 that is 
shipped in Fedora and EPEL 8
* Sat Oct  3 2020 Germano Massullo  - 3.2.1-6
- Added BuildRequires: perl-lib for Fedora > 32 and EL > 8
* Fri Oct  2 2020 Germano Massullo  - 3.2.1-5
- Fixed Lua macros
- Fixed errors of new cmake macros
* Sat Sep 26 2020 Andreas Schneider  - 3.2.1-4
- Fix build with new cmake macros
* Fri Sep 25 2020 Germano Massullo  - 3.2.1-3
- resumed OpenMP on ppc64le aarch64
- resumed OpenCL on ppc64le
- added 0001.patch
- removed %ifnarch ppc64le %{_bindir}/darktable-cltest
* Fri Sep 25 2020 Germano Massullo  - 3.2.1-2
- Introduced new cmake macros for Fedora >= 33 and EL >= 9 
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
- Added BuildRequires: perl(FindBin)
- Added BuildRequires: cmake(libavif) for Fedora >= 33 and EL >= 9
* Mon Aug 10 2020 Germano Massullo  - 3.2.1-1
- 3.2.1 release
* Sat Aug  1 2020 Fedora Release Engineering  - 
3.0.2-3
- Second attempt - Rebuilt for
  https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Mon Jul 27 2020 Fedora Release Engineering  - 
3.0.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild

References:

  [ 1 ] Bug #1884581 - darktable lacks lua support (therefore: no extensions 
work)
https://bugzilla.redhat.com/show_bug.cgi?id=1884581




 nordugrid-arc-6.7.0-4.el8 (FEDORA-EPEL-2020-296f3d7907)
 Advanced Resource Connector Middleware

Update Information:

xrootd 5

ChangeLog:

* Fri Aug 28 2020 Mattias Ellert  - 6.7.0-4
- xrootd 5 compatibility
* Tue Jul 28 2020 Fedora Release Engineering  - 
6.7.0-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Mon Jul 27 2020 Jeff Law  - 6.7.0-2
- Always specify C++11 or C++14 rather than using the default
  (which will be C++17 in the near future and this code is not C++17
  ready).




 root-6.22.02-3.el8 (FEDORA-EPEL-2020-296f3d7907)
 Numerical data analysis framework

Update Information:

xrootd 5

ChangeLog:

* Fri Oct  2 2020 Mattias Ellert  - 6.22.02-3
- Drop obsolete patch root-add-flexiblas-detection.patch (cmake's
  FindBLAS.cmake supports flexiblas now)
- Drop the workaround for the bug in doxygen causing different results
  on 32 and 64 bit architectures (use doxygen < 1.8.17 or >= 1.8.20-3)
- Build require xrootd 5 (Fedora 33+, EPEL 7+)
* Sun Aug 30 2020 Mattias Ellert  - 6.22.02-2
- Adapt to xrootd 5 (Fedora 33+, EPEL 7+)
  - Don't build the old proof client (xproofd)
  - Don't build the old NetX module




 xrdcl-http-5.0.2-1.el8 (FEDORA-EPEL-2020-296f3d7907)
 HTTP client plug-in for XRootD

Update Information:

xrootd 5

ChangeLog:

* Fri Sep 18 2020 Mattias Ellert  - 5.0.2-1
- Update to version 5.0.2
- Drop patches (accepted upstream or previously backported)
* Thu Aug 27 2020 Mattias

[Bug 1859831] bugzilla-5.0.6-6.fc33 FTBFS: %_python_bytecompile_extra is discontinued

2020-10-03 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1859831

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||bugzilla-5.0.6-9.fc33
 Resolution|--- |ERRATA
Last Closed||2020-10-04 00:15:32



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


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

[Bug 1855962] bugzilla can't send non-html email

2020-10-03 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1855962

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||bugzilla-5.0.6-9.fc33
 Resolution|--- |ERRATA
Last Closed||2020-10-04 00:15:29



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


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

[Bug 1882884] perl-Lingua-Stem-2.31 is available

2020-10-03 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1882884

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Lingua-Stem-2.31-1.fc3 |perl-Lingua-Stem-2.31-1.fc3
   |4   |4
   ||perl-Lingua-Stem-2.31-1.fc3
   ||3
 Resolution|--- |ERRATA
Last Closed||2020-10-04 00:14:59



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


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

Re: %set_build_flags problem in rpm spec file

2020-10-03 Thread Ruki Wang 
ok, I will try it. Thanks! : )

在 2020年10月3日星期六，Neal Gompa  写道：

> On Sat, Oct 3, 2020 at 10:18 AM Vitaly Zaitsev via devel
>  wrote:
> >
> > On 03.10.2020 15:47, Ruki Wang wrote:
> > > I try `%?set_build_flags` and it works fine.
> >
> > No, it will not. This command will just force RPM to ignore errors. No
> > actual build flags will be forwarded.
> >
> > You need to create separate SPEC files for Fedora and openSUSE.
> >
>
> That's not even close to true. The solution is quite simple for
> handling openSUSE Leap.
>
> Instead of "%set_build_flags" or "%?set_build_flags", do the following:
>
> %if 0%{?suse_version} && 0%{?suse_version} < 1550
> export CFLAGS="%{optflags}"
> export CXXFLAGS="%{optflags}"
> %else
> %set_build_flags
> %endif
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.
> org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
> fedoraproject.org
>


-- 

Ruki Wang
war...@gmail.com
https://github.com/waruqi
https://twitter.com/waruqi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Error creating the package RPM: make:*** No rule to make target 'install'.

2020-10-03 Thread Helg Green via devel 
Thank you very much!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Donate 1 minute of your time to test upgrades from F32 to F33

2020-10-03 Thread Tom Seewald 
During an attempted upgrade to F33 Beta I ran into:

Error: Transaction test error:
  file /usr/lib/.build-id/0e/fd9f1f23d7cefd37989b7d1b401b4994fee742 conflicts 
between attempted installs of openjfx-11.0.3-1.fc33.x86_64 and 
openjfx8-8.0.202-24.b07.fc33.x86_64
  file /usr/lib/.build-id/2d/747b771939ec456dadf18bfbec6a5db9d3a4cc conflicts 
between attempted installs of openjfx-11.0.3-1.fc33.x86_64 and 
openjfx8-8.0.202-24.b07.fc33.x86_64

If this needs to be formally filed as a bug, should it be opened against 
openjfx or fedora-upgrade or something else?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Package downgrades from fedora 32 -> fedora 33 (updated + annotated list inside)

2020-10-03 Thread Felix Schwarz 
Am 03.10.20 um 00:53 schrieb Fabio Valentini:
> - python3-certbot-dns-google is newer in 32 than in 33:
>   0:1.7.0-1.fc32 > 0:1.5.0-1.fc33
> 
> This is caused by python-certbot-dns-google being FTBFS for fedora 33+.
> There was no FTBFS bug reported for it, but both releng builds have failed.
> The subsequent update to 1.7.0 was also not pushed to f33 and rawhide ...

This is due to a missing dependency in F33+. I think this got fixed only very
recently but I'll check again. It's on my TODO list (though that became quite
long over the last month).

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

Re: Self Introduction: Boian Bonev

2020-10-03 Thread Matthew Miller 
On Sat, Oct 03, 2020 at 11:29:43PM +0300, bbonev wrote:
> Already did that in git yesterday, I will wait a couple of days to see if
> something else is suggested and will update the bug.
>  
> BTW. How it goes with review and sponsorship in Fedora community - do I
> need to do something more or I have already done all that is needed and
> just wait?

You will need someone to sponsor you into the packaging group. See 
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join#How_to_join_the_Fedora_Package_Collection_Maintainers.3F



-- 
Matthew Miller

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

Re: Self Introduction: Boian Bonev

2020-10-03 Thread bbonev 
 
 
 
Hi Matthew,  
 

 
Already did that in git yesterday, I will wait a couple of days to see if 
something else is suggested and will update the bug.
 

 
BTW. How it goes with review and sponsorship in Fedora community - do I need to 
do something more or I have already done all that is needed and just wait?  
 

 
With best regards,  
 
b.  
 

 
 
 
 
>  
> On Oct 3, 2020 at 20:31, Matthew Millerwrote:
>  
>  
>  On Sat, Oct 03, 2020 at 01:28:22AM +0300, Boian Bonev wrote:  >  Here I mean 
> the project name, which is iotop-c. I see no problem in  >  renaming the 
> binary. Yeah, I'd suggest just making it match -- `iotop-c` 
>  
>  
>  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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/33 livedisks do not boot on M$ system(s)

2020-10-03 Thread Chris Murphy 
On Sat, Oct 3, 2020 at 4:09 AM Marius Schwarz  wrote:
>
> Am 03.10.20 um 11:43 schrieb Tomasz Torcz:
>
> If you do not state the devicename, how does grub choose the correct
>
> drive? I don't want to overwrite the bootloader on the ssd.
>
>   There is only one correct ESP partition in EFI system to install
> bootloader to. You can read the code finding it at
> https://github.com/rhboot/grub2/blob/master/util/grub-install.c#L1029
>
>
>
> That seems to be commented incorrectly:
>
> L1045:
>   /*
> The EFI System Partition may have been given directly using
> --root-directory.
>   */
>
> there is no such option according to man and --help .
>
>grub-install [--modules=MODULES] [--install-modules=MODULES]
>  [--themes=THEMES] [--fonts=FONTS] [--locales=LOCALES]
>  [--compress[=no,xz,gz,lzo]] [-d | --directory=DIR]
>  [--grub-mkimage=FILE] [--boot-directory=DIR]
>  [--target=TARGET] [--grub-setup=FILE]
>  [--grub-mkrelpath=FILE] [--grub-probe=FILE]
>  [--allow-floppy] [--recheck] [--force] [--force-file-id]
>  [--disk-module=MODULE] [--no-nvram] [--removable]
>  [--bootloader-id=ID] [--efi-directory=DIR] INSTALL_DEVICE
>
> could --efi-directory be meant?
>
> ### UPDATE ###
>
>  after investigating the problem with not finding grub.cfg in the 
> proprosed bootpath /boot/ .. the solution was simple.
>
> The system died not use secure boot, as secure-boot was disabled for the 
> kernel-surface kernelseries. They are not signed, so no secure boot possible.
>
> Means: bios is loading "/boot/grub2/grub.cfg" but it can't find it, because 
> those are symlinks to "/boot/efi/fedora/grub.cfg" but that is not accessible, 
> because the partition it's linked to, is not mounted there when grub starts.

A grub2-install based grubx64.efi expects to find the grub.cfg in
/boot/grub2/grub.cfg. This OSLoader is not signed.

The grub2-efi-x64-2.04-31.fc33.x86_64 based grubx64.efi expects to
find the grub.cfg on the EFI system partition inside EFI/fedora/ and
this OSLoader is signed.

Basically you've stepped through the Looking Glass by using
grub2-install on a UEFI computer.

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

Re: Fedora 32/33 livedisks do not boot on M$ system(s)

2020-10-03 Thread Chris Murphy 
On Fri, Oct 2, 2020 at 3:12 AM Petr Pisar  wrote:
>
> On Thu, Oct 01, 2020 at 11:07:28AM -0700, Samuel Sieb wrote:
> > On 10/1/20 5:52 AM, Marius Schwarz wrote:
> > >
> > > >
> > > > Is it possible to boot from the stick and then perform a grub-install
> > > > with an old grub?
> > > >
> > >
> > > This attempt failed too:
> > >
> > > #  grub2-install /dev/sda
> > > grub2-install: Fehler: /usr/lib/grub/x86_64-efi/modinfo.sh existiert
> > > nicht. Bitte geben Sie --target oder --directory an.
> > >
> > > and that file seems not to be part of any package. There is only one for
> > > "i386-pc".
> >
> > You can't (and must not!) use grub2-install on an EFI system.
>
> Of course you have. How else would you get GRUB EFI executable onto the boot
> partition and register it into boot environments?

It's in an arch specific RPM. e.g.
grub2-efi-x64-2.04-31.fc34.x86_64.rpm contains grubx64.efi created and
signed within the Fedora build system.

The grub2-install created executable is not signed, will not work with
UEFI Secure Boot enabled unless manually signed by the user, and it
has different behavior from the Fedora created one: where it expects
to find modules and the grub.cfg.

> But the correct invocation for EFI systems is different. You just use
> "grub2-install" without the disk device name.

No the correct invocation is "dnf reinstall grub2-efi-x64 shim-x64"

Suggesting UEFI users install GRUB with grub2-install is asking for a
support nightmare, it's untenable.

-- 
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 1884931] New: perl-Pod-Checker-1.74 is available

2020-10-03 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1884931

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



Latest upstream release: 1.74
Current version/release in rawhide: 1.73-457.fc33
URL: http://search.cpan.org/dist/Pod-Checker/

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


-- 
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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

2020-10-03 Thread Jan Kratochvil 
On Mon, 28 Sep 2020 16:51:02 +0200, Jan Kratochvil wrote:
> To make DWZ better consumable it needs to have the partial units separately
> parseable. That way they can be shared at IR level and not just at DWARF level
> That means:
>  * DW_TAG_partial_unit should have DW_AT_language.
>  * DW_TAG_partial_unit must contain only types (struct/class).
>Currently they contain for example also static constant variables but when
>you parse such independent DW_TAG_partial_unit into which dictionary you
>will register such variable? That makes no sense.
> Currently DWZ has benefits only with DWZ common file. Without DWZ common files
> DWZ produces 1.6% files bigger than -fdebug-types-section. Therefore if the
> DWZ common files saving of 3.3% per Fedora distribution size is worth it then
> the existing DWZ tool should be dropped anyway as one can use normal
> -fdebug-types-section and one can just write a simple tool moving DW_UT_type
> units to the DWZ common file and converting DW_AT_signature declarations to
> DW_FORM_ref_sup4 and we are done.

I have measured this "a different common file" for DW_UT_type and it brings
18.14% size reduction of what DWZ does. With additional dropping of dead DIEs
+ dropping -fdebug-types-section type declaratins which achieves about 28%
this makes it together 46% of what DWZ reduces possible without those
overcomplicated constructs of DWZ.

Original comparison of plain -fdebug-types-section DWZ makes the Fedora
distribution 3.3% smaller.

-fdebug-types-section with some simple optimizations (just reusing existng
-fdebug-types-section code in consumers + DWZ common file opening in consumers
together with removal of dead DIEs) DWZ is still slightly smaller but already
only by 1.8% of the Fedora distribution size.

Sure my proposal does not expect that few percents matter. I have checked
further possibilities based on a the mail replies here which seem to insist on
any debuginfo size savings.


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

2020-10-03 Thread Matthew Miller 
On Sat, Oct 03, 2020 at 01:28:22AM +0300, Boian Bonev wrote:
> Here I mean the project name, which is iotop-c. I see no problem in
> renaming the binary.

Yeah, I'd suggest just making it match -- `iotop-c`.


-- 
Matthew Miller

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

[EPEL-devel] Re: proposal: EPEL 8 Next

2020-10-03 Thread Kevin Fenzi 
On Thu, Oct 01, 2020 at 11:12:28PM -0500, Carl George wrote:
> Here is my rough outline of the steps required to implement this proposal.
> I imagine things would happen roughly in this order, but some things could
> probably take place in parallel.
> 
> 1. EPEL Steering Committee approves the proposal
> 2. koji changes:
> - create CentOS Stream 8 external repo
> - create epel8-next build target (inheriting from epel8)
> - dist macro override for that target
> 3. create PDC entries
> 4. update fedscm-admin with branch SLAs
> 5. configure dist-git to allow branch name
> 6. update pungi config
> 7. add epel-next-repo subpackage to epel-release
> 8. add epel8-next release in bodhi
> 9. document in the wiki
> 10. announcement email
> 
> Please let me know if I'm missing anything.

Looks pretty good to me, but two things: 

1. I assume (but good to ask) that we are not going to change anything
in bugzilla? ie, bug reports should just go against the epel component? 
Of course now that playground is 'seperate' and next will also be, would
we ever have cases where we have a component without epel branch, but
with playground and/or next? And what would we do for bugs there?

2. We are heading into final freeze for Fedora 33 next tuesday, so not
sure how much will get done until f33 is out the door. Is it ok to do
this after? Some of it could be done with freeze breaks and such, but
might be easier just to do it all at once after f33 freeze is over?

Thanks much for putting this together!

kevin
--

> 
> On Wed, Sep 23, 2020 at 8:43 PM Carl George  wrote:
> >
> > I agree, using .el8.next for the dist macro makes the most sense.  This will
> > enable maintainers to use a similar workflow to Fedora branches, where older
> > branches can be fast forwarded, and the same commit can be built for
> > different targets but still have different NVRs in Koji.  Here is an example
> > workflow for a fictional foo package that already exists in Fedora.
> >
> > - request epel8 branch
> > - merge master branch to epel8 branch
> > - build epel8 branch, resulting in foo-1-1.el8
> > - realize it won't install on CentOS Stream due to a library difference
> > - request epel8-next branch
> > - merge epel8 branch to epel8-next branch
> > - build epel8-next branch, resulting in foo-1-1.el8.next
> >
> > After the next RHEL 8 minor release (when that library difference affects
> > everyone), the maintainer can increment the release on the epel8 branch and
> > proceed as usual.
> >
> > On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi  wrote:
> > >
> > > On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote:
> > > > At the EPEL Steering Committee last week, we had an extensive 
> > > > discussion of
> > > > this proposal, specifically focused on how to handle the dist macro.  I
> > > > believe these are the possible choices.
> > > >
> > > > * keep dist the same as epel8 (.el8)
> > > >
> > > > RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using 
> > > > .el8 for
> > > > dist.  It would make sense to continue using the same dist for EPEL 
> > > > Next.
> > > > However, this would put a little more work on packagers.  They would 
> > > > not be
> > > > able to build the same commit for both EPEL and EPEL Next because the 
> > > > NVR
> > > > will conflict in Koji.  In simple rebuild situations, this is not a 
> > > > problem
> > > > because at a minimum the release will be higher.  But if a packager 
> > > > wanted
> > > > to update the package in both EPEL and EPEL Next, they will need to 
> > > > first
> > > > update and build it in EPEL, then bump the release and build it in EPEL
> > > > Next.  This isn't ideal, but isn't terrible either, and can be partially
> > > > mitigated by good documentation around EPEL Next workflows.
> > > >
> > > > * modify dist to always be higher than epel8 (.el8.next or similar)
> > > >
> > > > In EPEL Next we could define dist to a string that RPM evaluates higher 
> > > > than
> > > > .el8, such as .el8.next.  This would allow EPEL and EPEL Next branches 
> > > > to be
> > > > in sync and the same commit could be built for both targets.  The higher
> > > > dist would ensure the upgrade path works.
> > >
> > > I think this makes the most sense and will help packages workflows the
> > > best.
> > >
> > > kevin
> > > ___
> > > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> > > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: 
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: 
> > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> >
> >
> >
> > --
> > Carl George
> 
> 
> 
> -- 
> Carl George
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send

Re: Fwd: Orphaned packages of skisela

2020-10-03 Thread Andy Mender 
On Fri, 2 Oct 2020 at 11:53, Vít Ondruch  wrote:

> Hi,
>
> I was in contact with Sebastian, who used to work for RH and maintained
> several Fedora packages. However, due to chances in his live, he decided to
> orphan his packages. Since he is not subscribed to fedora-devel ML, I'm
> forwarding his email.
>
>
> Vít
>
>
>
>
>  Přeposlaná zpráva 
> Předmět: Fwd: Orphaned packages of skisela
> Datum: Fri, 2 Oct 2020 11:48:32 +0200
> Od: Sebastián Kisela 
> 
> Komu: Vít Ondruch  
>
>
>
> -- Forwarded message -
> From: 
> Date: Fri 2. Oct 2020 at 11:32
> Subject: Orphaned packages of skisela
> To: 
>
>
> Your message to the devel mailing-list was rejected for the following
>
> reasons:
>
>
>
> The message is not from a list member
>
>
>
> The original message as received by Mailman is attached.
>
>
>
>
> -- Forwarded message --
> From: "Sebastián Kisela" 
> To: devel@lists.fedoraproject.org
> Cc:
> Bcc:
> Date: Fri, 2 Oct 2020 11:31:16 +0200
> Subject: Orphaned packages of skisela
> Dear all,
>
> sorry for leaving so much time for that, but I finally orphaned the
> packages I did not manage to maintain.
>
> The list is:
>
> lockdev
> pstoedit
> psutils
> python-ansicolors
> python-yattag
>

If possible, I'd like to pick up python-ansicolors.

Thanks!
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: %set_build_flags problem in rpm spec file

2020-10-03 Thread Neal Gompa 
On Sat, Oct 3, 2020 at 11:09 AM Vitaly Zaitsev via devel
 wrote:
>
> On 03.10.2020 16:54, Neal Gompa wrote:
> > Instead of "%set_build_flags" or "%?set_build_flags", do the following:
>
> Don't forget about the different package names in Fedora and openSUSE.
>
> Maintainers can use something like this to avoid this problem:
>
> BuildRequires: cmake(Foo)
> BuildRequires: pkgconfig(foo)

That's true. Thankfully this is rarer with -devel packages, but yes,
using generic common names like pkgconfig(), cmake(), perl(), rubygem(), and
others will help this considerably.



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

Re: %set_build_flags problem in rpm spec file

2020-10-03 Thread Vitaly Zaitsev via devel 
On 03.10.2020 16:54, Neal Gompa wrote:
> Instead of "%set_build_flags" or "%?set_build_flags", do the following:

Don't forget about the different package names in Fedora and openSUSE.

Maintainers can use something like this to avoid this problem:

BuildRequires: cmake(Foo)
BuildRequires: pkgconfig(foo)

-- 
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: %set_build_flags problem in rpm spec file

2020-10-03 Thread Neal Gompa 
On Sat, Oct 3, 2020 at 10:18 AM Vitaly Zaitsev via devel
 wrote:
>
> On 03.10.2020 15:47, Ruki Wang wrote:
> > I try `%?set_build_flags` and it works fine.
>
> No, it will not. This command will just force RPM to ignore errors. No
> actual build flags will be forwarded.
>
> You need to create separate SPEC files for Fedora and openSUSE.
>

That's not even close to true. The solution is quite simple for
handling openSUSE Leap.

Instead of "%set_build_flags" or "%?set_build_flags", do the following:

%if 0%{?suse_version} && 0%{?suse_version} < 1550
export CFLAGS="%{optflags}"
export CXXFLAGS="%{optflags}"
%else
%set_build_flags
%endif



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

Re: %set_build_flags problem in rpm spec file

2020-10-03 Thread Vitaly Zaitsev via devel 
On 03.10.2020 15:47, Ruki Wang wrote:
> I try `%?set_build_flags` and it works fine.

No, it will not. This command will just force RPM to ignore errors. No
actual build flags will be forwarded.

You need to create separate SPEC files for Fedora and openSUSE.

-- 
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: %set_build_flags problem in rpm spec file

2020-10-03 Thread Ruki Wang 
I try `%?set_build_flags` and it works fine.

Thanks!

Miro Hrončok  于2020年10月3日周六 下午2:45写道：

> On 03. 10. 20 5:04, Ruki Wang wrote:
> > Hi, every one.
> >
> > I am making rpm spec and doing tests on copr.
> >
> > But on opensuse-leap-15.1-*, %set_build_flags still causes some problems.
> >
> >
> > + %set_build_flags
> > /var/tmp/rpm-tmp.9RYL8i: line 32: fg: no job control
> > error: Bad exit status from /var/tmp/rpm-tmp.9RYL8i (%build)
> >  Bad exit status from /var/tmp/rpm-tmp.9RYL8i (%build)
> >
> >
> > Links:
> >
> > https://copr.fedorainfracloud.org/coprs/waruqi/xmake/build/1693007/
> >
> https://download.copr.fedorainfracloud.org/results/waruqi/xmake/opensuse-leap-15.2-x86_64/01693007-xmake/builder-live.log.gz
> > <
> https://download.copr.fedorainfracloud.org/results/waruqi/xmake/opensuse-leap-15.2-x86_64/01693007-xmake/builder-live.log.gz
> >
> >
> > Buzilla:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1882871
> >
> > Does anyone know the reason for this? Thanks!
> > 
>
> Yes. The reason is openSUSE and Fedora are different. and they don't have
> our macro.
>
> A quick "make it build" action would be to add ?:
>
>  %?set_build_flags
>
> However, the openSUSE build might not have the proper flags.
>
> --
> 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
>


-- 

Ruki Wang
war...@gmail.com
https://github.com/waruqi
https://twitter.com/waruqi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: %set_build_flags problem in rpm spec file

2020-10-03 Thread Ruki Wang 
Got it, thanks!

Neal Gompa  于2020年10月3日周六 下午8:07写道：

> On Sat, Oct 3, 2020 at 2:45 AM Miro Hrončok  wrote:
> >
> > On 03. 10. 20 5:04, Ruki Wang wrote:
> > > Hi, every one.
> > >
> > > I am making rpm spec and doing tests on copr.
> > >
> > > But on opensuse-leap-15.1-*, %set_build_flags still causes some
> problems.
> > >
> > >
> > > + %set_build_flags
> > > /var/tmp/rpm-tmp.9RYL8i: line 32: fg: no job control
> > > error: Bad exit status from /var/tmp/rpm-tmp.9RYL8i (%build)
> > >  Bad exit status from /var/tmp/rpm-tmp.9RYL8i (%build)
> > >
> > >
> > > Links:
> > >
> > > https://copr.fedorainfracloud.org/coprs/waruqi/xmake/build/1693007/
> > >
> https://download.copr.fedorainfracloud.org/results/waruqi/xmake/opensuse-leap-15.2-x86_64/01693007-xmake/builder-live.log.gz
> > > <
> https://download.copr.fedorainfracloud.org/results/waruqi/xmake/opensuse-leap-15.2-x86_64/01693007-xmake/builder-live.log.gz
> >
> > >
> > > Buzilla:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1882871
> > >
> > > Does anyone know the reason for this? Thanks!
> > > 
> >
> > Yes. The reason is openSUSE and Fedora are different. and they don't
> have our macro.
> >
> > A quick "make it build" action would be to add ?:
> >
> >  %?set_build_flags
> >
> > However, the openSUSE build might not have the proper flags.
> >
>
> It's because %set_build_flags was introduced in RPM 4.15, and openSUSE
> Leap 15.x uses RPM 4.14. Moreover, openSUSE Leap 15.1 predates the
> introduction of the macro even upstream. It was not backported into
> openSUSE Leap 15.2 either, so the macro just doesn't exist in openSUSE
> Leap yet.
>
> The macro was backported to RHEL 8 during its development, so it
> exists there despite it using RPM 4.14 as well.
>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Ruki Wang
war...@gmail.com
https://github.com/waruqi
https://twitter.com/waruqi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Donate 1 minute of your time to test upgrades from F32 to F33

2020-10-03 Thread Artur Frenszek-Iwicki 
>Problem 1: package copydeps-4.0-3.fc32.noarch requires python(abi) = 3.8, but 
>none of the providers can be installed
>  - python3-3.8.5-5.fc32.x86_64 does not belong to a distupgrade repository
>  - problem with installed package copydeps-4.0-3.fc32.noarch
This is because copydeps has been rewritten in Rust, so I retired the python 
package ("copydeps") in favour of the Rust one ("rust-copydeps"). However, as I 
wrote earlier on devel [1], my Rust packages got unpushed from F33, so now 
there's no new version for copydeps to get upgraded to.

>Problem 2: package hedgewars-1.0.0-12.fc33.x86_64 requires 
>libQt5Core.so.5(Qt_5.14.2_PRIVATE_API)(64bit), but none of the providers can 
>be installed
>  - package hedgewars-1.0.0-12.fc33.x86_64 requires qt5-qtbase(x86-64) = 
> 5.14.2, but none of the providers can be installed
>  - problem with installed package hedgewars-1.0.0-9.fc32.x86_64
>  - qt5-qtbase-5.14.2-5.fc32.x86_64 does not belong to a distupgrade repository
>  - hedgewars-1.0.0-9.fc32.x86_64 does not belong to a distupgrade repository
The error message is for 1.0.0-12, but I see that 1.0.0-13 has been built and 
submitted to bodhi recently [2]. Since it's marked as "pushed to stable", I 
guess it's just a matter of waiting for the mirrors to propagate.

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/J6QVZZLWBVWZPX6FIRMEX7MURGIHKDKS/
[2] https://bodhi.fedoraproject.org/updates/FEDORA-2020-8c4a470e9c
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: sundials-5.4.0 updating

2020-10-03 Thread Antonio T. sagitter 
Hi again.

You can build packages depending on Sundials by using the side-tag
f34-build-side-31299:

Use 'fedpkg build --target=f34-build-side-31299' to use it.
Use 'koji wait-repo f34-build-side-31299' to wait for the build repo to
be generated.

On 25/09/20 21:04, Antonio T. sagitter wrote:
> Hi all.
> 
> Sundials will be updated to the release 5.4.0 on Rawhide branch in 7
> days at least. Probably, i will create a specific side-tag.
> 
> Sundials 5.4.0 release notes:
> https://github.com/LLNL/sundials/releases/tag/v5.4.0
> 
> Regards.
> 

-- 
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/



signature.asc
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: %set_build_flags problem in rpm spec file

2020-10-03 Thread Neal Gompa 
On Sat, Oct 3, 2020 at 2:45 AM Miro Hrončok  wrote:
>
> On 03. 10. 20 5:04, Ruki Wang wrote:
> > Hi, every one.
> >
> > I am making rpm spec and doing tests on copr.
> >
> > But on opensuse-leap-15.1-*, %set_build_flags still causes some problems.
> >
> >
> > + %set_build_flags
> > /var/tmp/rpm-tmp.9RYL8i: line 32: fg: no job control
> > error: Bad exit status from /var/tmp/rpm-tmp.9RYL8i (%build)
> >  Bad exit status from /var/tmp/rpm-tmp.9RYL8i (%build)
> >
> >
> > Links:
> >
> > https://copr.fedorainfracloud.org/coprs/waruqi/xmake/build/1693007/
> > https://download.copr.fedorainfracloud.org/results/waruqi/xmake/opensuse-leap-15.2-x86_64/01693007-xmake/builder-live.log.gz
> > 
> >
> > Buzilla:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1882871
> >
> > Does anyone know the reason for this? Thanks!
> > 
>
> Yes. The reason is openSUSE and Fedora are different. and they don't have our 
> macro.
>
> A quick "make it build" action would be to add ?:
>
>  %?set_build_flags
>
> However, the openSUSE build might not have the proper flags.
>

It's because %set_build_flags was introduced in RPM 4.15, and openSUSE
Leap 15.x uses RPM 4.14. Moreover, openSUSE Leap 15.1 predates the
introduction of the macro even upstream. It was not backported into
openSUSE Leap 15.2 either, so the macro just doesn't exist in openSUSE
Leap yet.

The macro was backported to RHEL 8 during its development, so it
exists there despite it using RPM 4.14 as well.




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

Fedora-IoT-33-20201003.0 compose check report

2020-10-03 Thread Fedora compose checker 
No missing expected images.

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

Old soft failures (same test soft failed in Fedora-IoT-33-20201002.0):

ID: 684227  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/684227

Passed openQA tests: 15/16 (x86_64)
-- 
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 32/33 livedisks do not boot on M$ system(s)

2020-10-03 Thread Marius Schwarz 
Am 03.10.20 um 11:43 schrieb Tomasz Torcz:
> If you do not state the devicename, how does grub choose the correct
>> drive? I don't want to overwrite the bootloader on the ssd.
>   There is only one correct ESP partition in EFI system to install
> bootloader to. You can read the code finding it at
> https://github.com/rhboot/grub2/blob/master/util/grub-install.c#L1029
>
>

That seems to be commented incorrectly:

L1045:
      /*
        The EFI System Partition may have been given directly using
        --root-directory.
      */

there is no such option according to man and --help .

   grub-install [--modules=MODULES] [--install-modules=MODULES]
 [--themes=THEMES] [--fonts=FONTS] [--locales=LOCALES]
 [--compress[=no,xz,gz,lzo]] [-d | --directory=DIR]
 [--grub-mkimage=FILE] [--boot-directory=DIR]
 [--target=TARGET] [--grub-setup=FILE]
 [--grub-mkrelpath=FILE] [--grub-probe=FILE]
 [--allow-floppy] [--recheck] [--force]
[--force-file-id]
 [--disk-module=MODULE] [--no-nvram] [--removable]
 [--bootloader-id=ID] [*--efi-directory=DIR*]
INSTALL_DEVICE

could --efi-directory be meant?

### UPDATE ###

 after investigating the problem with not finding grub.cfg in the
proprosed bootpath /boot/ .. the solution was simple.

The system died not use secure boot, as secure-boot was disabled for the
kernel-surface kernelseries. They are not signed, so no secure boot
possible.

Means: bios is loading "/boot/grub2/grub.cfg" but it can't find it,
because those are symlinks to "/boot/efi/fedora/grub.cfg" but that is
not accessible, because the partition it's linked to, is not mounted
there when grub starts.

those symlinks where necessary to fix some  other bugs with grubby,
which has a slight different imagination where to do updates to
grub.cfg, as grub itself has. In other words, one loads from efi path,
one not . So symlinks were there to keep them in Sync. ( documented in a
grub/grubby br @ bz )

Because it worked before the grub2-install with those symlinks (grub.cfg
& grubenv) , there needs to be a different grub-install cmd needed :
which could that be?

(for now my system starts again)

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

Re: Fedora 32/33 livedisks do not boot on M$ system(s)

2020-10-03 Thread Tomasz Torcz 
On Sat, Oct 03, 2020 at 11:17:44AM +0200, Marius Schwarz wrote:
> Am 02.10.20 um 11:12 schrieb Petr Pisar:
> > On Thu, Oct 01, 2020 at 11:07:28AM -0700, Samuel Sieb wrote:
> >> On 10/1/20 5:52 AM, Marius Schwarz wrote:
>  Is it possible to boot from the stick and then perform a grub-install
>  with an old grub?
> 
> >>> This attempt failed too:
> >>>
> >>> #  grub2-install /dev/sda
> >>> grub2-install: Fehler: /usr/lib/grub/x86_64-efi/modinfo.sh existiert
> >>> nicht. Bitte geben Sie --target oder --directory an.
> >>>
> >>> and that file seems not to be part of any package. There is only one for
> >>> "i386-pc".
> >> You can't (and must not!) use grub2-install on an EFI system.
> > Of course you have. How else would you get GRUB EFI executable onto the boot
> > partition and register it into boot environments?
> >
> > But the correct invocation for EFI systems is different. You just use
> > "grub2-install" without the disk device name.
> If you do not state the devicename, how does grub choose the correct
> drive? I don't want to overwrite the bootloader on the ssd.

  There is only one correct ESP partition in EFI system to install
bootloader to. You can read the code finding it at
https://github.com/rhboot/grub2/blob/master/util/grub-install.c#L1029


-- 
Tomasz Torcz“Funeral in the morning, IDE hacking
to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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/33 livedisks do not boot on M$ system(s)

2020-10-03 Thread Marius Schwarz 
Am 03.10.20 um 11:17 schrieb Marius Schwarz:
>
> FYI: Not working without manual corrections
>
> insmod lvm
> insmod xfs
> set root=(hd0,gpt3)
> configfile /grub2/grub.cfg
> linux /vmlinuz-5.8.10
> initrd /initramfs-5.8.10
> boot
>
> Q: Why is configfile read, but not used if anything important is in it
> i.e. the sysroot options passed to "linux" to find the decrypted luks
> partition?
>

A: because it's not found

This is working and maybe the clue, why grub2-install fails:

set root=(hd0,gpt3)
configfile (hd0,gpt2)/grub2/grub.cfg


Any ideas?

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

2020-10-03 Thread Fedora compose checker 
Missing expected images:

Xfce raw-xz armhfp

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

Failed openQA tests: 13/181 (x86_64)

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

ID: 684043  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/684043
ID: 684047  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/684047
ID: 684161  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/684161

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

ID: 684055  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/684055
ID: 684056  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/684056
ID: 684059  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/684059
ID: 684066  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/684066
ID: 684069  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/684069
ID: 684070  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/684070
ID: 684078  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/684078
ID: 684114  Test: x86_64 universal install_blivet_resize_lvm
URL: https://openqa.fedoraproject.org/tests/684114
ID: 684139  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/684139
ID: 684173  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/684173

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

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

ID: 684054  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/684054
ID: 684074  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/684074
ID: 684077  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/684077
ID: 684091  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/684091
ID: 684104  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/684104

Passed openQA tests: 163/181 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20200930.n.0):

ID: 683995  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/683995
ID: 684014  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/684014
ID: 684041  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/684041
ID: 684111  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/684111
ID: 684126  Test: x86_64 universal install_blivet_btrfs
URL: https://openqa.fedoraproject.org/tests/684126

Installed system changes in test x86_64 Server-boot-iso install_default: 
Used mem changed from 208 MiB to 184 MiB
1 packages(s) added since previous compose: gpg-pubkey
Previous test data: https://openqa.fedoraproject.org/tests/681315#downloads
Current test data: https://openqa.fedoraproject.org/tests/683993#downloads

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
Used mem changed from 209 MiB to 186 MiB
1 packages(s) added since previous compose: gpg-pubkey
Previous test data: https://openqa.fedoraproject.org/tests/681316#downloads
Current test data: https://openqa.fedoraproject.org/tests/683994#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
Used mem changed from 180 MiB to 201 MiB
1 packages(s) added since previous compose: gpg-pubkey
Previous test data: https://openqa.fedoraproject.org/tests/681325#downloads
Current test data: https://openqa.fedoraproject.org/tests/684003#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
Used mem changed from 180 MiB to 201 MiB
1 packages(s) added since previous compose: gpg-pubkey
Previous test data: https://openqa.fedoraproject.org/tests/681327#downloads
Current test data: https://openqa.fedoraproject.org/tests/684005#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
Used mem changed from 161 MiB to 140 MiB
1 packages(s) added since previous compose: gpg-pubkey
System load changed from 0.44 to 0.31
Previous test data:

Re: Fedora 32/33 livedisks do not boot on M$ system(s)

2020-10-03 Thread Marius Schwarz 
Am 02.10.20 um 11:12 schrieb Petr Pisar:
> On Thu, Oct 01, 2020 at 11:07:28AM -0700, Samuel Sieb wrote:
>> On 10/1/20 5:52 AM, Marius Schwarz wrote:
 Is it possible to boot from the stick and then perform a grub-install
 with an old grub?

>>> This attempt failed too:
>>>
>>> #  grub2-install /dev/sda
>>> grub2-install: Fehler: /usr/lib/grub/x86_64-efi/modinfo.sh existiert
>>> nicht. Bitte geben Sie --target oder --directory an.
>>>
>>> and that file seems not to be part of any package. There is only one for
>>> "i386-pc".
>> You can't (and must not!) use grub2-install on an EFI system.
> Of course you have. How else would you get GRUB EFI executable onto the boot
> partition and register it into boot environments?
>
> But the correct invocation for EFI systems is different. You just use
> "grub2-install" without the disk device name.
If you do not state the devicename, how does grub choose the correct
drive? I don't want to overwrite the bootloader on the ssd.

by entering "grub2-install /dev/sdb" where sdb was the usb drive, grub2
removed the working boot config from .. you guessed it by now.. the ssd :(

The repair try, done by the docs.fp.orgbootloading-with-grub2 guide,
honestly said, it wants to install i386 on a clearly x64  system.


FYI: Not working without manual corrections

insmod lvm
insmod xfs
set root=(hd0,gpt3)
configfile /grub2/grub.cfg
linux /vmlinuz-5.8.10
initrd /initramfs-5.8.10
boot

Q: Why is configfile read, but not used if anything important is in it
i.e. the sysroot options passed to "linux" to find the decrypted luks
partition?

AFTER this: i managed to boot the system, by manually mounting the dm-0
device to /sysroot

BUT:

grub2-mkconfig -o /boot/grub2/grub.cfg

grub2-install --boot-directory=/boot /dev/nvm0n1

did not succeed in recreating a working boot environment, in fact, nothing 
changed. Still not presenting a grub menu, where grub2-mkconfig said, it 
created the menu. 
(i hate lying tools)

Q: What did anaconda different on the first installation of Fedora, to
make it work?

--> HELP needed <--


Lesson learned: once it's on a system, don't play with grub2-install.

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

Re: Self Introduction: Fabrice BAUZAC-STEHLY

2020-10-03 Thread Zbigniew Jędrzejewski-Szmek 
On Sat, Oct 03, 2020 at 09:22:52AM +0200, Fabrice BAUZAC-STEHLY wrote:
> Hello,
> 
> I wish to contribute, especially with packaging work.
> 
> I'm a 40-year-old programmer, GNU/Linux user since I'm 15, with
> knowledge about sysadmin, networking, Linux, C, Python, Perl...  And I
> like good technical documentation.  Recently I have started contributing
> some packaging work for Debian (python3-opentracing).  I'd like to
> continue, and not only for Debian but also for Fedora or EPEL8.

Hi Fabrice,

welcome to Fedora. Since you have some experience, you might want to start
by doing informal reviews of anything under
https://fedoraproject.org/PackageReviewStatus/reviewable.html. There's also
a number of SIGs concerned with more specific areas:
https://fedoraproject.org/wiki/Category:SIGs.

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-33-20201003.n.0 compose check report

2020-10-03 Thread Fedora compose checker 
Missing expected images:

Xfce raw-xz armhfp

Failed openQA tests: 4/181 (x86_64)

New failures (same test not failed in Fedora-33-20200929.n.0):

ID: 683936  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/683936
ID: 683991  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/683991

Old failures (same test failed in Fedora-33-20200929.n.0):

ID: 683876  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/683876
ID: 683887  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/683887

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

Old soft failures (same test soft failed in Fedora-33-20200929.n.0):

ID: 683858  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/683858
ID: 683871  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/683871
ID: 683891  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/683891
ID: 683894  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/683894
ID: 683908  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/683908
ID: 683920  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/683920
ID: 683921  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/683921
ID: 683942  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/683942
ID: 683945  Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/683945

Passed openQA tests: 168/181 (x86_64)

New passes (same test not passed in Fedora-33-20200929.n.0):

ID: 683812  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/683812
ID: 683831  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/683831

Installed system changes in test x86_64 Server-boot-iso install_default: 
2 packages(s) added since previous compose: python3-pexpect, 
python3-ptyprocess
Previous test data: https://openqa.fedoraproject.org/tests/680327#downloads
Current test data: https://openqa.fedoraproject.org/tests/683810#downloads

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
2 packages(s) added since previous compose: python3-pexpect, 
python3-ptyprocess
Previous test data: https://openqa.fedoraproject.org/tests/680328#downloads
Current test data: https://openqa.fedoraproject.org/tests/683811#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
Used swap changed from 24 MiB to 28 MiB
8 packages(s) removed since previous compose: libquvi, libquvi-scripts, 
lua-expat, lua-json, lua-lpeg, lua-socket, nautilus-sendto, python3-ordered-set
System load changed from 0.90 to 0.71
Previous test data: https://openqa.fedoraproject.org/tests/680372#downloads
Current test data: https://openqa.fedoraproject.org/tests/683855#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
8 packages(s) removed since previous compose: libquvi, libquvi-scripts, 
lua-expat, lua-json, lua-lpeg, lua-socket, nautilus-sendto, python3-ordered-set
Previous test data: https://openqa.fedoraproject.org/tests/680374#downloads
Current test data: https://openqa.fedoraproject.org/tests/683857#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Used swap changed from 13 MiB to 15 MiB
1 packages(s) removed since previous compose: python3-ordered-set
System load changed from 1.50 to 1.27
Previous test data: https://openqa.fedoraproject.org/tests/680391#downloads
Current test data: https://openqa.fedoraproject.org/tests/683874#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
Used swap changed from 22 MiB to 12 MiB
1 packages(s) removed since previous compose: python3-ordered-set
Average CPU usage changed from 10.06190476 to 28.4
Previous test data: https://openqa.fedoraproject.org/tests/680392#downloads
Current test data: https://openqa.fedoraproject.org/tests/683875#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
Used swap changed from 28 MiB to 13 MiB
Average CPU usage changed from 19.38571429 to 8.94285714
Previous test data: https://openqa.fedoraproject.org/tests/680408#downloads
Current test data: https://openqa.fedoraproject.org/tests/683891#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso

Fedora 33 compose report: 20201003.n.0 changes

2020-10-03 Thread Fedora Rawhide Report 
OLD: Fedora-33-20200929.n.0
NEW: Fedora-33-20201003.n.0

= SUMMARY =
Added images:4
Dropped images:  4
Added packages:  16
Dropped packages:0
Upgraded packages:   190
Downgraded packages: 1

Size of added packages:  25.28 MiB
Size of dropped packages:0 B
Size of upgraded packages:   7.74 GiB
Size of downgraded packages: 61.21 KiB

Size change of upgraded packages:   -10.66 MiB
Size change of downgraded packages: 1.24 KiB

= ADDED IMAGES =
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-33-20201003.n.0.iso
Image: Everything boot s390x
Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-33-20201003.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-33-20201003.n.0.iso
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-33-20201003.n.0.iso

= DROPPED IMAGES =
Image: Workstation raw-xz armhfp
Path: 
Workstation/armhfp/images/Fedora-Workstation-armhfp-33-20200929.n.0-sda.raw.xz
Image: Xfce raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Xfce-armhfp-33-20200929.n.0-sda.raw.xz
Image: LXQt raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXQt-armhfp-33-20200929.n.0-sda.raw.xz
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-33-20200929.n.0-sda.raw.xz

= ADDED PACKAGES =
Package: 3mux-1.0.1-1.fc33
Summary: Terminal multiplexer inspired by i3
RPMs:3mux golang-github-aaronjanse-3mux-devel
Size:8.74 MiB

Package: IP2Location-8.1.3-11.fc33
Summary: C library for mapping IP address to geolocation information
RPMs:IP2Location IP2Location-data-sample IP2Location-devel
Size:5.66 MiB

Package: ocaml-csexp-1.3.2-1.fc33
Summary: Parsing and printing of S-expressions in canonical form
RPMs:ocaml-csexp ocaml-csexp-devel
Size:771.37 KiB

Package: python-aioflo-0.4.1-2.fc33
Summary: Python library for Flo by Moen Smart Water Detectors
RPMs:python3-aioflo
Size:25.44 KiB

Package: python-aiounifi-23-1.fc33
Summary: Python library for communicating with Unifi Controller API
RPMs:python3-aiounifi
Size:35.11 KiB

Package: python-bidict-0.21.2-1.fc33
Summary: Bidirectional mapping library for Python
RPMs:python-bidict-doc python3-bidict
Size:484.43 KiB

Package: python-connect-box-0.2.8-1.fc33
Summary: Python client for interacting with Compal CH7465LG devices
RPMs:python3-connect-box
Size:25.13 KiB

Package: python-epson-projector-0.2.3-1.fc33
Summary: Python support for Epson projectors
RPMs:python3-epson-projector
Size:24.59 KiB

Package: python-pyduofern-0.34.1-1.fc33
Summary: Library for controlling Rademacher DuoFern actors
RPMs:python3-pyduofern
Size:144.19 KiB

Package: python-pyopenuv-2.0.0-1.fc33
Summary: Python API data from openuv.io
RPMs:python3-pyopenuv
Size:16.60 KiB

Package: python-requre-0.4.0-1.fc33
Summary: Python library what allows re/store output of various objects for 
testing
RPMs:python3-requre
Size:73.71 KiB

Package: python-smbprotocol-1.1.0-1.fc33
Summary: Interact with a server using the SMB 2/3 Protocol
RPMs:python3-smbprotocol
Size:170.36 KiB

Package: python-thingserver-0.2.1-1.fc33
Summary: HTTP Web Thing implementation
RPMs:python3-thingserver
Size:45.19 KiB

Package: python-typish-1.7.0-2.fc33
Summary: Python library for additional control over types
RPMs:python3-typish
Size:47.60 KiB

Package: rust-zincati-0.0.13-1.fc33
Summary: Update agent for Fedora CoreOS
RPMs:zincati
Size:8.96 MiB

Package: toot-0.27.0-2.fc33
Summary: A CLI and TUI tool for interacting with Mastodon
RPMs:toot
Size:106.89 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  Carla-1:2.2.0-1.fc33
Old package:  Carla-1:2.2.0-0.2.rc1.fc33
Summary:  Audio plugin host
RPMs: Carla Carla-devel Carla-vst lv2-carla
Size: 56.90 MiB
Size change:  2.18 MiB
Changelog:
  * Sun Sep 27 2020 Martin Gansser  - 1:2.2.0-1
  - Update to 2.2.0


Package:  GtkAda3-2020-1.fc33
Old package:  GtkAda3-2017-12.fc33
Summary:  GTKada 3, an Ada binding to GTK+ 3
RPMs: GtkAda3 GtkAda3-devel GtkAda3-doc GtkAda3-gl
Size: 34.75 MiB
Size change:  893.35 KiB
Changelog:
  * Fri Sep 25 2020 Bj??rn Persson  - 2020-1
  - Upgraded to the 2020 release.


Package:  R-tufte-0.7-1.fc33
Old package:  R-tufte-0.6-3.fc33
Summary:  Tufte's Styles for R Markdown Documents
RPMs: R-tufte
Size: 220.32 KiB
Size change:  162 B
Changelog:
  * Sat Sep 26 2020 Elliott Sales de Andrade  - 0.7-1
  - Update to latest version (#1882783)


Package:  Singular-4.1.1p3-20.fc33
Old package:  Singular-4.1.1p3-19.fc33
Summary:  Computer Algebra System for polynomial computations
RPMs: Singular Singular-devel Singular-doc Singular-emacs 
Singular-libpolys Singular-libpolys-devel Singular-libs Singular-polymake 
Singular-surfex factory factory-devel factory-gftables
Size: 107.69 MiB
Size change

Self Introduction: Fabrice BAUZAC-STEHLY

2020-10-03 Thread Fabrice BAUZAC-STEHLY 
Hello,

I wish to contribute, especially with packaging work.

I'm a 40-year-old programmer, GNU/Linux user since I'm 15, with
knowledge about sysadmin, networking, Linux, C, Python, Perl...  And I
like good technical documentation.  Recently I have started contributing
some packaging work for Debian (python3-opentracing).  I'd like to
continue, and not only for Debian but also for Fedora or EPEL8.

Thanks.

Best regards

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

[Test-Announce] Fedora 33 Branched 20201003.n.0 nightly compose nominated for testing

2020-10-03 Thread rawhide 
Announcing the creation of a new nightly release validation test event
for Fedora 33 Branched 20201003.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 1.3: anaconda-33.25.2-4.fc33.src, 20201003.n.0: 
anaconda-33.25.4-1.fc33.src
pykickstart - 1.3: pykickstart-3.27-2.fc33.src, 20201003.n.0: 
pykickstart-3.29-1.fc33.src
pungi - 1.3: pungi-4.2.4-1.fc33.src, 20201003.n.0: pungi-4.2.5-1.fc33.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/33

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

https://fedoraproject.org/wiki/Test_Results:Fedora_33_Branched_20201003.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_33_Branched_20201003.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Branched_20201003.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Branched_20201003.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Branched_20201003.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Branched_20201003.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_33_Branched_20201003.n.0_Security_Lab

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

Re: %set_build_flags problem in rpm spec file

2020-10-03 Thread Miro Hrončok 

On 03. 10. 20 5:04, Ruki Wang wrote:

Hi, every one.

I am making rpm spec and doing tests on copr.

But on opensuse-leap-15.1-*, %set_build_flags still causes some problems.


+ %set_build_flags
/var/tmp/rpm-tmp.9RYL8i: line 32: fg: no job control
error: Bad exit status from /var/tmp/rpm-tmp.9RYL8i (%build)
     Bad exit status from /var/tmp/rpm-tmp.9RYL8i (%build)


Links:

https://copr.fedorainfracloud.org/coprs/waruqi/xmake/build/1693007/
https://download.copr.fedorainfracloud.org/results/waruqi/xmake/opensuse-leap-15.2-x86_64/01693007-xmake/builder-live.log.gz 



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

Does anyone know the reason for this? Thanks!



Yes. The reason is openSUSE and Fedora are different. and they don't have our 
macro.

A quick "make it build" action would be to add ?:

%?set_build_flags

However, the openSUSE build might not have the proper flags.

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