Re: rawhide in mirrors.fedoraproject.org
Thank you Florian. I'll chat with my peers on this. Carol On Tue, Aug 3, 2021 at 3:41 PM Florian Weimer wrote: > * Carol Bouchard: > > > I have test scripts upstream which runs UTs and valgrind checks for > rawhide. Recently they > > broke due to the following error and similar with > mirrors.fedoraproject.org: > > > > Fedora rawhide openh264 (From Cisco) - x86_64 0.0 B/s | 0 B 00:00 - Curl > error (6): > > Couldn't resolve host name for > > > https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide=x86_64 > > [getaddrinfo() thread failed to start] > > > > I have no issues with doing the curl locally in redhat. Issue seems to > > be upstream in github. Any ideas what changed? Can this be fixed? > > Github declined to fix it for now: > > Docker seccomp policy incompatible with glibc 2.34 > <https://github.com/actions/virtual-environments/issues/3812> > > I assume they are waiting for a new moby release with this fix: > > seccomp: add support for "clone3" syscall in default policy > <https://github.com/moby/moby/pull/42681> > > The fix will not be backported apparently, so I don't know how long that > will take. > > There may be some tweaks to get Github Actions going again, depending on > what you actually use. In some cases, it's possible to run the docker > command with the --security-opt seccomp=unconfined option. Without > seccomp filters, there are no seccomp-related problems. > > Thanks, > Florian > > ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
rawhide in mirrors.fedoraproject.org
I have test scripts upstream which runs UTs and valgrind checks for rawhide. Recently they broke due to the following error and similar with mirrors.fedoraproject.org: Fedora rawhide openh264 (From Cisco) - x86_64 0.0 B/s | 0 B 00:00 - Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-rawhide=x86_64 [getaddrinfo() thread failed to start] I have no issues with doing the curl locally in redhat. Issue seems to be upstream in github. Any ideas what changed? Can this be fixed? Carol ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 33 fails upgrade for rcm-tools-fedora-rpms
This is possible. I've been having issues with my laptop and booted a number of times. I am fine now. TY Carol On Mon, Mar 22, 2021 at 7:49 PM Peter Robinson wrote: > On Mon, Mar 22, 2021 at 11:34 PM Carol Bouchard > wrote: > > > > I saw this error just before my upgrade to fedora33 and I'm now seeing > it after the > > upgrade. How do I fix this since I need brew to work? > > Given it can't resolve the host I'm guessing you're not on the VPN, or > else it's not querying the DNS servers provided by the VPN for > internal hosts. > > > Before Upgrade: > > CM Tools for Fedora 33 (RPMs) 0.0 B/s | 0 B > 00:00 > > Errors during downloading metadata for repository > 'rcm-tools-fedora-rpms': > > - Curl error (6): Couldn't resolve host name for > https://download.devel.redhat.com/rel-eng/RCMTOOLS/latest-RCMTOOLS-2-F-33/compose/Everything/x86_64/os/repodata/repomd.xml > [Could not resolve host: download.devel.redhat.com] > > Error: Failed to download metadata for repo 'rcm-tools-fedora-rpms': > Cannot download repomd.xml: Cannot download repodata/repomd.xml: All > mirrors were tried > > Ignoring repositories: rcm-tools-fedora-rpms > > > > After Upgrade: > > $sudo yum install brew > > [sudo] password for cbouchar: > > RCM Tools for Fedora 33 (RPMs) > 0.0 B/s | 0 B 00:00 > > Errors during downloading metadata for repository > 'rcm-tools-fedora-rpms': > > - Curl error (6): Couldn't resolve host name for > https://download.devel.redhat.com/rel-eng/RCMTOOLS/latest-RCMTOOLS-2-F-33/compose/Everything/x86_64/os/repodata/repomd.xml > [Could not resolve host: download.devel.redhat.com] > > Error: Failed to download metadata for repo 'rcm-tools-fedora-rpms': > Cannot download repomd.xml: Cannot download repodata/repomd.xml: All > mirrors were tried > > ___ > > 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 > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 33 fails upgrade for rcm-tools-fedora-rpms
I saw this error just before my upgrade to fedora33 and I'm now seeing it after the upgrade. How do I fix this since I need brew to work? Before Upgrade: CM Tools for Fedora 33 (RPMs) 0.0 B/s | 0 B 00:00 Errors during downloading metadata for repository 'rcm-tools-fedora-rpms': - Curl error (6): Couldn't resolve host name for https://download.devel.redhat.com/rel-eng/RCMTOOLS/latest-RCMTOOLS-2-F-33/compose/Everything/x86_64/os/repodata/repomd.xml [Could not resolve host: download.devel.redhat.com] Error: Failed to download metadata for repo 'rcm-tools-fedora-rpms': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried Ignoring repositories: rcm-tools-fedora-rpms After Upgrade: $sudo yum install brew [sudo] password for cbouchar: RCM Tools for Fedora 33 (RPMs) 0.0 B/s | 0 B 00:00 Errors during downloading metadata for repository 'rcm-tools-fedora-rpms': - Curl error (6): Couldn't resolve host name for https://download.devel.redhat.com/rel-eng/RCMTOOLS/latest-RCMTOOLS-2-F-33/compose/Everything/x86_64/os/repodata/repomd.xml [Could not resolve host: download.devel.redhat.com] Error: Failed to download metadata for repo 'rcm-tools-fedora-rpms': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
Thank you for the details Daniel! On Mon, Mar 15, 2021 at 10:22 AM Daniel P. Berrangé wrote: > On Mon, Mar 15, 2021 at 10:16:58AM -0400, Carol Bouchard wrote: > > Since Fedora is also making the change, I'm wondering whether this voice > > should also > > be heard. They're assuming it's just GLib. > > Fedora isn't making a change on its own. Fedora has simply pulled in > the latest version of GLibC that contains the change. It will affect > any distro which subsequently pulls in this GLibC code, which is > pretty much all of them eventually. > > Regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org-o- > https://www.instagram.com/dberrange :| > > ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
Since Fedora is also making the change, I'm wondering whether this voice should also be heard. They're assuming it's just GLib. Carol On Mon, Mar 15, 2021 at 10:09 AM Daniel P. Berrangé wrote: > On Mon, Mar 15, 2021 at 09:50:18AM -0400, Carol Bouchard wrote: > > Hi Daniel and other Fedora experts: > > > > I'm trying to get the m4 package to change their code. They're saying > this > > is not POSIX > > compliant change so they are resisting. See below snippet. I don't have > > the > > background to this change to answer their questions. Is someone with this > > background willing to jump onto the email thread to move forward with > this? > > Let me know and I'll add you to the thread. Also I told them it's not a > > glib > > change only that Fedora is also moving in this direction but my comments > > got lost in the thread. > > Looking at this thread: > > https://lists.gnu.org/archive/html/bug-m4/2021-03/msg0.html > > it appears that all the right people I'd expect are already involved > in the discussion from the GLibC / Gnulib side. > > Regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org-o- > https://www.instagram.com/dberrange :| > > ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
Hi Daniel and other Fedora experts:
I'm trying to get the m4 package to change their code. They're saying this
is not POSIX
compliant change so they are resisting. See below snippet. I don't have
the
background to this change to answer their questions. Is someone with this
background willing to jump onto the email thread to move forward with this?
Let me know and I'll add you to the thread. Also I told them it's not a
glib
change only that Fedora is also moving in this direction but my comments
got lost in the thread.
> > I can open a defect against POSIX if we decide that is needed, but want
> > some consensus first on whether it is glibc's change that went too far,
> > or POSIX's requirements that are too restrictive for what glibc wants
to do.
> Here are a couple of questions, to understand the motivation and the
possible
> alternative solutions to the problem:
>
> 1) As far as I understand, the issue occurs with certain x86 or x86_64
>processors.
>
>1.1) What has been the value of MINSIGSTKSZ on x86 and x86_64 so far?
>1.2) What value of MINSIGSTKSZ is needed for AVX-512F support?
>1.3) Will the trend to larger MINSIGSTKSZ values continue for Intel
> processors?
On Thu, Mar 4, 2021 at 8:04 AM Daniel P. Berrangé
wrote:
> On Thu, Mar 04, 2021 at 07:02:27AM -0500, Carol Bouchard wrote:
> > It's going to require more than removing the hack due to the following:
> >
> > /* Storage for the alternate signal stack. */
> > static union
> > {
> > char buffer[SIGSTKSZ];
> >
> > /* These other members are for proper alignment. There's no
> > standard way to guarantee stack alignment, but this seems enough
> > in practice. */
> > long double ld;
> > long l;
> > void *p;
> > } alternate_signal_stack;
>
> A "simple" option is to just stop using SIGSTKSZ here, and define
> your own constant - pick it based on worst case real world SIGSTKSZ
> that you'll expect. Perhaps stick in an assert in the code too, to
> abort the process at runtime if the real value is larger.
>
> A alternative solution is to stop statically allocating the
> struct and instead malloc it at startup. If there's no convenient
> place todo the alloc, you could possibly use an __attribute__(constructor)
> function that will get invoked by the dyn loader at startup for you,
> before main() even runs.
>
> Regards,
> Daniel
> --
> |: https://berrange.com -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-
> https://www.instagram.com/dberrange :|
>
>
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
I'm going to reach out to glib team. I wished all I had to do is remove
their preprocessor code but I don't think it is that simple.
I much appreciate your help on this issue.
Carol
On Thu, Mar 4, 2021 at 7:02 AM Carol Bouchard wrote:
> It's going to require more than removing the hack due to the following:
>
> /* Storage for the alternate signal stack. */
> static union
> {
> char buffer[SIGSTKSZ];
>
> /* These other members are for proper alignment. There's no
> standard way to guarantee stack alignment, but this seems enough
> in practice. */
> long double ld;
> long l;
> void *p;
> } alternate_signal_stack;
>
> On Thu, Mar 4, 2021 at 6:48 AM Carol Bouchard wrote:
>
>> Thank you. I may very well do that.
>>
>> Carol
>>
>> On Thu, Mar 4, 2021 at 4:57 AM Daniel P. Berrangé
>> wrote:
>>
>>> On Wed, Mar 03, 2021 at 03:13:29PM -0500, Carol Bouchard wrote:
>>> > In our code base (restraint), we patch and recompile the m4 code base.
>>> > https://github.com/tar-mirror/gnu-m4
>>> > In their code, they have the following which fails to compile when
>>> SIGSTKSZ
>>> > < 16384 is interpreted.
>>> > This is going to be a challenge to make work.
>>> >
>>> > # define SIGSTKSZ 8192
>>> > #ifndef SIGSTKSZ
>>> > # define SIGSTKSZ 16384
>>> > #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
>>> > /* libsigsegv 2.6 through 2.8 have a bug where some architectures use
>>> >more than the Linux default of an 8k alternate stack when deciding
>>> >if a fault was caused by stack overflow. */
>>> > # undef SIGSTKSZ
>>> > # define SIGSTKSZ 16384
>>> > #endif
>>>
>>> AFAICT libsigsegv 2.8 is a release dating from 2009, obsoleted by the
>>> 2.9 release in 2010.
>>>
>>> I'd question whether this code really need to workaround a bug in
>>> something that is 11 years old.
>>>
>>> IOW, I'd suggest just deleting this hack entirely.
>>>
>>>
>>> Regards,
>>> Daniel
>>> --
>>> |: https://berrange.com -o-
>>> https://www.flickr.com/photos/dberrange :|
>>> |: https://libvirt.org -o-
>>> https://fstop138.berrange.com :|
>>> |: https://entangle-photo.org-o-
>>> https://www.instagram.com/dberrange :|
>>>
>>>
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
It's going to require more than removing the hack due to the following:
/* Storage for the alternate signal stack. */
static union
{
char buffer[SIGSTKSZ];
/* These other members are for proper alignment. There's no
standard way to guarantee stack alignment, but this seems enough
in practice. */
long double ld;
long l;
void *p;
} alternate_signal_stack;
On Thu, Mar 4, 2021 at 6:48 AM Carol Bouchard wrote:
> Thank you. I may very well do that.
>
> Carol
>
> On Thu, Mar 4, 2021 at 4:57 AM Daniel P. Berrangé
> wrote:
>
>> On Wed, Mar 03, 2021 at 03:13:29PM -0500, Carol Bouchard wrote:
>> > In our code base (restraint), we patch and recompile the m4 code base.
>> > https://github.com/tar-mirror/gnu-m4
>> > In their code, they have the following which fails to compile when
>> SIGSTKSZ
>> > < 16384 is interpreted.
>> > This is going to be a challenge to make work.
>> >
>> > # define SIGSTKSZ 8192
>> > #ifndef SIGSTKSZ
>> > # define SIGSTKSZ 16384
>> > #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
>> > /* libsigsegv 2.6 through 2.8 have a bug where some architectures use
>> >more than the Linux default of an 8k alternate stack when deciding
>> >if a fault was caused by stack overflow. */
>> > # undef SIGSTKSZ
>> > # define SIGSTKSZ 16384
>> > #endif
>>
>> AFAICT libsigsegv 2.8 is a release dating from 2009, obsoleted by the
>> 2.9 release in 2010.
>>
>> I'd question whether this code really need to workaround a bug in
>> something that is 11 years old.
>>
>> IOW, I'd suggest just deleting this hack entirely.
>>
>>
>> Regards,
>> Daniel
>> --
>> |: https://berrange.com -o-
>> https://www.flickr.com/photos/dberrange :|
>> |: https://libvirt.org -o-
>> https://fstop138.berrange.com :|
>> |: https://entangle-photo.org-o-
>> https://www.instagram.com/dberrange :|
>>
>>
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
Thank you. I may very well do that. Carol On Thu, Mar 4, 2021 at 4:57 AM Daniel P. Berrangé wrote: > On Wed, Mar 03, 2021 at 03:13:29PM -0500, Carol Bouchard wrote: > > In our code base (restraint), we patch and recompile the m4 code base. > > https://github.com/tar-mirror/gnu-m4 > > In their code, they have the following which fails to compile when > SIGSTKSZ > > < 16384 is interpreted. > > This is going to be a challenge to make work. > > > > # define SIGSTKSZ 8192 > > #ifndef SIGSTKSZ > > # define SIGSTKSZ 16384 > > #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384 > > /* libsigsegv 2.6 through 2.8 have a bug where some architectures use > >more than the Linux default of an 8k alternate stack when deciding > >if a fault was caused by stack overflow. */ > > # undef SIGSTKSZ > > # define SIGSTKSZ 16384 > > #endif > > AFAICT libsigsegv 2.8 is a release dating from 2009, obsoleted by the > 2.9 release in 2010. > > I'd question whether this code really need to workaround a bug in > something that is 11 years old. > > IOW, I'd suggest just deleting this hack entirely. > > > Regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org-o- > https://www.instagram.com/dberrange :| > > ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
In our code base (restraint), we patch and recompile the m4 code base. https://github.com/tar-mirror/gnu-m4 In their code, they have the following which fails to compile when SIGSTKSZ < 16384 is interpreted. This is going to be a challenge to make work. # define SIGSTKSZ 8192 #ifndef SIGSTKSZ # define SIGSTKSZ 16384 #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384 /* libsigsegv 2.6 through 2.8 have a bug where some architectures use more than the Linux default of an 8k alternate stack when deciding if a fault was caused by stack overflow. */ # undef SIGSTKSZ # define SIGSTKSZ 16384 #endif On Wed, Mar 3, 2021 at 3:05 PM Florian Weimer wrote: > * Carol Bouchard: > > > Thank you Daniel and Richard. I'm going to have to study this some to > > understand how this solves the compile issue cause the glibc code > > isn't gone. It's still there. > > SIGSTKSZ is no longer a (preprocessor) constant. If you use it in place > where a variable is expected, it works. But you can't use it in > preprocessor conditionals anymore. > > Thanks, > Florian > > ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora/f35 compile error
Thank you Daniel and Richard. I'm going to have to study this some to
understand how this solves the compile issue cause the glibc code isn't
gone. It's still there.
Carol
On Wed, Mar 3, 2021 at 11:31 AM Richard W.M. Jones
wrote:
> On Wed, Mar 03, 2021 at 02:24:35PM +, Daniel P. Berrangé wrote:
> > On Wed, Mar 03, 2021 at 09:07:48AM -0500, Carol Bouchard wrote:
> > > I'm seeing the following compile error in my product which I'm not
> seeing
> > > with earlier versions of Fedora.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > *make[4]: Entering directory
> > > '/builddir/build/BUILD/restraint-0.3.2/third-party/m4-1.4.18/lib' CC
> > > gl_avltree_oset.o CC binary-io.o CC c-ctype.o CC
> > > c-stack.oIn file included from /usr/include/signal.h:315,
> > > from ./signal.h:52, from c-stack.c:49:c-stack.c:55:26:
> > > error: missing binary operator before token "(" 55 | #elif
> > > HAVE_LIBSIGSEGV && SIGSTKSZ < 16384 |
> > > ^~~~*
> > >
> > > In earlier fedora versions, SIGSTKSZ is a numeric value. In rawhide,
> I'm
> > > seeing
> > > the following in file /usr/include/bits/sigstksz.h.
> > >
> > >
> > > */* Default stack size for a signal handler: sysconf (SC_SIGSTKSZ).
> */#
> > > undef SIGSTKSZ# define SIGSTKSZ sysconf (_SC_SIGSTKSZ)*
> > >
> > > This looks like an issue to be addressed in Fedora and not by applying
> a
> > > patch. Please advise.
> >
> > The glibc change was intentionale and unavoidable per this previous
> > thread:
> >
> >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/BR5DU2NSKRZAJHEUWOI4H6ZIQQNVAXAR/#JAEAW2T2YSEIRSB62ESBDLL62OBUSLXU
> >
> > So you'll need to patch the application so that it doesn't make an
> > assumption that SIGSTKSZ evaluates to a static constant.
>
> FWIW these were the two proposed fixes for this in OCaml (the second
> one was accepted). Not too bad, you just have to be aware that the
> structure can no longer be statically allocated:
>
>
> https://pagure.io/fedora-ocaml/c/dfb5e954a04f59b0456cc4c0ddf3acaf22e0ff07?branch=fedora-35-4.12.0
>
> https://github.com/ocaml/ocaml/pull/10266/files
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Fedora/f35 compile error
I'm seeing the following compile error in my product which I'm not seeing
with earlier versions of Fedora.
*make[4]: Entering directory
'/builddir/build/BUILD/restraint-0.3.2/third-party/m4-1.4.18/lib' CC
gl_avltree_oset.o CC binary-io.o CC c-ctype.o CC
c-stack.oIn file included from /usr/include/signal.h:315,
from ./signal.h:52, from c-stack.c:49:c-stack.c:55:26:
error: missing binary operator before token "(" 55 | #elif
HAVE_LIBSIGSEGV && SIGSTKSZ < 16384 |
^~~~*
In earlier fedora versions, SIGSTKSZ is a numeric value. In rawhide, I'm
seeing
the following in file /usr/include/bits/sigstksz.h.
*/* Default stack size for a signal handler: sysconf (SC_SIGSTKSZ). */#
undef SIGSTKSZ# define SIGSTKSZ sysconf (_SC_SIGSTKSZ)*
This looks like an issue to be addressed in Fedora and not by applying a
patch. Please advise.
Carol
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: ld core dumped with s390x architecture
Adding Tomas Kopecek into this discussion. On Fri, Nov 6, 2020 at 8:49 AM Petr Pisar wrote: > On Fri, Nov 06, 2020 at 08:33:09AM -0500, Carol Bouchard wrote: > > I reran my build and it is picking up the old version. Is this an issue > in > > brew/dist-git? Am I expected to change my > > Makefile and produce another release (doesn't seem reasonable)? > > https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=32922197 > > > I guess that's because there was no Rawhide compose since then and Brew > uses > Rawhide compose instead of Koji build repositories. Either way should > contact > Brew maintainers. This is a mailng list about Fedora project. Not about Red > Hat systems. > > -- 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 > ___ 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: ld core dumped with s390x architecture
Petr: I reran my build and it is picking up the old version. Is this an issue in brew/dist-git? Am I expected to change my Makefile and produce another release (doesn't seem reasonable)? https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=32922197 Carol On Fri, Nov 6, 2020 at 7:39 AM Carol Bouchard wrote: > Thank you Petr! > > On Fri, Nov 6, 2020 at 7:23 AM Petr Pisar wrote: > >> On Fri, Nov 06, 2020 at 07:10:09AM -0500, Carol Bouchard wrote: >> > I am a developer to Beaker Project which manages tests for various >> distros >> > such as >> > Fedora 34. I'm trying to build a restraint release and there exists an >> > build issue with >> > Architecture s390x. The error I'm seeing is as follows: >> > >> > collect2: fatal error: ld terminated with signal 11 [Segmentation >> > fault], core dumped >> > compilation terminated. >> > >> > A week earlier this was building cleanly and we've not made any changes >> in >> > this area. >> > The complete build can be found at: >> > https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=32901169 >> > >> >> Your failed build used a faulty binutils-2.35.1-11.fc34. The crash should >> be >> fixed in binutils-2.35.1-12.fc34 which has been available since Tuesday. >> You >> should update your system to receive the updated binutils pacakage. >> >> -- 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 >> > ___ 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: ld core dumped with s390x architecture
Thank you Petr! On Fri, Nov 6, 2020 at 7:23 AM Petr Pisar wrote: > On Fri, Nov 06, 2020 at 07:10:09AM -0500, Carol Bouchard wrote: > > I am a developer to Beaker Project which manages tests for various > distros > > such as > > Fedora 34. I'm trying to build a restraint release and there exists an > > build issue with > > Architecture s390x. The error I'm seeing is as follows: > > > > collect2: fatal error: ld terminated with signal 11 [Segmentation > > fault], core dumped > > compilation terminated. > > > > A week earlier this was building cleanly and we've not made any changes > in > > this area. > > The complete build can be found at: > > https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=32901169 > > > > Your failed build used a faulty binutils-2.35.1-11.fc34. The crash should > be > fixed in binutils-2.35.1-12.fc34 which has been available since Tuesday. > You > should update your system to receive the updated binutils pacakage. > > -- 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 > ___ 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
ld core dumped with s390x architecture
I am a developer to Beaker Project which manages tests for various distros such as Fedora 34. I'm trying to build a restraint release and there exists an build issue with Architecture s390x. The error I'm seeing is as follows: collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped compilation terminated. A week earlier this was building cleanly and we've not made any changes in this area. The complete build can be found at: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=32901169 Carol ___ 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
