It looks like there are hundreds of build breakages related to the new GCC 5 which has been set up on the tumbleweed build service. These all need feeding back to upstream providers; presumably cases where the C and C++ code doesn’t conform with the standard enforced by the new compiler. Is there anything that I as a willing potential user of tumbleweed can do to help with this ? Or is it all being done already behind the scenes by others ? Meanwhile it might be necessary to regress to the previous GCC on the build machine in order to explore progress with things like wayland and the new KDE. Is this under consideration ?
The build breaks are catalogued here https://build.opensuse.org/project/monitor/openSUSE:Factory?blocked=0&building=0&dispatching=0&finished=0&scheduled=0&signing=0&succeeded=0 .
The best place for those questions relating to Tumbleweed is the Factory Mailing List. The archive is at http://lists.opensuse.org/opensuse-factory/
For latest there on GCC5 see this ML thread and follow future weeks: Tumbleweed - Review of the Week
‘Factory’ is down to 78 build breakages, and it looks to me as if none of them are in packages that go on the ISO. So it looks like the backroom people are doing good work, and maybe we will get a fresh build soon to try out.
The mailing list is very quiet; I tried posting to it to offer my help in resolving a few build breaks, but the message bounced; though I am willing to lend a hand, I do not seem able to.
The bounce message should give you the reason why it bounced… E.g. mails containing HTML are not accepted.
though I am willing to lend a hand, I do not seem able to.
You could just branch a package on OBS, fix it, and submit it back.
See also: openSUSE:How to contribute to Factory - openSUSE Wiki
Here’s the bounce message
The message from <xxxx@gmail.com> with subject “Fwd: How to contribute to
resolving the build breakages ?” was unable to be delivered to the list
because of an access rule set up by the list administrator.
I rather assumed that a list administrator would have to approve the first few messages I sent to the list, but that does not seem to have happened yet.
Anyway, I tried the instructions for contributing a fix to a package, but I didn’t get very far. I checked out a package; that gave me a ‘zip’ file which I unzipped and that then seemed to be the source code; but it wasn’t clear to me how to (attempt to) build the package, or what to do to set up appropriate files for checking in again. I’ll keep looking and keep trying; but if you can post a worked example here or on the wiki, that would be most helpful.
No. If you are subscribed to the list, there should not be any moderation action necessary, not even for your first mail.
If you are not subscribed, you cannot send a mail at all IIANM.
Maybe your mail address is on some blacklist? No idea.
Anyway, I tried the instructions for contributing a fix to a package, but I didn’t get very far. I checked out a package; that gave me a ‘zip’ file which I unzipped and that then seemed to be the source code; but it wasn’t clear to me how to (attempt to) build the package, or what to do to set up appropriate files for checking in again.
Yes, if you run “osc ci …” you get the package’s source code.
There’s no need to build it locally, as it will be built on OBS anyway. If you want to, you can with “osc build”.
Normally you shouldn’t modify the sources in the tarball themselves, but rather add patches.
You could also use the web frontend, might be easier especially in the beginning:
I’ll keep looking and keep trying; but if you can post a worked example here or on the wiki, that would be most helpful.
I can get a local build of the package I’m trying to take a look at (‘ksh’, for what it’s worth); but the build is set up with rpm/rpmbuild, which means it’s rather heavily encapsulated and I can’t find anywhere to go to a directory and try ‘make’ to investigate the breakage. Also I wouldn’t know how to create a patch file to put back into the OBS if I was ever to be able to figure out what was wrong.
So, defeated by the automation, at the moment.
I see the numbers of packages in error jumping up and down by a few; there were 72 failing packages when I last looked, which is down a lot from the 200+ that there were yesterday. So it looks like several people are attending to the breakages at the moment, which is hopeful for the prospects of having a viable up-to-date tumbleweed build soon.
There should be a build log, which contains the whole output of the build process. I’m not sure how you’d access it after a local build though, as I normally don’t build locally.
In the web interface you can just click on the “failed” or “succeeded” package status to get it.
Or use “osc buildlog”.
Btw, osc has extensive online help, just run “osc --help” or “osc command --help”…
Also I wouldn’t know how to create a patch file to put back into the OBS if I was ever to be able to figure out what was wrong.
Should be explained in the last link I gave you.
In short: fix the problem, create a diff, and add it as patch to the specfile.
The problem with ‘ksh’ seems to be this fragment of code
#ifndef L_tmpnam
#define L_tmpnam 25
#endif
extern char*
tmpnam(char* s)
{
static char buf[L_tmpnam];
return pathtemp(s ? s : buf, L_tmpnam, NiL, "tn", NiL);
}
which generates error messages
341s] /home/abuild/rpmbuild/BUILD/ksh93/src/lib/libast/comp/tmpnam.c: In function '_ast_tmpnam':^M
341s] /home/abuild/rpmbuild/BUILD/ksh93/src/lib/libast/comp/tmpnam.c:48:14: error: storage size of 'buf' isn't known^M
341s] static char buf[L_tmpnam];^M
341s] ^^M
341s] /home/abuild/rpmbuild/BUILD/ksh93/src/lib/libast/comp/tmpnam.c:50:39: error: expected expression before ',' token^M
341s] return pathtemp(s ? s : buf, L_tmpnam, NiL, "tn", NiL);^M
341s] ^^M
341s] /home/abuild/rpmbuild/BUILD/ksh93/src/lib/libast/comp/tmpnam.c:48:14: warning: unused variable 'buf' -Wunused-variable]^M
341s] static char buf[L_tmpnam];^M
341s] ^^M
i.e. it looks as if L_tmpnam is already defined to something other than a suitable number. Is this a known GCC 5-ism ? I’ll try and develop something that I can check in as a patch for this, and a revision to the ‘ksh.spec’ file; but if someone wants to jump in and do this faster than I can, they are most welcome to.
Maybe this patch helps?
https://build.opensuse.org/package/view_file/home:Andreas_Schwab:Factory/ksh/cpp.patch?expand=1
Doesn’t really seem to be related, but that’s the only change in the derived package in home:Andreas_Schwab:Factory which builds fine.
L_tmpnam in turn comes from
<<"#ifndef L_tmpnam">>
#ifndef L_tmpnam
#define L_tmpnam (sizeof(P_tmpdir)+15)
#endif
<<"#define L_tmpnam">> L_tmpnam
<<"#endif">>
in src/lib/libast/features/stdio , and it ends up being macro-defined to ‘empty’, which then causes the problem with the compile. It comes from some kind of code-generator utility which I have not come across before. Maybe someone who understands what they are doing can take this one on; I’d only be likely to cause a greater mess by guessing. And there’s lots of other build breakages for me to try to fix.
Yeah, and I suppose that “code-generator utility” is fixed by the patch mentioned above.
I’m pretty sure that Andreas Schwab will submit back his fixes anyway though… 
So ‘ksh’ will get fixed in due course, which is good. ‘libhugetlbfs’ has also already been fixed, but still shows up as broken in the OBS report. I’m taking on ‘seamonkey’ next; is there somewhere a list of what still needs fixing, so I can try my hand at something useful ?
seamonkey’s breakage is
#if MOZ_LIBSTDCXX_VERSION >= GLIBCXX_VERSION(3, 4, 14)
/* Instantiate these templates to avoid GLIBCXX_3.4.14 symbol versions
* depending on optimization level */
template char *string::_S_construct_aux_2(size_type, char, allocator<char> const&);
#ifdef _GLIBCXX_USE_WCHAR_T
template wchar_t *wstring::_S_construct_aux_2(size_type, wchar_t, allocator<wchar_t> const&);
#endif /* _GLIBCXX_USE_WCHAR_T */
which gives error messages
541s] c++ -o host_stdc++compat.o -c -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fno-strict-aliasing -std=gnu++0x -MD -MP -MF .deps/host_stdc++compat.o.pp -DMOZ_LIBSTDCXX_VERSION=197653 -I/home/abuild/rpmbuild/BUILD/seamonkey/mozilla/build/unix/stdc++compat -I. -I../../../dist/include -I/usr/include/nspr4 /home/abuild/rpmbuild/BUILD/seamonkey/mozilla/build/unix/stdc++compat/stdc++compat.cpp
542s] /home/abuild/rpmbuild/BUILD/seamonkey/mozilla/build/unix/stdc++compat/stdc++compat.cpp:49:86: error: no member function '_S_construct_aux_2' declared in 'std::__cxx11::basic_string<char>'
542s] template char *string::_S_construct_aux_2(size_type, char, allocator<char> const&);
542s] ^
542s] /home/abuild/rpmbuild/BUILD/seamonkey/mozilla/build/unix/stdc++compat/stdc++compat.cpp:51:96: error: no member function '_S_construct_aux_2' declared in 'std::__cxx11::basic_string<wchar_t>'
542s] template wchar_t *wstring::_S_construct_aux_2(size_type, wchar_t, allocator<wchar_t> const&);
542s] ^
This one looks like it’s best fixed by someone who knows their way around seamonkey and/or the templates in the cxx11 headers. I’ll try something else …
I think the fix for the apache2-mod-perl breakage is
--- src/modules/perl/modperl_handler.h.orig 2015-06-25 11:24:55.633601071 +0100
+++ src/modules/perl/modperl_handler.h 2015-06-25 11:25:36.632508649 +0100
@@ -44,7 +44,7 @@
modperl_handler_t *modperl_handler_new_from_sv(pTHX_ apr_pool_t *p, SV *sv);
-MP_INLINE const char *modperl_handler_name(modperl_handler_t *handler);
+const char *modperl_handler_name(modperl_handler_t *handler);
int modperl_handler_resolve(pTHX_ modperl_handler_t **handp,
apr_pool_t *p, server_rec *s);
i.e. to build the ‘modperl_handler_name’ without the inline directive, so that it actually gets built into the object file. But I can’t figure out how to add this patch into the spec file so that it gets applied during the build.
Copy the patch file to the checkout directory and run “osc add filename.patch” to add it to the project. (or click on “Add File” in the web interface and upload the patch file to your branch)
Add a “PatchX: filename.patch” line to the spec file (in the header, e.g. below the last SourceX: line), and then apply it with the “%patchX” macro in the %prep section.
See also e.g. http://www.tldp.org/HOWTO/RPM-HOWTO/build.html or the link I offered previously.
And don’t forget to add a changelog entry to the xxx.changes file before you submit back. You can use “osc vc” to do that, or click on the filename in the web interface to edit it and then on “Insert changes template” to add an empty changes line which you should modify accordingly.
You should mention every added patch there, by something like “add filename.patch to fix build on Factory”…
PS: Maybe the thread would be better placed in the Development->“Open Build Service (OBS)” subforum I suppose. Should we move it?
The build seems to run now that I have done the ‘osc add’
By all means move this thread to a more appropriate place. Please put a stub thread here pointing to the new place so I can find it again !
There were more symbols declared ‘inline’ in that file which got deleted by the compiler; I took the ‘inline’ off those too, but now I am getting
133s] waiting 720 seconds for server to start: .httpd-prefork: Syntax error on line 85 of /home/abuild/rpmbuild/BUILD/httpd24/t/conf/httpd.conf: Cannot load /home/abuild/rpmbuild/BUILD/httpd24/src/modules/perl/mod_perl.so into server: /home/abuild/rpmbuild/BUILD/httpd24/src/modules/perl/mod_perl.so: undefined symbol: modperl_wbucket_flush
Is it a matter of chasing these down one by one ? Or can someone who knows ‘mod_perl’ knock them out all in one go ?
Will be moved to OpenBuild Servic and is CLOSED for the moment.