Problem with s390x koji builder

2021-01-20 Thread Vascom
What's wrong with s390x koji builder?

I always see this error:

Child return code was: -11
EXCEPTION: [Error()]
Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/mockbuild/trace_decorator.py",
line 93, in trace
result = func(*args, **kw)
  File "/usr/lib/python3.9/site-packages/mockbuild/util.py", line 600,
in do_with_status
raise exception.Error("Command failed: \n # %s\n%s" % (command,
output), child.returncode)
mockbuild.exception.Error: Command failed:

Other arches are OK.

https://koji.fedoraproject.org/koji/taskinfo?taskID=60085705

Need to fix it.

--
Best regards,
Vasiliy Glazov
___
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: Problem with s390x koji builder

2021-01-20 Thread Juan Orti Alcaine
I also got the same error:

https://koji.fedoraproject.org/koji/taskinfo?taskID=60083125

El mié, 20 ene 2021 a las 9:35, Vascom () escribió:

> What's wrong with s390x koji builder?
>
> I always see this error:
>
> Child return code was: -11
> EXCEPTION: [Error()]
> Traceback (most recent call last):
>   File "/usr/lib/python3.9/site-packages/mockbuild/trace_decorator.py",
> line 93, in trace
> result = func(*args, **kw)
>   File "/usr/lib/python3.9/site-packages/mockbuild/util.py", line 600,
> in do_with_status
> raise exception.Error("Command failed: \n # %s\n%s" % (command,
> output), child.returncode)
> mockbuild.exception.Error: Command failed:
>
> Other arches are OK.
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=60085705
>
> Need to fix it.
>
> --
> Best regards,
> Vasiliy Glazov
> ___
> 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


merging packages - is fedora fedora guideline right?

2021-01-20 Thread Petr Stodulka

Hi guys,
I am confused about the official guidelines for merging of packages in Fedora.
From my POV, when I merge some packages and the functionality is preserved,
the Obsoletes and Provides should be set and kept for 2 release cycles.
So there is not problem with dependencies, etc. However, I've just realized
that regarding guidelines only Obsoletes should be set.

Was it changed and is it really correct? From that point, I already have
a reported broken deps for git-remote-hg because of the missing provides
after the merge of some packages - I will fix it, but I am curious whether
this is really expected. Can you guys put a light on that? Or the guideline
needs to be fixed?

Thank you!

[0] 
https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages

--
Petr Stodulka
OS & Application Modernization
IRC nicks: pstodulk, skytak
Senior Software Engineer
Red Hat Czech s.r.o.
___
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: merging packages - is fedora fedora guideline right?

2021-01-20 Thread Elliott Sales de Andrade
On Wed, 20 Jan 2021 at 03:48, Petr Stodulka  wrote:
>
> Hi guys,
> I am confused about the official guidelines for merging of packages in Fedora.
>  From my POV, when I merge some packages and the functionality is preserved,
> the Obsoletes and Provides should be set and kept for 2 release cycles.
> So there is not problem with dependencies, etc. However, I've just realized
> that regarding guidelines only Obsoletes should be set.
>

That link is not to the current Guidelines. The Guidelines section on
renames is here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages
and it says to add both, *unless* it is not a sufficiently compatible
replacement.

> Was it changed and is it really correct? From that point, I already have
> a reported broken deps for git-remote-hg because of the missing provides
> after the merge of some packages - I will fix it, but I am curious whether
> this is really expected. Can you guys put a light on that? Or the guideline
> needs to be fixed?
>
> Thank you!
>
> [0] 
> https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages
>
> --
> Petr Stodulka
> OS & Application Modernization
> IRC nicks: pstodulk, skytak
> Senior Software Engineer
> Red Hat Czech s.r.o.

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


Re: merging packages - is fedora fedora guideline right?

2021-01-20 Thread Petr Stodulka

Thank you Elliot! Now it's clear.

On 20. 01. 21 10:02, Elliott Sales de Andrade wrote:

On Wed, 20 Jan 2021 at 03:48, Petr Stodulka  wrote:


Hi guys,
I am confused about the official guidelines for merging of packages in Fedora.
  From my POV, when I merge some packages and the functionality is preserved,
the Obsoletes and Provides should be set and kept for 2 release cycles.
So there is not problem with dependencies, etc. However, I've just realized
that regarding guidelines only Obsoletes should be set.



That link is not to the current Guidelines. The Guidelines section on
renames is here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages
and it says to add both, *unless* it is not a sufficiently compatible
replacement.


Was it changed and is it really correct? From that point, I already have
a reported broken deps for git-remote-hg because of the missing provides
after the merge of some packages - I will fix it, but I am curious whether
this is really expected. Can you guys put a light on that? Or the guideline
needs to be fixed?

Thank you!

[0] 
https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages

--
Petr Stodulka
OS & Application Modernization
IRC nicks: pstodulk, skytak
Senior Software Engineer
Red Hat Czech s.r.o.




--
Petr Stodulka
OS & Application Modernization
IRC nicks: pstodulk, skytak
Senior Software Engineer
Red Hat Czech s.r.o.
___
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


/usr/include/c++/11/string_view:98:21: error: static assertion failed

2021-01-20 Thread Martin Gansser
Hi,

when compiling cxxtools-3.0 on rawhide it fails with the following error 
messages [2]:

settingswriter.cpp:42:26:   required from here
/usr/include/c++/11/string_view:98:21: error: static assertion failed
   98 |   static_assert(is_trivial_v<_CharT> && 
is_standard_layout_v<_CharT>);
  | ^~~~
/usr/include/c++/11/string_view:98:21: note: 
'std::is_trivial_v' evaluates to false
make[2]: *** [Makefile:920: settingswriter.lo] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory '/builddir/build/BUILD/cxxtools-3.0/src'
make[1]: *** [Makefile:600: all] Error 2
make[1]: Leaving directory '/builddir/build/BUILD/cxxtools-3.0/src'
make: *** [Makefile:539: all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.TZ5CHP (%build)
RPM build errors:

[1] https://martinkg.fedorapeople.org/ErrorReports/cxxtools-3.0-1.fc33.src.rpm
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=60083999

How can i solve it ?

Regards
Martin
___
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: Obsoletes/Provides question

2021-01-20 Thread Richard W.M. Jones
On Wed, Jan 20, 2021 at 03:23:04AM +0100, Kevin Kofler via devel wrote:
> Daniel P. Berrangé wrote:
> 
> > On Tue, Jan 19, 2021 at 03:18:41PM +, Richard W.M. Jones wrote:
> >> On Tue, Jan 19, 2021 at 04:12:59PM +0100, Miro Hrončok wrote:
> >> > On 19. 01. 21 16:06, Richard W.M. Jones wrote:
> >> > >(2) Or adding:
> >> > >
> >> > >%package tar-filter
> >> > >Obsoletes: %{name}-tar-plugin <= %{version}-%{release}
> >> > >
> >> > >which says that it obsoletes but doesn't provide a replacement.  Note
> >> > >however I'm not sure if this will work, because they won't have
> >> > >nbdkit-tar-filter installed before the upgrade (it never existed in
> >> > >F32), so will the Obsoletes ever be "seen" by dnf?
> >> > 
> >> > Yes, it will be seen and respected.
> >> > 
> >> > Note that it in most cases, it is recommended to obsolete a specific
> >> > version-release rather than %{version}-%{release}.
> >> 
> >> To be clear, I would find the last released nbdkit-tar-plugin version
> >> in F32 (https://koji.fedoraproject.org/koji/buildinfo?buildID=1605446)
> >> and write this?
> >> 
> >> %package tar-filter
> >> Obsoletes: %{name}-tar-plugin = 1.20.7-1.fc32
> > 
> > Yes, but use <= here, rather than =, as users might be updating from an
> > older install.
> > 
> > Arguably can leave off the .fc32 part too IMHO.
> 
> But then, <= 1.20.7-1 will do the wrong thing, which is why Miro recommends 
> (and I agree with him) to use < 1.20.7-2 instead.

This is what I added (to both Rawhide and F33):

https://src.fedoraproject.org/rpms/nbdkit/c/f0f5e8b3ec84ff88900395d908d654770d2efe55?branch=master

where 1.23.9-2 was the last Fedora release that had the obsolete
nbdkit-tar-plugin package.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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: Problem with s390x koji builder

2021-01-20 Thread Florian Weimer
* Juan Orti Alcaine:

> I also got the same error:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=60083125

I can reproduce it locally.  It's a crash in rpmbuild:

Thread 1 "rpmbuild" received signal SIGSEGV, Segmentation fault.
0x03fffde89e60 in packageBinaries._omp_fn.0 () at pack.c:780
780 if (rc)
(gdb) bt
#0  0x03fffde89e60 in packageBinaries._omp_fn.0 () at pack.c:780
#1  0x03fffca94806 in GOMP_parallel (
fn=0x3fffde89d80 , data=0x3fff478, 
num_threads=2, flags=) at ../../../libgomp/parallel.c:178
#2  0x03fffde953fa in packageBinaries (cheating=0, cookie=0x0, 
spec=0x2aa00065570) at pack.c:765
#3  buildSpec (ts=, buildArgs=, 
spec=0x2aa00065570, what=) at build.c:411
#4  0x03fffde98074 in rpmSpecBuild (ts=, 
spec=, buildArgs=) at build.c:452
#5  0x02aa3e74 in buildForTarget (ts=0x2aa00069a80, 
arg=, ba=0x2aa7990 ) at rpmbuild.c:500
#6  0x02aa409a in build (ts=0x2aa00069a80, 
arg=0x3fffe3a "/builddir/build/SPECS/compsize.spec", rcfile=0x0, 
ba=0x2aa7990 ) at rpmbuild.c:552
#7  0x02aa2f84 in main (argc=, argv=)
at rpmbuild.c:690
(gdb) print rc
No symbol "rc" in current context.

As you can see, something is broken with debugging information.


(gdb) disassemble 
Dump of assembler code for function packageBinaries._omp_fn.0:
   0x03fffde89d80 <+0>: stmg%r6,%r15,48(%r15)
   0x03fffde89d86 <+6>: ear %r1,%a0
   0x03fffde89d8a <+10>:lgr %r14,%r15
   0x03fffde89d8e <+14>:lay %r15,-280(%r15)
   0x03fffde89d94 <+20>:aghi%r14,-24
   0x03fffde89d98 <+24>:std %f8,0(%r14)
   0x03fffde89d9c <+28>:std %f10,8(%r14)
   0x03fffde89da0 <+32>:std %f14,16(%r14)
   0x03fffde89da4 <+36>:sllg%r1,%r1,32
   0x03fffde89daa <+42>:ear %r1,%a1
   0x03fffde89dae <+46>:l   %r11,32(%r2)
   0x03fffde89db2 <+50>:stg %r1,200(%r15)
   0x03fffde89db8 <+56>:lg  %r10,16(%r2)
   0x03fffde89dbe <+62>:l   %r13,24(%r2)
   0x03fffde89dc2 <+66>:mvc 248(8,%r15),40(%r1)
   0x03fffde89dc8 <+72>:ld  %f8,8(%r2)
   0x03fffde89dcc <+76>:ld  %f10,0(%r2)
   0x03fffde89dd0 <+80>:lgr %r8,%r2
   0x03fffde89dd4 <+84>:brasl   %r14,0x3fffde87530 

   0x03fffde89dda <+90>:cije%r2,0,0x3fffde89e76 

   0x03fffde89de0 <+96>:cijnh   %r11,0,0x3fffde89e76 

   0x03fffde89de6 <+102>:   stg %r8,192(%r15)
   0x03fffde89dec <+108>:   la  %r7,208(%r15)
   0x03fffde89df0 <+112>:   la  %r1,28(%r8)
   0x03fffde89df4 <+116>:   lgr %r8,%r7
   0x03fffde89df8 <+120>:   lgdr%r7,%f8
   0x03fffde89dfc <+124>:   ldgr%f14,%r1
   0x03fffde89e00 <+128>:   lhi %r9,0
   0x03fffde89e04 <+132>:   lg  %r1,0(%r10)
   0x03fffde89e0a <+138>:   std %f10,208(%r15)
   0x03fffde89e0e <+142>:   std %f14,224(%r15)
   0x03fffde89e12 <+146>:   stg %r1,232(%r15)
   0x03fffde89e18 <+152>:   st  %r13,240(%r15)
   0x03fffde89e1c <+156>:   stg %r7,216(%r15)
   0x03fffde89e22 <+162>:   lgfr%r1,%r9
   0x03fffde89e26 <+166>:   stg %r1,184(%r15)
   0x03fffde89e2c <+172>:   mvghi   176(%r15),0
   0x03fffde89e32 <+178>:   mvghi   168(%r15),17
   0x03fffde89e38 <+184>:   mvghi   160(%r15),1
   0x03fffde89e3e <+190>:   lgr %r3,%r8
   0x03fffde89e42 <+194>:   lghi%r6,8
   0x03fffde89e46 <+198>:   lghi%r5,40
   0x03fffde89e4a <+202>:   lghi%r4,0
   0x03fffde89e4e <+206>:   larl%r2,0x3fffde910c0 

   0x03fffde89e54 <+212>:   brasl   %r14,0x3fffde87c70 
   0x03fffde89e5a <+218>:   lg  %r1,192(%r15)
=> 0x03fffde89e60 <+224>:   lt  %r1,28(%r1)
   0x03fffde89e66 <+230>:   jne 0x3fffde89e76 

   0x03fffde89e6a <+234>:   ahi %r9,1
   0x03fffde89e6e <+238>:   aghi%r10,8
   0x03fffde89e72 <+242>:   brct%r11,0x3fffde89e04 

   0x03fffde89e76 <+246>:   lg  %r1,200(%r15)
   0x03fffde89e7c <+252>:   clc 248(8,%r15),40(%r1)
   0x03fffde89e82 <+258>:   jne 0x3fffde89e9e 

   0x03fffde89e86 <+262>:   ld  %f8,256(%r15)
   0x03fffde89e8a <+266>:   ld  %f10,264(%r15)
   0x03fffde89e8e <+270>:   ld  %f14,272(%r15)
   0x03fffde89e92 <+274>:   lmg %r6,%r15,328(%r15)
   0x03fffde89e98 <+280>:   jg  0x3fffde895f0 
   0x03fffde89e9e <+286>:   brasl   %r14,0x3fffde88810 
<__stack_chk_fail@plt>
(gdb) print/x $r1
$1 = 0x0

So it's a null pointer dereference.


745  * (largest first) to help achieve an optimal load distribution.
746  */
747 rpmRC packageBinaries(rpmSpec spec, const char *cookie, int cheating)
748 {
749 rpmRC rc = RPMRC_OK;
750 Package pkg;
751 Package *tasks;
752 int npkgs = 0;
753
754 for (pkg = spec->packages; pkg != NULL; pkg = pkg

/usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

2021-01-20 Thread Miro Hrončok

Many Pythons started to fail in Fedora on x86_64 and aarch64 with:

+ /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9d-x86_64-linux-gnu/st5slPIv: 
symbol `.gnu.debuglto_.debug_line_str' required but not present
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9d-x86_64-linux-gnu/st5slPIv: 
no symbols
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9-x86_64-linux-gnu/stgbbuCz: 
symbol `.gnu.debuglto_.debug_line_str' required but not present
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9-x86_64-linux-gnu/stgbbuCz: 
no symbols


+ /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9d-aarch64-linux-gnu/stOvyE1u: 
symbol `.gnu.debuglto_.debug_line_str' required but not present
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9d-aarch64-linux-gnu/stOvyE1u: 
no symbols
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9-aarch64-linux-gnu/st2BV5jT: 
symbol `.gnu.debuglto_.debug_line_str' required but not present
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9-aarch64-linux-gnu/st2BV5jT: 
no symbols


Right before the mass rebuild. Is this known?

https://koschei.fedoraproject.org/affected-by/redhat-rpm-config?epoch1=0&version1=178&release1=1.fc34&epoch2=0&version2=180&release2=1.fc34&collection=f34
https://koschei.fedoraproject.org/affected-by/gcc-c++?epoch1=0&version1=11.0.0&release1=0.14.fc34&epoch2=0&version2=11.0.0&release2=0.15.fc34&collection=f34

--
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: Problem with s390x koji builder

2021-01-20 Thread Jakub Jelinek
On Wed, Jan 20, 2021 at 11:18:16AM +0100, Florian Weimer wrote:
> So it's a null pointer dereference.
> 
> 
> 745  * (largest first) to help achieve an optimal load distribution.
> 746  */
> 747 rpmRC packageBinaries(rpmSpec spec, const char *cookie, int cheating)
> 748 {
> 749 rpmRC rc = RPMRC_OK;
> 750 Package pkg;
> 751 Package *tasks;
> 752 int npkgs = 0;
> 753
> 754 for (pkg = spec->packages; pkg != NULL; pkg = pkg->next)
> 755 npkgs++;
> 756 tasks = xcalloc(npkgs, sizeof(Package));
> 757
> 758 pkg = spec->packages;
> 759 for (int i = 0; i < npkgs; i++) {
> 760 tasks[i] = pkg;
> 761 pkg = pkg->next;
> 762 }
> 763 qsort(tasks, npkgs, sizeof(Package), compareBinaries);
> 764
> 765 #pragma omp parallel
> 766 #pragma omp single
> 767 for (int i = 0; i < npkgs; i++) {
> 768 Package pkg = tasks[i];
> 769 #pragma omp task untied priority(i)
> 770 {
> 771 pkg->rc = packageBinary(spec, pkg, cookie, cheating, 
> &pkg->filename);
> 772 rpmlog(RPMLOG_DEBUG,
> 773 _("Finished binary package job, result %d, filename 
> %s\n"),
> 774 pkg->rc, pkg->filename);
> 775 if (pkg->rc) {
> 776 #pragma omp critical
> 777 rc = pkg->rc;
> 778 }
> 779 } /* omp task */
> 780 if (rc)
> 781 break;
> 782 }

It is definitely not valid OpenMP, because it is racy (that if (rc) part
with tasks writing that var).
It would need to use atomic accesses to rc, like:
#pragma omp atomic write
rc = pkg->rc;
instead of #pragma omp critical and
rpmRC testrc;
#pragma omp atomic read
testrc = rc;
if (testrc)
break;
But, that shouldn't be the reason why it crashed.

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


Re: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

2021-01-20 Thread Jonathan Wakely

On 20/01/21 11:31 +0100, Miro Hrončok wrote:

Many Pythons started to fail in Fedora on x86_64 and aarch64 with:

+ /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip
/usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9d-x86_64-linux-gnu/st5slPIv: 
symbol `.gnu.debuglto_.debug_line_str' required but not present
/usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9d-x86_64-linux-gnu/st5slPIv: 
no symbols
/usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9-x86_64-linux-gnu/stgbbuCz: 
symbol `.gnu.debuglto_.debug_line_str' required but not present
/usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9-x86_64-linux-gnu/stgbbuCz: 
no symbols


+ /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip
/usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9d-aarch64-linux-gnu/stOvyE1u: 
symbol `.gnu.debuglto_.debug_line_str' required but not present
/usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9d-aarch64-linux-gnu/stOvyE1u: 
no symbols
/usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9-aarch64-linux-gnu/st2BV5jT: 
symbol `.gnu.debuglto_.debug_line_str' required but not present
/usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9-aarch64-linux-gnu/st2BV5jT: 
no symbols


Right before the mass rebuild. Is this known?


It seems to affect Boost builds too.
___
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: Problem with s390x koji builder

2021-01-20 Thread Petr Pisar
Forwarded to .

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


Re: /usr/include/c++/11/string_view:98:21: error: static assertion failed

2021-01-20 Thread Jonathan Wakely

On 20/01/21 09:51 -, Martin Gansser wrote:

Hi,

when compiling cxxtools-3.0 on rawhide it fails with the following error 
messages [2]:

settingswriter.cpp:42:26:   required from here
/usr/include/c++/11/string_view:98:21: error: static assertion failed
  98 |   static_assert(is_trivial_v<_CharT> && 
is_standard_layout_v<_CharT>);
 | ^~~~
/usr/include/c++/11/string_view:98:21: note: 
'std::is_trivial_v' evaluates to false
make[2]: *** [Makefile:920: settingswriter.lo] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory '/builddir/build/BUILD/cxxtools-3.0/src'
make[1]: *** [Makefile:600: all] Error 2
make[1]: Leaving directory '/builddir/build/BUILD/cxxtools-3.0/src'
make: *** [Makefile:539: all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.TZ5CHP (%build)
RPM build errors:

[1] https://martinkg.fedorapeople.org/ErrorReports/cxxtools-3.0-1.fc33.src.rpm
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=60083999

How can i solve it ?


The code is invalid. std::string and std::string_view are for
manipulating sequences of types which are trivial and standard layout.
The cxxtools::Char type is non-trivial, probably because it has a
user-provided copy constructor or destructor. You can't use a
std::string_view of such types.

The code needs to be fixed.

___
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


Crash, maybe, in packaging scripts on Koji/s390

2021-01-20 Thread Richard W.M. Jones

https://kojipkgs.fedoraproject.org//work/tasks/9457/60089457/build.log
(from https://koji.fedoraproject.org/koji/taskinfo?taskID=60089433)

ends with ...

Checking for unpackaged file(s): /usr/lib/rpm/check-files 
/builddir/build/BUILDROOT/ocaml-extlib-1.7.8-1.fc34.s390x
Child return code was: -11
EXCEPTION: [Error()]
Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/mockbuild/trace_decorator.py", line 
93, in trace
result = func(*args, **kw)
  File "/usr/lib/python3.9/site-packages/mockbuild/util.py", line 600, in 
do_with_status
raise exception.Error("Command failed: \n # %s\n%s" % (command, output), 
child.returncode)
mockbuild.exception.Error: Command failed: 
 # bash --login -c /usr/bin/rpmbuild -bb --target s390x --nodeps 
/builddir/build/SPECS/ocaml-extlib.spec

I kicked off another build to see if this is reproducible.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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: Crash, maybe, in packaging scripts on Koji/s390

2021-01-20 Thread Richard W.M. Jones
On Wed, Jan 20, 2021 at 10:52:35AM +, Richard W.M. Jones wrote:
> 
> https://kojipkgs.fedoraproject.org//work/tasks/9457/60089457/build.log
> (from https://koji.fedoraproject.org/koji/taskinfo?taskID=60089433)
> 
> ends with ...
> 
> Checking for unpackaged file(s): /usr/lib/rpm/check-files 
> /builddir/build/BUILDROOT/ocaml-extlib-1.7.8-1.fc34.s390x
> Child return code was: -11
> EXCEPTION: [Error()]
> Traceback (most recent call last):
>   File "/usr/lib/python3.9/site-packages/mockbuild/trace_decorator.py", line 
> 93, in trace
> result = func(*args, **kw)
>   File "/usr/lib/python3.9/site-packages/mockbuild/util.py", line 600, in 
> do_with_status
> raise exception.Error("Command failed: \n # %s\n%s" % (command, output), 
> child.returncode)
> mockbuild.exception.Error: Command failed: 
>  # bash --login -c /usr/bin/rpmbuild -bb --target s390x --nodeps 
> /builddir/build/SPECS/ocaml-extlib.spec
> 
> I kicked off another build to see if this is reproducible.

Oh sorry, I see there is already a thread this morning about this:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XQWO72AZ7MKVC3CSICKKYF77EHNUVJ6U/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: /usr/include/c++/11/string_view:98:21: error: static assertion failed

2021-01-20 Thread Jonathan Wakely

On 20/01/21 10:47 +, Jonathan Wakely wrote:

On 20/01/21 09:51 -, Martin Gansser wrote:

Hi,

when compiling cxxtools-3.0 on rawhide it fails with the following error 
messages [2]:

settingswriter.cpp:42:26:   required from here
/usr/include/c++/11/string_view:98:21: error: static assertion failed
 98 |   static_assert(is_trivial_v<_CharT> && is_standard_layout_v<_CharT>);
| ^~~~
/usr/include/c++/11/string_view:98:21: note: 
'std::is_trivial_v' evaluates to false
make[2]: *** [Makefile:920: settingswriter.lo] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory '/builddir/build/BUILD/cxxtools-3.0/src'
make[1]: *** [Makefile:600: all] Error 2
make[1]: Leaving directory '/builddir/build/BUILD/cxxtools-3.0/src'
make: *** [Makefile:539: all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.TZ5CHP (%build)
RPM build errors:

[1] https://martinkg.fedorapeople.org/ErrorReports/cxxtools-3.0-1.fc33.src.rpm
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=60083999

How can i solve it ?


The code is invalid. std::string and std::string_view are for
manipulating sequences of types which are trivial and standard layout.
The cxxtools::Char type is non-trivial, probably because it has a
user-provided copy constructor or destructor. You can't use a
std::string_view of such types.


It's non-trivial because it has a non-trivial default constructor:

//! Constructs a character with a value of 0.
Char()
: _value(0)
{}



The code needs to be fixed.



___
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: Problem with s390x koji builder

2021-01-20 Thread Florian Weimer
* Jakub Jelinek:

> It is definitely not valid OpenMP, because it is racy (that if (rc) part
> with tasks writing that var).
> It would need to use atomic accesses to rc, like:
>   #pragma omp atomic write
>   rc = pkg->rc;
> instead of #pragma omp critical and
>   rpmRC testrc;
>   #pragma omp atomic read
>   testrc = rc;
>   if (testrc)
>   break;
> But, that shouldn't be the reason why it crashed.

Is there anything I can do to help to debug this?

Debuginfo quality around is very poor, for example I can't see if the
value of npkgs is correct at the point where packageBinaries calls
GOMP_parallel.

Is there a way to get the type of the struct that contains the per-task
data?

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


Re: /usr/include/c++/11/string_view:98:21: error: static assertion failed

2021-01-20 Thread Martin Gansser
ok, i think i will contac upstream to fix it.

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


Re: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

2021-01-20 Thread Miro Hrončok

On 20. 01. 21 11:31, Miro Hrončok wrote:

Many Pythons started to fail in Fedora on x86_64 and aarch64 with:

+ /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9d-x86_64-linux-gnu/st5slPIv: 
symbol `.gnu.debuglto_.debug_line_str' required but not present
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9d-x86_64-linux-gnu/st5slPIv: 
no symbols
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9-x86_64-linux-gnu/stgbbuCz: 
symbol `.gnu.debuglto_.debug_line_str' required but not present
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9-x86_64-linux-gnu/stgbbuCz: 
no symbols


+ /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9d-aarch64-linux-gnu/stOvyE1u: 
symbol `.gnu.debuglto_.debug_line_str' required but not present
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9d-aarch64-linux-gnu/stOvyE1u: 
no symbols
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9-aarch64-linux-gnu/st2BV5jT: 
symbol `.gnu.debuglto_.debug_line_str' required but not present
/usr/bin/strip: 
/builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9-aarch64-linux-gnu/st2BV5jT: 
no symbols


Right before the mass rebuild. Is this known?

https://koschei.fedoraproject.org/affected-by/redhat-rpm-config?epoch1=0&version1=178&release1=1.fc34&epoch2=0&version2=180&release2=1.fc34&collection=f34 

https://koschei.fedoraproject.org/affected-by/gcc-c++?epoch1=0&version1=11.0.0&release1=0.14.fc34&epoch2=0&version2=11.0.0&release2=0.15.fc34&collection=f34 


https://gcc.gnu.org/PR98765

--
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: List of long term FTBFS packages to be retired in February

2021-01-20 Thread Chihurumnaya Ibiam
I'd like sugar-view-slides and sugar-visualmatch to be exempted as I'm
working on
both.

-- 

Ibiam Chihurumnaya
ibiamchihurumn...@gmail.com



On Mon, Dec 28, 2020 at 9:57 PM Miro Hrončok  wrote:

> Dear maintainers.
>
> Based on the current fail to build from source policy, the following
> packages
> will be retired from Fedora 34 approximately one week before branching
> (February
> 2021).
>
> Policy:
>
> https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
>
> Note that some listed packages are orphaned and hence may be retired even
> sooner.
>
> The packages in rawhide were not successfully built at least since Fedora
> 32.
>
> This report is based on dist tags.
>
> Packages collected via:
>
> https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb
>
> If you see a package that was built, please let me know.
> If you see a package that should be exempted from the process, please let
> me
> know and we can work together to get a FESCo approval for that.
>
> If you see a package that can be rebuilt, please do so.
>
>Package  (co)maintainers
> Latest build
>
> ===
> VirtualGL   gsgatlin   Fedora
> 31
> boo elsupergomez, orphan, tpokorra Fedora
> 31
> gmpcorphan Fedora
> 31
> jboss-servlet-2.5-api   dmoluguw, orphan   Fedora
> 31
> js-html5shivorphan Fedora
> 31
> js-respond  orphan Fedora
> 31
> nodejs-info-symbol  orphan Fedora
> 31
> nodejs-interpretnodejs-sig, orphan Fedora
> 31
> nodejs-net-browserify-alt   orphan Fedora
> 31
> nodejs-win-spawnnodejs-sig, orphan Fedora
> 31
> rubygem-net-ssh-multi   maxamillion, orphan, tdawson   Fedora
> 31
> sugar-flipstickscallkalpa, chimosky, pbrobinson,   Fedora
> 31
>   tuxbrewr
> sugar-getiabookscallkalpa, chimosky, pbrobinson,   Fedora
> 31
>   tuxbrewr
> sugar-infoslicercallkalpa, chimosky, pbrobinson,   Fedora
> 31
>   tuxbrewr
> sugar-labyrinth callkalpa, chimosky, pbrobinsonFedora
> 31
> sugar-ruler callkalpa, chimoskyFedora
> 31
> sugar-starchart callkalpa, chimosky, orphanFedora
> 31
> sugar-view-slides   callkalpa, chimosky, pbrobinson,   Fedora
> 31
>   tuxbrewr
> sugar-visualmatch   chimosky, orphan   Fedora
> 31
> sugar-yupanacallkalpa, chimosky, orphanFedora
> 31
>
>
> The following packages require above mentioned packages:
>
> Depending on: js-html5shiv (1)
> copr-frontend (maintained by: clime, copr-sig, dturecek, frostyx,
> msuchy, praiskup)
> copr-frontend-1.171-1.fc34.noarch requires js-html5shiv
>
> Depending on: nodejs-info-symbol (2)
> nodejs-log-utils (maintained by: orphan)
> nodejs-log-utils-0.2.1-6.fc32.noarch requires
> npm(info-symbol)
>
> nodejs-time-diff (maintained by: orphan)
> nodejs-time-diff-0.3.1-7.fc32.src requires npm(info-symbol)
>
> Depending on: nodejs-interpret (1)
> nodejs-shelljs (maintained by: fab, nodejs-sig, patches)
> nodejs-shelljs-0.8.4-2.fc33.noarch requires npm(interpret)
>
>
> Affected (co)maintainers (directly and indirectly):
> callkalpa: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks,
> sugar-view-slides, sugar-infoslicer, sugar-starchart, sugar-getiabooks
> chimosky: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks,
> sugar-view-slides, sugar-visualmatch, sugar-infoslicer, sugar-starchart,
> sugar-getiabooks
> clime: js-html5shiv
> copr-sig: js-html5shiv
> dmoluguw: jboss-servlet-2.5-api
> dturecek: js-html5shiv
> elsupergomez: boo
> fab: nodejs-interpret
> frostyx: js-html5shiv
> gsgatlin: VirtualGL
> maxamillion: rubygem-net-ssh-multi
> msuchy: js-html5shiv
> nodejs-sig: nodejs-win-spawn, nodejs-interpret
> patches: nodejs-interpret
> pbrobinson: sugar-labyrinth, sugar-flipsticks, sugar-view-slides,
> sugar-infoslicer, sugar-getiabooks
> praiskup: js-html5shiv
> tdawson: rubygem-net-ssh-multi
> tpokorra: boo
> tuxbrewr: sugar-view-slides, sugar-infoslicer, sugar-getiabooks,
> sugar-flipsticks
>
___
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

Re: List of long term FTBFS packages to be retired in February

2021-01-20 Thread Miro Hrončok

On 20. 01. 21 14:15, Chihurumnaya Ibiam wrote:

I'd like sugar-view-slides and sugar-visualmatch to be exempted as I'm working 
on
both.


When do you expect to have it done? E.g. is it during the Fedora 34 release 
cycle?

--
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: List of long term FTBFS packages to be retired in February

2021-01-20 Thread Chihurumnaya Ibiam
Yes I expect to have it done during the Fedora 34 release cycle.

-- 

Ibiam Chihurumnaya
ibiamchihurumn...@gmail.com



On Wed, Jan 20, 2021 at 2:18 PM Miro Hrončok  wrote:

> On 20. 01. 21 14:15, Chihurumnaya Ibiam wrote:
> > I'd like sugar-view-slides and sugar-visualmatch to be exempted as I'm
> working on
> > both.
>
> When do you expect to have it done? E.g. is it during the Fedora 34
> release cycle?
>
> --
> 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: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

2021-01-20 Thread Pavel Raiskup
On Tuesday, January 19, 2021 8:50:38 PM CET Dan Čermák wrote:
> Dominik 'Rathann' Mierzejewski  writes:
> 
> > On Monday, 18 January 2021 at 23:29, Dan Čermák wrote:
> >> clime  writes:
> > [...]
> >> > But when you said "workaround", I was thinking that you actually saw
> >> > the correct solution because "workaround" is imho used usually when
> >> > someone can't or don't want to solve things the right way so he/she
> >> > takes a shortcut. So I was curious what you think is "the right way"
> >> > here.
> >> 
> >> Imho the "right way" would be to integrate this into rpmbuild itself
> >> instead of adding another layer on top of it.
> >
> > +1. Maybe it's time to introduce RPM spec file format versioning
> > and say .spec files with e.g.:
> >
> > SPEC-Version: 2
> >
> > should be pre-processed by rpmbuild first.
> 
> When we go down that route, we might even think about throwing out m4
> altogether and using a different templating language.

I think that m4 isn't used actually.

:-) I though that it would be awesome if we could actually finish the
m4-as-a-library concept [1] - and maybe teach RPM to use m4, one day.  At
least it sounds like a good experiment WRT macros (I wished to have
something like that when I reached the "max-macro-buffer-size" in RPM, in
m4 such limit shouldn't exist).

[1] m4 v2.0 sources 
http://git.savannah.gnu.org/gitweb/?p=m4.git;a=shortlog;h=refs/heads/master

Pavel

> But that a very OT
> discussion and would rather belong to the rpm development mailinglist.
> 
> 
> Cheers,
> 
> Dan
> 



___
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: List of long term FTBFS packages to be retired in February

2021-01-20 Thread Miro Hrončok

On 20. 01. 21 14:23, Chihurumnaya Ibiam wrote:

Yes I expect to have it done during the Fedora 34 release cycle.


OK, I won't bother FESCo with an exception request and will simply postpone the 
two retirements. Note that they will still be included in reports.


--
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: Fedora 34 Change: SOF as default audio driver for Intel LPE hardware (Self-Contained Change proposal)

2021-01-20 Thread Hans de Goede
Hi,

On 1/18/21 6:44 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jan 18, 2021 at 03:49:58PM +, Peter Robinson wrote:
>> On Mon, Jan 18, 2021 at 3:20 PM Ben Cotton  wrote:
>>>
>>> https://fedoraproject.org/wiki/Changes/SofDefaultForIntelLpe
>>>
>>>
>>> == Summary ==
>>> Intel LPE audio hardware has 2 drivers in the mainline kernel the SST
>>> driver and the SOF driver, switch the default driver from SST to SOF.
>>>
>>> == Owner ==
>>> * Name: [[User:jwrdegoede| Hans de Goede]]
>>> * Email: hdego...@redhat.com
>>>
>>>
>>> == Detailed Description ==
>>>
>>> Intel x86 hardware based on the Bay Trail-T and Cherry Trails SoCs
>>> does not come with the standard Intel HDA audio hardware. Instead it
>>> has an audio block called the Low Power Engine or LPE. The LPE block
>>> needs to have firmware loaded into it to function. There are 2
>>> firmwares available the old proprietary SST firmware and recently the
>>> open source SOF firmware has been released for the LPE engine.
>>>
>>> There are also 2 kernel drivers for the LPE block, one for each
>>> firmware, so we have a SST driver and a SOF driver. The upstream Intel
>>> developers of these drivers, who are also part of the SOF team want to
>>> deprecate and eventually remove the old SST driver in favor of the SOF
>>> driver. Starting with the 5.11 kernel it is possible to build both
>>> drivers into a single kernel and select which one will actually bind
>>> to the LPE block using a kernel commandline parameter.
>>>
>>> ATM the upstream default is the old SST driver, to avoid regressions.
>>> This Fedora change will entail carrying a downstream patch which flips
>>> the default to the SOF driver. This is being done in conclave with the
>>> upstream devs who would like to see more testing of the SOF driver.
>>> The upstream devs believe that the SOF driver is ready to replace the
>>> SST driver, but they would appreciate this being tested by Fedora
>>> first, before they flip the default for everyone.
>>>
>>>
>>> == Benefit to Fedora ==
>>>
>>> By consciously making the switch now, with extensive testing and
>>> monitoring the situation we can safely make the switch without
>>> regressions hitting users of the Fedora stable releases. Whereas if we
>>> just wait for upstream to flip the default, then this may very well
>>> land in the middle of a stable release when we rebase the kernel.
>>>
>>> This helps strengthen our relationship with the upstream developers
>>> and falls under the "First" part of the "Four Foundations".
>>>
>>> This stops us from depending in the proprietary SST firmware-blobs,
>>> replacing them with the Open Source SOF firmware, matching the
>>> "Freedom" part of the "Four Foundations".
>>>
>>> == Scope ==
>>> * Proposal owners: This will require a small downstream kernel patch
>>> to change the default driver when both are built (or an upstream patch
>>> to make the default configurable). That's it, no other changes are
>>> required.
>>> * Other developers: N/A (not a System Wide Change)
>>> * Release engineering: N/A (not a System Wide Change)
>>> * Policies and guidelines: N/A (not a System Wide Change)
>>> * Trademark approval: N/A (not needed for this Change)
>>> * Alignment with Objectives: This falls under the "First" part of the
>>> "Four Foundations".
>>>
>>> == Upgrade/compatibility impact ==
>>> The switch will automatically be made when booting a Fedora 34 kernel.
>>>
>>> == How To Test ==
>>> I (Hans de Goede) have an extensive collection of affected hardware.
>>> The audio setup on these devices consists of the LPE block itself
>>> combined with an external audio-codec. There are a number of
>>> audio-codecs used / supported on these boards. The LPE block has 2
>>> audio-links (called SSP0 and SSP2) and some of the codecs have 2
>>> audio-links (called AIF1 and AIF2) not each board uses the same
>>> audio-link on each side.
>>>
>>> I plan to run the below test-plan on devices with the following SoC /
>>> codec / link combinations:
>>>
>>> * Bay Trail (CR) / RT5640  / SSP0<->AIF1
>>> * Bay Trail (CR) / RT5640  / SSP0<->AIF2
>>> * Bay Trail  / RT5640  / SSP2<->AIF1
>>> * Cherry Trail   / RT5640  / SSP2<->AIF1
>>> * Cherry Trail   / RT5645  / SSP2
>>> * Bay Trail (CR) / RT5651  / SSP0<->AIF1
>>> * Cherry Trail   / RT5651  / SSP2<->AIF1
>>> * Bay Trail  / RT5672  / SSP2
>>> * Bay Trail (CR) / ESS8316 / SSP0
>>> * Cherry Trail   / ESS8316 / SSP2
>>> * Cherry Trail   / NAU8824 / SSP2
>>
>> Does this cover newer generations like Apollo Lake?

The LPE audio block really stems from Intel's efforts to get
into tablets, so 1-2W Scenario Design Power, Apollo Lake
does not scale that low and has normal HDA audio.

There are some special Haswell SKus which have a LPE
like block, but those use yet another firmware/driver combo.

So this is really only about Bay- and Cherry-Trail based
devices.

> Also: is there some easy command (something bar grep something) that
> users could execute to test if they have the affected hard

Re: Obsoletes/Provides question

2021-01-20 Thread Fabio Valentini
On Wed, Jan 20, 2021 at 3:23 AM Kevin Kofler via devel
 wrote:
>
> Daniel P. Berrangé wrote:
>
> > On Tue, Jan 19, 2021 at 03:18:41PM +, Richard W.M. Jones wrote:
> >> On Tue, Jan 19, 2021 at 04:12:59PM +0100, Miro Hrončok wrote:
> >> > On 19. 01. 21 16:06, Richard W.M. Jones wrote:
> >> > >(2) Or adding:
> >> > >
> >> > >%package tar-filter
> >> > >Obsoletes: %{name}-tar-plugin <= %{version}-%{release}
> >> > >
> >> > >which says that it obsoletes but doesn't provide a replacement.  Note
> >> > >however I'm not sure if this will work, because they won't have
> >> > >nbdkit-tar-filter installed before the upgrade (it never existed in
> >> > >F32), so will the Obsoletes ever be "seen" by dnf?
> >> >
> >> > Yes, it will be seen and respected.
> >> >
> >> > Note that it in most cases, it is recommended to obsolete a specific
> >> > version-release rather than %{version}-%{release}.
> >>
> >> To be clear, I would find the last released nbdkit-tar-plugin version
> >> in F32 (https://koji.fedoraproject.org/koji/buildinfo?buildID=1605446)
> >> and write this?
> >>
> >> %package tar-filter
> >> Obsoletes: %{name}-tar-plugin = 1.20.7-1.fc32
> >
> > Yes, but use <= here, rather than =, as users might be updating from an
> > older install.
> >
> > Arguably can leave off the .fc32 part too IMHO.
>
> But then, <= 1.20.7-1 will do the wrong thing, which is why Miro recommends
> (and I agree with him) to use < 1.20.7-2 instead.

Yes. This is also in line with the Packaging Guidelines, where there's
a good description of this scenario:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages

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: Fedora 34 Change: fbrnch (Self-Contained Change proposal)

2021-01-20 Thread Jens-Ulrik Petersen
On Tue, Jan 19, 2021 at 1:38 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> > Add the [https://github.com/juhp/fbrnch fbrnch] packager tool to Fedora.
>
> Sounds good ;)
>
> > ** Submit and complete package review(s).
>
> Links?
>

Thanks - I will try to get those posted soon.
Or for the initial Fedora package versions I might put some of the Fedora
web services bindings into fbrnch in the first instance to avoid the extra
packaging overhead for now.

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


Re: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

2021-01-20 Thread Vitaly Zaitsev via devel

On 20.01.2021 11:31, Miro Hrončok wrote:

Right before the mass rebuild. Is this known?


Fedora 34 will be built again with broken, full of regressions GCC 
compiler (just like Fedora 32).


--
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: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

2021-01-20 Thread Jeff Law


On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote:
> On 20.01.2021 11:31, Miro Hrončok wrote:
>> Right before the mass rebuild. Is this known?
>
> Fedora 34 will be built again with broken, full of regressions GCC
> compiler (just like Fedora 32).
Fix for this is already approved upstream and likely going into a new
spin of gcc.

FWIW, it's related to flipping to dwarf5.  It doesn't affect code
generation.

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


Review swap

2021-01-20 Thread Jerry James
MuseScore 3.6 is out, and adds a dependency on another font.  Who
would like to swap reviews?  I need this one:

steinberg-petaluma-fonts:
https://bugzilla.redhat.com/show_bug.cgi?id=1918394

Let me know what I can review for you.  Regards,
-- 
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: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

2021-01-20 Thread Vitaly Zaitsev via devel

On 20.01.2021 17:03, Jeff Law wrote:

Fix for this is already approved upstream and likely going into a new
spin of gcc.


Today I got two new GCC regressions in the same package. Reported to RHBZ.

--
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: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)

2021-01-20 Thread Matthew Miller
On Sun, Jan 17, 2021 at 05:58:45PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > Someone on Fedora Discussion¹ noticed this number and wonders if it's meant
> > to be 8192. Not that it probably matters very much, but, you know, nice
> > round numbers and all.
> 
> Yep, it was. I'll fix the wiki.

On another note, someone asked what 

"(Note that the device is destroyed and recreated during restart. This means
that all pages will be "swapped in", i.e. decompressed. On machines with low
memory, rebooting might be a better option.)"

means, and I realized I actually have no idea. Does this mean that low
memory machines should reboot often? Or is this just about testing after
changing settings?

-- 
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: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

2021-01-20 Thread Miro Hrončok

On 20. 01. 21 17:03, Jeff Law wrote:



On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote:

On 20.01.2021 11:31, Miro Hrončok wrote:

Right before the mass rebuild. Is this known?


Fedora 34 will be built again with broken, full of regressions GCC
compiler (just like Fedora 32).

Fix for this is already approved upstream and likely going into a new
spin of gcc.

FWIW, it's related to flipping to dwarf5.  It doesn't affect code
generation.


Can we please check the impact of such changes in the future *before* shipping 
them?

--
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: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

2021-01-20 Thread Jeff Law


On 1/20/21 9:17 AM, Miro Hrončok wrote:
> On 20. 01. 21 17:03, Jeff Law wrote:
>>
>>
>> On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote:
>>> On 20.01.2021 11:31, Miro Hrončok wrote:
 Right before the mass rebuild. Is this known?
>>>
>>> Fedora 34 will be built again with broken, full of regressions GCC
>>> compiler (just like Fedora 32).
>> Fix for this is already approved upstream and likely going into a new
>> spin of gcc.
>>
>> FWIW, it's related to flipping to dwarf5.  It doesn't affect code
>> generation.
>
> Can we please check the impact of such changes in the future *before*
> shipping them?
Generally we do.  If you were to look at the hundreds of fixes we've
already made in F33 and F34, those are a direct result of doing our own
test builds and fixing things we've found, either in the package or in
gcc itself.

THe dwarf5 change went in very late upstream and thus wasn't subject to
the continuous testing and fixing we've done.   Sorry for that.

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


Re: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

2021-01-20 Thread Jeff Law


On 1/20/21 9:08 AM, Vitaly Zaitsev via devel wrote:
> On 20.01.2021 17:03, Jeff Law wrote:
>> Fix for this is already approved upstream and likely going into a new
>> spin of gcc.
>
> Today I got two new GCC regressions in the same package. Reported to
> RHBZ.
THen it's a safe bet we'll fix them.



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


Re: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

2021-01-20 Thread Miro Hrončok

On 20. 01. 21 17:21, Jeff Law wrote:



On 1/20/21 9:17 AM, Miro Hrončok wrote:

On 20. 01. 21 17:03, Jeff Law wrote:



On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote:

On 20.01.2021 11:31, Miro Hrončok wrote:

Right before the mass rebuild. Is this known?


Fedora 34 will be built again with broken, full of regressions GCC
compiler (just like Fedora 32).

Fix for this is already approved upstream and likely going into a new
spin of gcc.

FWIW, it's related to flipping to dwarf5.  It doesn't affect code
generation.


Can we please check the impact of such changes in the future *before*
shipping them?

Generally we do.  If you were to look at the hundreds of fixes we've
already made in F33 and F34, those are a direct result of doing our own
test builds and fixing things we've found, either in the package or in
gcc itself.


Thanks!


THe dwarf5 change went in very late upstream and thus wasn't subject to
the continuous testing and fixing we've done.   Sorry for that.


I understand that stuff can break unexpectedly.

--
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: Fedora 34 Mass Rebuild

2021-01-20 Thread Tom Stellard

On 1/15/21 11:31 AM, Mohan Boddu wrote:

Hi all,

Per the Fedora 34 schedule[1] we will start a mass rebuild for Fedora 34
on Jan 20th 2021. We will run a mass rebuild for Fedora 34 for the
changes listed in:

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

Mass rebuild will be done in a side tag (f34-rebuild) and moved over
when completed.



Once a package is built in the side-tag, does it enter the side-tag 
buildroot so that other packages built in the side-tag may use it?


-Tom


Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f34-failures.html

Things still needing rebuilt
https://kojipkgs.fedoraproject.org/mass-rebuild/f34-need-rebuild.html

FTBFS bugs will be filed shortly.

Please be sure to let releng know if you see any bugs in the
reporting. You can contact releng in #fedora-releng on freenode, by
dropping an email to our list[2] or filing an issue in pagure[3]

Regards,
Mohan Boddu.

[1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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


Re: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

2021-01-20 Thread Jeff Law


On 1/20/21 9:29 AM, Miro Hrončok wrote:
> On 20. 01. 21 17:21, Jeff Law wrote:
>>
>>
>> On 1/20/21 9:17 AM, Miro Hrončok wrote:
>>> On 20. 01. 21 17:03, Jeff Law wrote:


 On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote:
> On 20.01.2021 11:31, Miro Hrončok wrote:
>> Right before the mass rebuild. Is this known?
>
> Fedora 34 will be built again with broken, full of regressions GCC
> compiler (just like Fedora 32).
 Fix for this is already approved upstream and likely going into a new
 spin of gcc.

 FWIW, it's related to flipping to dwarf5.  It doesn't affect code
 generation.
>>>
>>> Can we please check the impact of such changes in the future *before*
>>> shipping them?
>> Generally we do.  If you were to look at the hundreds of fixes we've
>> already made in F33 and F34, those are a direct result of doing our own
>> test builds and fixing things we've found, either in the package or in
>> gcc itself.
>
> Thanks!
NP.  It's good for Fedora and good for GCC as well.

>
>> THe dwarf5 change went in very late upstream and thus wasn't subject to
>> the continuous testing and fixing we've done.   Sorry for that.
>
> I understand that stuff can break unexpectedly.
Yea, the timing was awful.  It didn't help that when I saw this
yesterday in the tester I passed it along to Nick thinking it was
actually a binutils problem.  So we lost a fair amount of time because
of that.



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


Re: Review swap

2021-01-20 Thread Jared K. Smith
On Wed, Jan 20, 2021 at 11:13 AM Jerry James  wrote:

> MuseScore 3.6 is out, and adds a dependency on another font.  Who
> would like to swap reviews?  I need this one:
>

I'll review it.  I don't need any reviews done in return at this moment.

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


Re: Fedora 34 Mass Rebuild

2021-01-20 Thread Miro Hrončok

On 20. 01. 21 17:35, Tom Stellard wrote:

On 1/15/21 11:31 AM, Mohan Boddu wrote:

Hi all,

Per the Fedora 34 schedule[1] we will start a mass rebuild for Fedora 34
on Jan 20th 2021. We will run a mass rebuild for Fedora 34 for the
changes listed in:

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

Mass rebuild will be done in a side tag (f34-rebuild) and moved over
when completed.



Once a package is built in the side-tag, does it enter the side-tag buildroot so 
that other packages built in the side-tag may use it?


Usually yes, but not with the mass rebuild site tag (AFAIK).

--
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: List of long term FTBFS packages to be retired in February

2021-01-20 Thread Tom Callaway
Looks like VirtualGL was rebuilt:
https://koji.fedoraproject.org/koji/packageinfo?packageID=14293

~spot

On Mon, Dec 28, 2020 at 3:57 PM Miro Hrončok  wrote:

> Dear maintainers.
>
> Based on the current fail to build from source policy, the following
> packages
> will be retired from Fedora 34 approximately one week before branching
> (February
> 2021).
>
> Policy:
>
> https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
>
> Note that some listed packages are orphaned and hence may be retired even
> sooner.
>
> The packages in rawhide were not successfully built at least since Fedora
> 32.
>
> This report is based on dist tags.
>
> Packages collected via:
>
> https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb
>
> If you see a package that was built, please let me know.
> If you see a package that should be exempted from the process, please let
> me
> know and we can work together to get a FESCo approval for that.
>
> If you see a package that can be rebuilt, please do so.
>
>Package  (co)maintainers
> Latest build
>
> ===
> VirtualGL   gsgatlin   Fedora
> 31
> boo elsupergomez, orphan, tpokorra Fedora
> 31
> gmpcorphan Fedora
> 31
> jboss-servlet-2.5-api   dmoluguw, orphan   Fedora
> 31
> js-html5shivorphan Fedora
> 31
> js-respond  orphan Fedora
> 31
> nodejs-info-symbol  orphan Fedora
> 31
> nodejs-interpretnodejs-sig, orphan Fedora
> 31
> nodejs-net-browserify-alt   orphan Fedora
> 31
> nodejs-win-spawnnodejs-sig, orphan Fedora
> 31
> rubygem-net-ssh-multi   maxamillion, orphan, tdawson   Fedora
> 31
> sugar-flipstickscallkalpa, chimosky, pbrobinson,   Fedora
> 31
>   tuxbrewr
> sugar-getiabookscallkalpa, chimosky, pbrobinson,   Fedora
> 31
>   tuxbrewr
> sugar-infoslicercallkalpa, chimosky, pbrobinson,   Fedora
> 31
>   tuxbrewr
> sugar-labyrinth callkalpa, chimosky, pbrobinsonFedora
> 31
> sugar-ruler callkalpa, chimoskyFedora
> 31
> sugar-starchart callkalpa, chimosky, orphanFedora
> 31
> sugar-view-slides   callkalpa, chimosky, pbrobinson,   Fedora
> 31
>   tuxbrewr
> sugar-visualmatch   chimosky, orphan   Fedora
> 31
> sugar-yupanacallkalpa, chimosky, orphanFedora
> 31
>
>
> The following packages require above mentioned packages:
>
> Depending on: js-html5shiv (1)
> copr-frontend (maintained by: clime, copr-sig, dturecek, frostyx,
> msuchy, praiskup)
> copr-frontend-1.171-1.fc34.noarch requires js-html5shiv
>
> Depending on: nodejs-info-symbol (2)
> nodejs-log-utils (maintained by: orphan)
> nodejs-log-utils-0.2.1-6.fc32.noarch requires
> npm(info-symbol)
>
> nodejs-time-diff (maintained by: orphan)
> nodejs-time-diff-0.3.1-7.fc32.src requires npm(info-symbol)
>
> Depending on: nodejs-interpret (1)
> nodejs-shelljs (maintained by: fab, nodejs-sig, patches)
> nodejs-shelljs-0.8.4-2.fc33.noarch requires npm(interpret)
>
>
> Affected (co)maintainers (directly and indirectly):
> callkalpa: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks,
> sugar-view-slides, sugar-infoslicer, sugar-starchart, sugar-getiabooks
> chimosky: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks,
> sugar-view-slides, sugar-visualmatch, sugar-infoslicer, sugar-starchart,
> sugar-getiabooks
> clime: js-html5shiv
> copr-sig: js-html5shiv
> dmoluguw: jboss-servlet-2.5-api
> dturecek: js-html5shiv
> elsupergomez: boo
> fab: nodejs-interpret
> frostyx: js-html5shiv
> gsgatlin: VirtualGL
> maxamillion: rubygem-net-ssh-multi
> msuchy: js-html5shiv
> nodejs-sig: nodejs-win-spawn, nodejs-interpret
> patches: nodejs-interpret
> pbrobinson: sugar-labyrinth, sugar-flipsticks, sugar-view-slides,
> sugar-infoslicer, sugar-getiabooks
> praiskup: js-html5shiv
> tdawson: rubygem-net-ssh-multi
> tpokorra: boo
> tuxbrewr: sugar-view-slides, sugar-infoslicer, sugar-getiabooks,
> sugar-flipsticks
> ___
> 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-cond

Re: List of long term FTBFS packages to be retired in February

2021-01-20 Thread Miro Hrončok

On 20. 01. 21 17:50, Tom Callaway wrote:

Looks like VirtualGL was rebuilt:
https://koji.fedoraproject.org/koji/packageinfo?packageID=14293 



Yes, known. It will be no longer listed in the report next week.

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


Summary/Minutes from today's FESCo Meeting (2021-01-20)

2021-01-20 Thread Stephen Gallagher
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

=
#fedora-meeting-2: FESCO (2021-01-20)
=


Meeting started by sgallagh at 15:00:19 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-01-20/fesco.2021-01-20-15.00.log.html
.



Meeting summary
- ---
* init process  (sgallagh, 15:00:19)

* #2547 F34 Change: Signed RPM Contents  (sgallagh, 15:05:44)
  * ACTION: puiterwijk to update the Change Proposal with more details
(sgallagh, 16:03:55)
  * Once the Change is updated, FESCo will re-evaluate and may vote on
the ticket following the FastTrack process  (sgallagh, 16:04:21)
  * ACTION: puiterwijk will notify fedora-devel when the Change is
updated  (sgallagh, 16:05:54)

* #2545 F34 Change: Localization measurement and tooling  (sgallagh,
  16:14:42)

* #2543 F34 Change: Unify the GRUB configuration files location across
  all supported architectures  (sgallagh, 16:20:25)
  * AGREED: Unification of GRUB config files is accepted (+6, 1, -0)
(sgallagh, 16:27:42)

* Next week's chair  (sgallagh, 16:27:50)
  * ACTION: King_InuYasha to chair the next meeting  (sgallagh,
16:30:11)

* Open Floor  (sgallagh, 16:30:19)
  * LINK: https://pagure.io/fesco/fesco-docs/pull-request/41   (zbyszek,
16:31:20)

Meeting ended at 16:41:32 UTC.




Action Items
- 
* puiterwijk to update the Change Proposal with more details
* puiterwijk will notify fedora-devel when the Change is updated
* King_InuYasha to chair the next meeting




Action Items, by person
- ---
* King_InuYasha
  * King_InuYasha to chair the next meeting
* puiterwijk
  * puiterwijk to update the Change Proposal with more details
  * puiterwijk will notify fedora-devel when the Change is updated
* **UNASSIGNED**
  * (none)




People Present (lines said)
- ---
* sgallagh (106)
* mhroncok (57)
* puiterwijk (55)
* King_InuYasha (50)
* nirik (48)
* zbyszek (46)
* decathorpe (23)
* dcantrell (22)
* zodbot (16)
* cverna (7)
* mboddu (7)
* ignatenkobrain (0)
* Conan_Kudo (0)
* Eighth_Doctor (0)
* Sir_Gallantmon (0)
* Son_Goku (0)
* Pharaoh_Atem (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAmAIaj8ACgkQRduFpWgo
bRFj0AwAkpTWTcAumt/ZqWpiWB5P8ZCdGd3S6aYX4lHqhQiEyaGR1LObXVX+ltew
iDH8QKgItVibOkaU8aGcoOvDnmPA4AGAm9ZamwzL0ZH2/EXEfgpAw5FQvqRFdVIy
i4LCpqcikD+KUtrrje2HBgqXm5IawkxMaYOOUS+BNAXpNblbc5f8txmLLQJgEACt
9anrOm+YxCPHBa52zUo53J83lxyV/sXGRfsSAWW5O0Uw6QmVhyU9UrIposcyDBmW
AFCfx0NWbDmYaXWweLXCicO2F30WV/mnvRQstEx15UholwA2LlptYVWJj6rlUdDX
E/zFPwL6fsbcI35nKqUg+4FQQs15vQO8IMpJTpWW4468milNojjXYYk20zB4RJNw
6mKEYPfc/69wqemb79zGYfJ1dv7ls2d1bk+iAyhVhrngPpUtWjyowLhjEY/nwCBg
URth/ep/IzNhEH7IAA9PY14Ot1mp3gbHeiclild6okp0Vmcwj5/n0GZAOMm7B/Ne
Zvo66vqJ
=Wz0F
-END 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


SCons-4.1.0

2021-01-20 Thread Antonio T. sagitter

Hi all.

scons-4.1.0 rpm [1] is ready to be pushed in Rawhide branch; not before 
next 7 days i will build it.

Release note of SCons-4.1.0 [2].

Packages which require SCons:

boswars-0:2.7-24.svn160110.fc33.src
compat-tolua++-0:1.0.93-14.fc33.src
galera-0:26.4.6-1.fc34.src
glob2-0:0.9.4.4-53.fc33.src
godot-0:3.2.1-1.fc33.1.src
gpsd-1:3.22-1.fc34.src
libffado-0:2.4.4-2.fc34.src
libserf-0:1.3.9-17.fc33.src
mingw-nsis-0:3.06.1-1.fc33.src
mypaint-0:2.0.1-1.fc34.src
netpanzer-0:0.8.7-16.fc33.src
pingus-0:0.7.6-37.fc33.src
powdertoy-0:95.0-3.fc33.src
sunpinyin-0:3.0.0-0.4.20190805git.fc33.src
tolua++-0:1.0.93-30.fc33.src
vdrift-0:20141020-22.fc33.src
wesnoth-0:1.15.8-1.fc34.src

[1] https://sagitter.fedorapeople.org/SCons/scons-4.1.0-1.fc33.src.rpm
[2] https://github.com/SCons/scons/releases/tag/4.1.0

--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.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: Fedora 34 Mass Rebuild

2021-01-20 Thread Kevin Fenzi
On Wed, Jan 20, 2021 at 08:35:54AM -0800, Tom Stellard wrote:
> On 1/15/21 11:31 AM, Mohan Boddu wrote:
> > Hi all,
> > 
> > Per the Fedora 34 schedule[1] we will start a mass rebuild for Fedora 34
> > on Jan 20th 2021. We will run a mass rebuild for Fedora 34 for the
> > changes listed in:
> > 
> > https://pagure.io/releng/issues?status=Open&tags=mass+rebuild
> > 
> > Mass rebuild will be done in a side tag (f34-rebuild) and moved over
> > when completed.
> > 
> 
> Once a package is built in the side-tag, does it enter the side-tag
> buildroot so that other packages built in the side-tag may use it?

Nope... or well, you shouldn't count on it. 

Basically things are submitted as fast as they can be, if we waited for
newrepo between each build it would take months to rebuild things. 

In some kind of shiny future, it would be cool to be able to see what
things need bootstrapping, bootstrap them into the rebuild and then
rebuild everything else in dependecy order. Thats gonna be a lot of work
though. 

kevin


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


Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)

2021-01-20 Thread Samuel Sieb

On 1/20/21 8:14 AM, Matthew Miller wrote:

On Sun, Jan 17, 2021 at 05:58:45PM +, Zbigniew Jędrzejewski-Szmek wrote:

Someone on Fedora Discussion¹ noticed this number and wonders if it's meant
to be 8192. Not that it probably matters very much, but, you know, nice
round numbers and all.


Yep, it was. I'll fix the wiki.


On another note, someone asked what

"(Note that the device is destroyed and recreated during restart. This means
that all pages will be "swapped in", i.e. decompressed. On machines with low
memory, rebooting might be a better option.)"

means, and I realized I actually have no idea. Does this mean that low
memory machines should reboot often? Or is this just about testing after
changing settings?


That's about changing settings.  When restarting the zram service, it 
has to remove the swap device which forces all the swapped pages back 
into RAM.  This might not be successful if you don't have enough RAM, so 
if you are using a low memory device, you should reboot instead. 
Although if you see that you aren't using too much swap, then it could 
be ok.

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


Re: Fedora 34 Mass Rebuild

2021-01-20 Thread Mohan Boddu
On Wed, Jan 20, 2021 at 11:36 AM Tom Stellard  wrote:
>
> On 1/15/21 11:31 AM, Mohan Boddu wrote:
> > Hi all,
> >
> > Per the Fedora 34 schedule[1] we will start a mass rebuild for Fedora 34
> > on Jan 20th 2021. We will run a mass rebuild for Fedora 34 for the
> > changes listed in:
> >
> > https://pagure.io/releng/issues?status=Open&tags=mass+rebuild
> >
> > Mass rebuild will be done in a side tag (f34-rebuild) and moved over
> > when completed.
> >
>
> Once a package is built in the side-tag, does it enter the side-tag
> buildroot so that other packages built in the side-tag may use it?

Nope, it wont, mass rebuild side tag uses the general release
buildroot (for ex: f34-build), so in case if you really want something
to be available in the buildroot, you can run a normal build and the
mass rebuild will pick up the new buildroot, but only some mass
rebuild builds will pick up the new buildroot depending on where
exactly the mass rebuild is at that point of time. That's why we ask
the maintainers to land all their changes in rawhide before we start
the mass rebuild.

>
> -Tom
>
> > Failures can be seen
> > https://kojipkgs.fedoraproject.org/mass-rebuild/f34-failures.html
> >
> > Things still needing rebuilt
> > https://kojipkgs.fedoraproject.org/mass-rebuild/f34-need-rebuild.html
> >
> > FTBFS bugs will be filed shortly.
> >
> > Please be sure to let releng know if you see any bugs in the
> > reporting. You can contact releng in #fedora-releng on freenode, by
> > dropping an email to our list[2] or filing an issue in pagure[3]
> >
> > Regards,
> > Mohan Boddu.
> >
> > [1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html
> > [2] 
> > https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
> > [3] https://pagure.io/releng/
> > ___
> > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> > To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >
>
___
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: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)

2021-01-20 Thread Matthew Miller
On Wed, Jan 20, 2021 at 10:59:52AM -0800, Samuel Sieb wrote:
> That's about changing settings.  When restarting the zram service,
> it has to remove the swap device which forces all the swapped pages
> back into RAM.  This might not be successful if you don't have
> enough RAM, so if you are using a low memory device, you should
> reboot instead. Although if you see that you aren't using too much
> swap, then it could be ok.

Thanks! That makes sense!

-- 
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: Review swap

2021-01-20 Thread Jerry James
On Wed, Jan 20, 2021 at 9:40 AM Jared K. Smith  wrote:
> I'll review it.  I don't need any reviews done in return at this moment.

Thank you, Jared!  Please let me know when you do need a review.
-- 
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


Request for contributions: Demos of Features or other videos for virtual FOSDEM 2021 booth

2021-01-20 Thread Till Maas
Hi,

there will be a virtual booth at FOSDEM 2021 and this allows to show
some videos. This allows to present the latest features in Fedora or
other interesting items. I skimmed over the Features for 33 and 34 and
the following topics seemed to be good for a video:

- IoT edition
- i3 spin
- overview of benefits from btrfs as root filesystem
- ELN
- swap of zram
- sqlite rpmdb
- systemd-resolved
- nano as editor
- network time security
- thermal management
- storage instatiation daemon
- reserve resources for active users
- DNS over TLS
- module obsoletes and EOL
- restart services at end of rpm transaction
- rust crate packages
- update-alternatives for cc and c++
- wayland for KDE
- xwayland as standalone package
- gitrepos master to main
- compress kernel firmware
- maybe something for language updates or package updates that explain
  the new benefits (don't want to list all of them)
- ntp replacement

If you would create a video to show at FOSDEM or have one in mind,
please add them to the table at
https://fedoraproject.org/wiki/FOSDEM_2021#Videos

FOSDEM will be 6-7 February, so if you would like to contribute, it
would need to be soon.

There is also a mindshare ticket to track efforts for FOSDEM:
https://pagure.io/mindshare/issue/248

Thanks
Till
___
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: Crash, maybe, in packaging scripts on Koji/s390

2021-01-20 Thread Jeff Law


On 1/20/21 3:53 AM, Richard W.M. Jones wrote:
> On Wed, Jan 20, 2021 at 10:52:35AM +, Richard W.M. Jones wrote:
>> https://kojipkgs.fedoraproject.org//work/tasks/9457/60089457/build.log
>> (from https://koji.fedoraproject.org/koji/taskinfo?taskID=60089433)
>>
>> ends with ...
>>
>> Checking for unpackaged file(s): /usr/lib/rpm/check-files 
>> /builddir/build/BUILDROOT/ocaml-extlib-1.7.8-1.fc34.s390x
>> Child return code was: -11
>> EXCEPTION: [Error()]
>> Traceback (most recent call last):
>>   File "/usr/lib/python3.9/site-packages/mockbuild/trace_decorator.py", line 
>> 93, in trace
>> result = func(*args, **kw)
>>   File "/usr/lib/python3.9/site-packages/mockbuild/util.py", line 600, in 
>> do_with_status
>> raise exception.Error("Command failed: \n # %s\n%s" % (command, output), 
>> child.returncode)
>> mockbuild.exception.Error: Command failed: 
>>  # bash --login -c /usr/bin/rpmbuild -bb --target s390x --nodeps 
>> /builddir/build/SPECS/ocaml-extlib.spec
>>
>> I kicked off another build to see if this is reproducible.
> Oh sorry, I see there is already a thread this morning about this:
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XQWO72AZ7MKVC3CSICKKYF77EHNUVJ6U/
Should be fixed now I think.  Hopefully mjw, jakub and florian are
getting some sleep.    The s390x issue was "beyond unexpected".

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


Re: Crash, maybe, in packaging scripts on Koji/s390

2021-01-20 Thread Jakub Jelinek
On Wed, Jan 20, 2021 at 02:38:18PM -0700, Jeff Law wrote:
> On 1/20/21 3:53 AM, Richard W.M. Jones wrote:
> > On Wed, Jan 20, 2021 at 10:52:35AM +, Richard W.M. Jones wrote:
> >> https://kojipkgs.fedoraproject.org//work/tasks/9457/60089457/build.log
> >> (from https://koji.fedoraproject.org/koji/taskinfo?taskID=60089433)
> >>
> >> ends with ...
> >>
> >> Checking for unpackaged file(s): /usr/lib/rpm/check-files 
> >> /builddir/build/BUILDROOT/ocaml-extlib-1.7.8-1.fc34.s390x
> >> Child return code was: -11
> >> EXCEPTION: [Error()]
> >> Traceback (most recent call last):
> >>   File "/usr/lib/python3.9/site-packages/mockbuild/trace_decorator.py", 
> >> line 93, in trace
> >> result = func(*args, **kw)
> >>   File "/usr/lib/python3.9/site-packages/mockbuild/util.py", line 600, in 
> >> do_with_status
> >> raise exception.Error("Command failed: \n # %s\n%s" % (command, 
> >> output), child.returncode)
> >> mockbuild.exception.Error: Command failed: 
> >>  # bash --login -c /usr/bin/rpmbuild -bb --target s390x --nodeps 
> >> /builddir/build/SPECS/ocaml-extlib.spec
> >>
> >> I kicked off another build to see if this is reproducible.
> > Oh sorry, I see there is already a thread this morning about this:
> >
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XQWO72AZ7MKVC3CSICKKYF77EHNUVJ6U/
> Should be fixed now I think.  Hopefully mjw, jakub and florian are
> getting some sleep.    The s390x issue was "beyond unexpected".

It will only be fixed when gcc-11.0.0-0.16.fc34 makes it into the
buildroots.

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


Re: /usr/lib/rpm/redhat/brp-strip-lto fails with symbol `.gnu.debuglto_.debug_line_str' required but not present

2021-01-20 Thread Kevin Kofler via devel
Miro Hrončok wrote:
> symbol `.gnu.debuglto_.debug_line_str' required but not present

This is causing a whole chain of breakage in Rawhide: The above bug prevents 
building binutils, which prevents fixing:
https://bugzilla.redhat.com/show_bug.cgi?id=1916925
which in turn prevents rebuilding qt5-qtwebengine with my attempt to fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1904652
(which is actually caused by a glibc change, but I'm trying to get the 
Chromium/QtWebEngine sandbox to work with the changed glibc).

In addition, the .gnu.debuglto_.debug_line_str issue also breaks building 
qt3 according to Koschei (but I am not in a hurry to rebuild that one right 
now).

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


Self Introduction: Matthew Almond

2021-01-20 Thread Matthew Almond via devel
Hi everyone,

Some background on me: I've been working with Linux since 1995 in a
variety of capacities. I'm fascinated by file systems, configuration
and system management technologies.

I'm the author of RPMCoW[1]. This was recently accepted for Fedora 34.
I aim to provide the new features first as patches to rpm[2] and
librepo[3] along with a new package dnf-plugin-cow[4] which I will
submit shortly. Given the deadlines for Fedora 34, I expect to iterate
the patches against the upstream sources[5][6] in parallel with the
forks/PRs on the package sources.

I'm presenting (virtually) this work at CentOS Dojo @ FOSDEM 2021[7]. I
anticipate the talk will be recorded. To date my best explanations have
been facilitated by use of diagrams and simple animation. I expect to
eventually write a white paper on this topic, but as time is a precious
resource, I am inclined to focus on making this available to all first.

I am excited to finally contribute back to the community which has
given so much. Cheers!

- Matthew

[1] https://fedoraproject.org/wiki/Changes/RPMCoW
[2] https://src.fedoraproject.org/fork/malmond/rpms/rpm
[3] https://src.fedoraproject.org/fork/malmond/rpms/librepo
[4] https://github.com/facebookincubator/dnf-plugin-cow
[5] https://github.com/rpm-software-management/rpm/pull/1470
[6] https://github.com/rpm-software-management/librepo/pull/222
[7] https://hopin.com/events/centos-dojo-fosdem
___
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: Signed RPM Contents (late System-Wide Change)

2021-01-20 Thread Patrick マルタインアンドレアス Uiterwijk
> https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents
> 

I'd like to point out that after many requests, I have updated the change page 
for this significantly, with more details as to the goals (and non-goals) of 
this feature, and answers to many other questions asked.

Please have another look if you are interested in this.
___
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: Signed RPM Contents (late System-Wide Change)

2021-01-20 Thread Miro Hrončok

On 21. 01. 21 0:29, Patrick マルタインアンドレアス Uiterwijk wrote:

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



I'd like to point out that after many requests, I have updated the change page 
for this significantly, with more details as to the goals (and non-goals) of 
this feature, and answers to many other questions asked.

Please have another look if you are interested in this.


Thanks!

--
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: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

2021-01-20 Thread Stephen Gallagher
On Wed, Jan 20, 2021 at 7:10 PM Miro Hrončok  wrote:
>
> On 21. 01. 21 0:29, Patrick マルタインアンドレアス Uiterwijk wrote:
> >> https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents
> >>
> >
> > I'd like to point out that after many requests, I have updated the change 
> > page for this significantly, with more details as to the goals (and 
> > non-goals) of this feature, and answers to many other questions asked.
> >
> > Please have another look if you are interested in this.
>
> Thanks!
>

Indeed, thank you very much, Patrick. I genuinely appreciate the
effort you've put into this update and it answers the remaining
questions I had for this feature.
___
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: Matthew Almond

2021-01-20 Thread Matthew Miller
On Wed, Jan 20, 2021 at 11:27:28PM +, Matthew Almond via devel wrote:
> I'm the author of RPMCoW[1]. This was recently accepted for Fedora 34.

Welcome, and thanks for pushing interesting new ideas into Fedora!


-- 
Matthew Miller

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


Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

2021-01-20 Thread Matthew Miller
On Wed, Jan 20, 2021 at 11:29:55PM -, Patrick  マルタインアンドレアス  Uiterwijk wrote:
> > https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents
> I'd like to point out that after many requests, I have updated the change
> page for this significantly, with more details as to the goals (and
> non-goals) of this feature, and answers to many other questions asked.
> 
> Please have another look if you are interested in this.

Maybe worth sending to devel-announce again?

-- 
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: [ELN] How to handle RHEL-specific changes when it fails in ELN?

2021-01-20 Thread Nico Kadel-Garcia
On Tue, Jan 19, 2021 at 6:49 AM Fabio Valentini  wrote:
>
> On Tue, Jan 19, 2021 at 12:22 AM Josh Stone  wrote:
> >
> > On 1/16/21 3:21 PM, Nico Kadel-Garcia wrote:
> > > On Sat, Jan 16, 2021 at 4:54 PM Kevin Kofler via devel
> > >  wrote:
> > >>
> > >> Miro Hrončok wrote:
> > >>> See also:
> > >>> https://src.fedoraproject.org/rpms/rust-bootupd/c/c6cf7f6492e0d943e8471f86719df89eed587f6a?branch=master
> > >>
> > >> This is a blatant violation of Fedora packaging guidelines and ought to 
> > >> be
> > >> reverted immediately.
> > >>
> > >> Kevin Kofler
>
> (snip)
>
> > > And where and how, precisely, does "rhel require this". Having the
> > > provenance of the source tarballs or git repos is wise and sensible,
> > > and random tarballs with no provenance are a problem for everybody, so
> > > that part is a good idea. But I'm not aware of it as a requirement. Is
> > > anyone else?
> >
> > It's a softer "requires", as in: RHEL is not shipping rust2rpm nor the
> > mass of rust-*-devel packages, so vendoring is the way.
>
> That might be so, but it's not a valid reason to build packages this
> way in fedora, where all the required dependencies should be present
> already.
> Additionally, missing instructions on how to build the "vendor"
> tarball, missing License information for the vendored crates, and
> missing "bundled()" provides are *definitely* against Packaging
> Guidelines.
>
> Fabio

I see a "Source1" tarball from github. If a github published archive
isn't reasonable for a Source tarball, there are a *lot* of other
.spec files that would need to be rejected.

Some of the other logic about this is peculiar, but that particular
"including a separate tarball" part looks  legal in and of itself. The
Samba and Subversion and Emacs SRPM's, for example, have included
separate tarballs for years.
___
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


Schedule for Thursday's FPC Meeting (2021-01-21 17:00 UTC)

2021-01-20 Thread James Antill
 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2021-01-21 17:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2021-01-21 09:00 PST  US/Pacific
2021-01-21 12:00 EST  --> US/Eastern <--
2021-01-21 17:00 GMT  Europe/London 
2021-01-21 17:00 UTC  UTC   
2021-01-21 18:00 CET  Europe/Berlin 
2021-01-21 18:00 CET  Europe/Paris  
2021-01-21 22:30 IST  Asia/Calcutta 
 New Day: Friday -
2021-01-22 01:00 HKT  Asia/Hong_Kong
2021-01-22 01:00 +08  Asia/Singapore
2021-01-22 02:00 JST  Asia/Tokyo
2021-01-22 03:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

= Followup Actions =

#topic #pr-814
 * mhroncok
   talk to authors again, having a working example might help a lot

#topic Open Floor
 * decathorpe
   look through non-meeting tickets, see if any are stuck/need to be discussed

= Followup Issues =

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

= Followup Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines.
https://pagure.io/packaging-committee/pull-request/814

= Pull Requests =

#topic #pr-1041 Use only .metainfo.xml in AppData guidelines 
https://pagure.io/packaging-committee/pull-request/1041

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * Bring it up at the end of the meeting, during the open floor topic. Note
    that added topics may be deferred until the following meeting.

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


Backwards-incompatible RPM format change in Fedora 34?

2021-01-20 Thread Florian Weimer
With rpm-4.15.1-3.fc32.1.x86_64, I get this error:

$ rpm -qip 
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/debug/tree/Packages/m/ModemManager-debugsource-1.14.10-1.fc34.aarch64.rpm
error: /var/tmp/rpm-tmp.6iU66n: signature hdr data: BAD, no. of bytes(88084) 
out of range
error: 
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/debug/tree/Packages/m/ModemManager-debugsource-1.14.10-1.fc34.aarch64.rpm:
 not an rpm package (or package manifest)

Is this expected?

It seems that rpm-4.16.1.2-1.fc33.x86_64 can parse the RPM just fine.
But rpm-4.14.3-4.el8.x86_64 does not like it, either.

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