Re: Pull requests for compat-gcc-34
23.02.2018 13:58 Jonathan Wakely wrote: > > > On 22/02/18 16:47 +0100, Rafal Luzynski wrote: > >15.02.2018 12:02 Rafal Luzynski wrote: > >> > >> > >> 9.02.2018 11:34 Rafal Luzynski wrote: > >> > [...] > >> > Please: > >> > - backport the solution to F26 and F27 as well, this should be much > >> > easier than in F28 (my pull requests may be helpful), > >> > - mark my pull requests as merged/obsolete/whatever is appropriate, > >> > - mark the bugzilla tickets as fixed (hopefully this is automatic). > >> > >> PING > >> > >> Any chance to fix compat-gcc-34 in F27 and F26 as well? Pull requests > >> have been waiting for about 1.5 months now. > > > >PING^2 > > Updates submitted for f26 and f27 now. Indeed. Thank you Jakub, I have not noticed. And thank you Jonathan for pushing it to bodhi, that made me notice the change. > You might have noticed the GCC maintainer is a bit busy with rawhide, > and compat-gcc-34 is not a high priority :-) True, I've noticed and that's why I have prepared the patches and asked in public anyone with sufficient privileges to accept them. Thank you everybody for your participation and I hope it is correct now. Regards, Rafal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Help needed with new segfaults in frame unwinding under gcc8
I'm sorry, for the first time in decades I actually hit the send key sequence (Ctrl-C Ctrl-C) accidentally. > "JJ" == Jakub Jelinek writes: JJ> Strangely, --enable-network to mock was really needed so that the JJ> first testsuite passes. That's absolutely bizarre. JJ> I can now get the coredumps, but I'm afraid I really need a way to JJ> reproduce it under gdb, from the core dump there isn't sufficient JJ> information available. I just now found a way. See below. JJ> So, what is this squatter process about, with what command line JJ> options is it invoked, how does it interact with other processes, is JJ> it single-threaded? It creates various search indices for the IMAP server (which is why it wraps Xapian). The manpage is available from https://cyrusimap.org/imap/reference/manpages/systemcommands/squatter.html Technically the test suite simply creates the conditions for it to do its work (in a randomly named directory) and then calls squatter directly. You should be able to see the arguments in the test suite's output. You can get down into the mock chroot and run tests manually: mock -r fedora-rawhide-x86_64 --shell and then enter: su - mockbuild cd /builddir/build/BUILD/cyrus-imapd-3.0.5/cassandane export CYRUS_USER=$USER export LD_LIBRARY_PATH=/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc29.x86_64/usr/lib64 rm -rf work; mkdir work ./testrunner.pl -vvv -f pretty SearchFuzzy.xapianv2 (You may have to adjust LD_LIBRARY_PATH there; using a glob fails to work for me for reasons I don't understand.) That will run just one test. Down in the log you'll see something like: => Instance[1506] Running: "/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/sbin/squatter" "-C" "/builddir/build/BUILD/cyrus-imapd-3.0.5/cassandane/work/2322151/conf/imapd.conf" A bit further you see the output from that process: 2322151/squatter[50141]: SQL backend defaulting to engine 'pgsql' 2322151/squatter[50141]: indexing mailboxes 2322151/squatter[50141]: indexing mailbox user.cassandane... and at that point it segfaults. If at this point you "rm -rf work/224058I1/search" (to clear out the partially created search database) and then run: /builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/sbin/squatter -C work/2322151/conf/imapd.conf you should see the same segfault. For me it does still segfault when run under gdb, though you will have to delete that "search" directory each time or the process won't fail. JJ> What I can see is that the exc passed to _Unwind_Resume points to JJ> some memory inside of the xapian_dbw_open C++ function's stack frame JJ> which indeed contains multiple try/catch blocks, even nested ones; That's about as far as I have been able to comprehend. Just to be sure, I have done builds with fedora-rpm-macros and glibc rolled back to the versions January 21 (the last successful koschei build) and sadly things still fail in the same way. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: 389-ds-base and freeipa on 32 bit arches
On Fri, Feb 23, 2018 at 12:32 PM, Jeff Law wrote: > The fact that the 389-ds code works on other architectures does not > allow us to draw any conclusions at this point. > Can you give any more details on 32-bit ARM in particular -- is it just i686 that is experiencing issues, or have you seen similar memory corruption issues on 32-bit ARM as well? -- Jared Smith ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Help needed with new segfaults in frame unwinding under gcc8
I'm sorry, for the first time in decades I actually hit the send key sequence (Ctrl-C Ctrl-C) accidentally. > "JJ" == Jakub Jelinek writes: JJ> Strangely, --enable-network to mock was really needed so that the JJ> first testsuite passes. That's absolutely bizarre. JJ> I can now get the coredumps, but I'm afraid I really need a way to JJ> reproduce it under gdb, from the core dump there isn't sufficient JJ> information available. I just now found a way. See below. JJ> So, what is this squatter process about, with what command line JJ> options is it invoked, how does it interact with other processes, is JJ> it single-threaded? It creates various search indices for the IMAP server (which is why it wraps Xapian). The manpage is available from https://cyrusimap.org/imap/reference/manpages/systemcommands/squatter.html Technically the test suite simply creates the conditions for it to do its work (in a randomly named directory) and then calls squatter directly. You should be able to see the arguments in the test suite's output. You can get down into the mock chroot and run tests manually: mock -r fedora-rawhide-x86_64 --shell and then enter: su - mockbuild cd /builddir/build/BUILD/cyrus-imapd-3.0.5/cassandane export CYRUS_USER=$USER export LD_LIBRARY_PATH=/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc29.x86_64/usr/lib64 rm -rf work; mkdir work ./testrunner.pl -vvv -f pretty SearchFuzzy.xapianv2 (You may have to adjust LD_LIBRARY_PATH there; using a glob fails to work for me for reasons I don't understand.) That will run just one test. Down in the log you'll see something like: => Instance[1506] Running: "/builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/sbin/squatter" "-C" "/builddir/build/BUILD/cyrus-imapd-3.0.5/cassandane/work/2322151/conf/imapd.conf" A bit further you see the output from that process: 2322151/squatter[50141]: SQL backend defaulting to engine 'pgsql' 2322151/squatter[50141]: indexing mailboxes 2322151/squatter[50141]: indexing mailbox user.cassandane... and at that point it segfaults. If at this point you "rm -rf work/224058I1/search" (to clear out the partially created search database) and then run: /builddir/build/BUILDROOT/cyrus-imapd-3.0.5-4.fc28.x86_64/usr/sbin/squatter -C work/2322151/conf/imapd.conf you should see the same segfault. For me it does still segfault when run under gdb, though you will have to delete that "search" directory each time or the process won't fail. JJ> What I can see is that the exc passed to _Unwind_Resume points to JJ> some memory inside of the xapian_dbw_open C++ function's stack frame JJ> which indeed contains multiple try/catch blocks, even nested ones; That's about as far as I have been able to comprehend. Just to be sure, I have done builds with fedora-rpm-macros and glibc rolled back to the versions January 21 (the last successful koschei build) and sadly things still fail in the same way. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Help needed with new segfaults in frame unwinding under gcc8
> "JJ" == Jakub Jelinek writes: JJ> Strangely, --enable-network to mock was really needed so that the JJ> first testsuite passes. That's absolutely bizarre. JJ> I can now get the coredumps, but I'm afraid I really need a way to JJ> reproduce it under gdb, from the core dump there isn't sufficient JJ> information available. And unfortunately I haven't been able to create one. So, what is this squatter process about, JJ> with what command line options is it invoked, how does it interact JJ> with other processes, is it single-threaded? JJ> What I can see is that the exc passed to _Unwind_Resume points to JJ> some memory inside of the xapian_dbw_open C++ function's stack frame JJ> which indeed contains multiple try/catch blocks, even nested ones; JJ> but I find it strange that _Unwind_Exception objects would be on the JJ> stack, they should be in malloced objects (at the end of JJ> __cxa_exception e.g. for C++ exceptions), or come from the emergency JJ> pool if malloc would fail (unlikely in this case). The JJ> _Unwind_Exception contains completely bogus values not just in one JJ> field, but in all of them. JJ> Jakub JJ> ___ devel mailing list JJ> -- devel@lists.fedoraproject.org To unsubscribe send an email to JJ> devel-le...@lists.fedoraproject.org -- Jason L Tibbitts III - ti...@math.uh.edu - 713/743-3486 - 660PGH System Manager: University of Houston Department of Mathematics ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Pagure - Can't remove yourself from a project if not an admin?
On Mon, Feb 19, 2018 at 2:35 AM, Pierre-Yves Chibon wrote: > > Maybe I could help you in the mean time, feel free to ask. Thanks for the offer but I emailed one of the admins and got myself removed. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Help needed with new segfaults in frame unwinding under gcc8
Some more information: I looked through the Koschei logs for this package and it seemed it actually started failing before gcc8 went in. Specifically, the first failed build was on January 22, and the changes for that run were: mariadb-devel 3:10.2.12-2.fc28 -> 3:10.2.12-3.fc28 binutils 2.29.1-12.fc28 -> 2.29.1-13.fc28 glibc-common 2.26.9000-46.fc28 -> 2.26.9000-48.fc28 perl-DateTime-TimeZone 2.15-1.fc28-> 2.16-1.fc28 libxcrypt 4.0.0-0.203.2018012... -> 4.0.0-0.204.2018012... glibc 2.26.9000-46.fc28 -> 2.26.9000-48.fc28 netpbm-progs 10.81.00-1.fc28-> 10.81.00-2.fc28 glibc-devel2.26.9000-46.fc28 -> 2.26.9000-48.fc28 libxcrypt-devel4.0.0-0.203.2018012... -> 4.0.0-0.204.2018012... netpbm 10.81.00-1.fc28-> 10.81.00-2.fc28 ca-certificates2017.2.20-5.fc28 -> 2017.2.20-6.fc28 glibc-headers 2.26.9000-46.fc28 -> 2.26.9000-48.fc28 libnsl 2.26.9000-46.fc28 -> 2.26.9000-48.fc28 glibc-all-langpacks2.26.9000-46.fc28 -> 2.26.9000-48.fc28 perl-IO-Socket-SSL 2.052-1.fc28 -> 2.054-1.fc28 redhat-rpm-config 79-1.fc28 -> 84-1.fc28 The glibc and redhat-rpm-config updates are most interesting as the latter changed the default compiler flags. Unfortunately the log is no longer available, nor is any log from any koschei run previous to gcc8 landing. So I have more to investigate, including trying to roll back the redhat-rpm-config changes. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Help needed with new segfaults in frame unwinding under gcc8
On Fri, Feb 23, 2018 at 02:17:34PM -0600, Jason L Tibbitts III wrote: > > "JJ" == Jakub Jelinek writes: > > JJ> Well, I'm seeing > [...] > > So that's the first of the two test suites, which I've seen fail before > but I haven't invested any time into debugging it. It's completely > unrelated to any of the failures I'm talking about. > > You can just remove or comment the line "make check || exit 1" in the > spec to skip that test suite and get down to the one that crashes. > > JJ> Does it need networking outside of the mock (i.e. shall I retry with > JJ> --enable-networking)? > > There should be no need; it certainly doesn't need networking. That's > just a cunit-based test suite and outside of a couple of cases where I > was randomly trying things to get better debugging for the unwinder > segfault at hand, I've not had any real problems with it. Strangely, --enable-network to mock was really needed so that the first testsuite passes. I can now get the coredumps, but I'm afraid I really need a way to reproduce it under gdb, from the core dump there isn't sufficient information available. So, what is this squatter process about, with what command line options is it invoked, how does it interact with other processes, is it single-threaded? What I can see is that the exc passed to _Unwind_Resume points to some memory inside of the xapian_dbw_open C++ function's stack frame which indeed contains multiple try/catch blocks, even nested ones; but I find it strange that _Unwind_Exception objects would be on the stack, they should be in malloced objects (at the end of __cxa_exception e.g. for C++ exceptions), or come from the emergency pool if malloc would fail (unlikely in this case). The _Unwind_Exception contains completely bogus values not just in one field, but in all of them. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Help needed with new segfaults in frame unwinding under gcc8
> "JJ" == Jakub Jelinek writes: JJ> Well, I'm seeing [...] So that's the first of the two test suites, which I've seen fail before but I haven't invested any time into debugging it. It's completely unrelated to any of the failures I'm talking about. You can just remove or comment the line "make check || exit 1" in the spec to skip that test suite and get down to the one that crashes. JJ> Does it need networking outside of the mock (i.e. shall I retry with JJ> --enable-networking)? There should be no need; it certainly doesn't need networking. That's just a cunit-based test suite and outside of a couple of cases where I was randomly trying things to get better debugging for the unwinder segfault at hand, I've not had any real problems with it. Thanks to tmz on IRC I have some independent verification of this (he gets the same failures) and have a way to reproduce this inside mock inside a docker container. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F29 System Wide Change: Enable dbus-broker
On Fri, Feb 16, 2018 at 12:13:15PM +0100, Jan Kurik wrote: > Proposed System Wide Change: Enable dbus-broker > https://fedoraproject.org/wiki/Changes/EnableDbusBroker What about renaming this to DbusBrokerAsTheDefaultDbusImplementation? "Enable" correctly describes the technical operation (systemctl invocation), but it isn't obvious just from the title that this is about replacing normal dbus daemon. > == Scope == > * Proposal owners: > ** Fix regressions. > ** Enabledbus-broker.service in system and user-global context of > systemd (via systemd presets). > ** Pull in dbus-broker package from dbus package. I'm not sure if this is the correct way to do this. People might want to install systems with just normal dbus (e.g. in containers or minimal installations). It'd be better to update comps [1] to pull in dbus-broker instead of dbus into @Standard. [Based on our preeliminary discussions] This replaces the system wide bus and user busses. What about the at-spi2 private dbus instance? Would dbus-broker be fast enough to change gdm to use the user bus? Do you have plans to replace this last use too? If dbus-broker becomes the default like described in the Change page, what other dependencies on dbus will remain? Since this is already testable [2], what about asking for testing on devel-announce@ and test-announce@ ? This is a pretty big change, and I don't we can make the decision to use this by default without widespread testing. [1] https://pagure.io/fedora-comps/blob/master/f/comps-f29.xml.in [2] https://fedoraproject.org/wiki/Changes/EnableDbusBroker#How_To_Test Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Help needed with new segfaults in frame unwinding under gcc8
On Fri, Feb 23, 2018 at 11:54:28AM -0600, Jason L Tibbitts III wrote:
> > "JJ" == Jakub Jelinek writes:
>
> JJ> Haven't managed to reproduce it, while there are some testsuite
> JJ> failures, they are due to timeouts and e.g. dmesg doesn't show any
> JJ> segvs nor traps.
>
> Of course I can reproduce this easily and it also happens in the
> buildsystem. The first failure after the gcc update is
> https://koji.fedoraproject.org/koji/taskinfo?taskID=25054443 Note that
> it fails on all architectures except for s390x, and that succeeds only
> because the test suite is disabled there.
Well, I'm seeing
Suite: backend
Test: badhost ...FAILED
1. cunit/unit.c:133 - CU_FAIL_FATAL("Code under test timed out")
Test: badservice ...
unit: code under test
(/builddir/build/BUILD/cyrus-imapd-3.0.5/cunit/backend.testc:test_badhost)
timed out
passed
Test: sasl_plain ...FAILED
1. cunit/unit.c:133 - CU_FAIL_FATAL("Code under test timed out")
Test: sasl_digestmd5 ...
unit: code under test
(/builddir/build/BUILD/cyrus-imapd-3.0.5/cunit/backend.testc:test_sasl_plain)
timed out
FAILED
and many others, supposedly the issue you have is after this make check
and thus my mock build doesn't even reach there.
Does it need networking outside of the mock (i.e. shall I retry with
--enable-networking)?
Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Help needed with new segfaults in frame unwinding under gcc8
> "JJ" == Jakub Jelinek writes: JJ> Haven't managed to reproduce it, while there are some testsuite JJ> failures, they are due to timeouts and e.g. dmesg doesn't show any JJ> segvs nor traps. Of course I can reproduce this easily and it also happens in the buildsystem. The first failure after the gcc update is https://koji.fedoraproject.org/koji/taskinfo?taskID=25054443 Note that it fails on all architectures except for s390x, and that succeeds only because the test suite is disabled there. Of course something could have changed in rawhide between now and when I did this last night, so I'll rerun everything. But I did do aw scratch build (with an abbreviated test suite run) still shows the failures which can be viewed here: https://koji.fedoraproject.org/koji/taskinfo?taskID=25261672 Not that it's useful to you unless you can get the cores out of koji. (The s390x build fails for different reasons.) - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: libtool and LDFLAGS build flags injection
The package is slurm and the issue is their plugins. It's a deep architectural problem unfortunately,To summarize the issue briefly: When designing a plugin system, the services a plugin providesought not depend on the environment that loads it. That is not the case for slurm. Their pluginscontain symbols that refer back to the program that loads them. Suppose you have a plugin P loaded by programs A and B. Slurm's plugins often contain symbols a in A and b in B. When program A loads plugin P, the symbols b remain unresolved. When program B loads plugin P, the symbols a remain unresolved. I have spent hours supplying complex patches for them to "harden" and meet the bind now requirement,They acknowledge the problem but do not have enough customers complaining about it yet. Slurm issoftware deployed in large HPC research centers typically (hundred, thousands or more nodes). On Friday, February 23, 2018 12:26 PM, John Reiser wrote: Philip Kovacs wrote: > My particular concern is not "missing" bind now flags in the elf objects. I > am concerned about > making sure bind now is omitted because the package cannot operate with that > flag. Please tell us the name of the packages, and some indication of why the package does not work with BIND_NOW. Having specific information might help to identify and understand a more-general situation. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2018
On Fri, Feb 23, 2018 at 04:09:26PM +, Richard W.M. Jones wrote: > On Thu, Feb 22, 2018 at 06:49:02PM +0100, Marek Polacek wrote: > > libguestfs-1.37.35-2.fc28.src.rpm > > I'm not sure about these failures, but they don't seem to be GCC bugs. > > Is there a log file? The one I have says libvirt: XML-RPC error : Failed to connect socket to '/builddir/.cache/libvirt/libvirt-sock': No such file or directory libguestfs: error: could not connect to libvirt (URI = qemu:///session): Failed to connect socket to '/builddir/.cache/libvirt/libvirt-sock': No such file or directory [code=38 int1=2] libguestfs: trace: launch = -1 (error) libguestfs: trace: close libguestfs: closing guestfs handle 0x5646f5406a40 (state 0) libguestfs: command: run: rm libguestfs: command: run: \ -rf /builddir/build/BUILD/libguestfs-1.37.35/tmp/libguestfsfTNsVu make: *** [Makefile:2906: quickcheck] Error 1 so it's probably another networking issue in mock. Marek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: 389-ds-base and freeipa on 32 bit arches
On 02/23/2018 10:29 AM, Alexander Bokovoy wrote: > On pe, 23 helmi 2018, Jeff Law wrote: >> On 02/23/2018 09:58 AM, Randy Barlow wrote: >>> Greetings gcc maintainers! >>> >>> A FESCo issue[0] has been filed due to the dropping of 389-ds-base and >>> freeipa on 32 bit arches for Fedora 28. This was done without a change >>> request being filed, so FESCo is trying to decide how best to handle it. >>> >>> It seems there are some concerns about whether the C tooling correctly >>> handles some cases for 32-bit arches that led to the decision by the IPA >>> maintainers to drop support for 32-bit. FESCo would like to ask for the >>> GCC maintainers' input on the issue. >>> >>> Thanks in advance for your feedback! >> GCC, binutils, etc all support 32-bit arches just fine. THe current >> thinking is there are serious concurrency concerns in the freeipa code >> which are leading to the failures they were seeing on 32 bit platforms >> (i686 in particular). > To be clear there are concerns in 389-ds code that lead to data > corruptions on i686. They aren't seen on other 32-bit platforms Fedora > supports according to 389-ds developers. Sorry to mis-characterize the problem. It's the 389-ds code with the concurrency concerns, not freeipa. The fact that the 389-ds code works on other architectures does not allow us to draw any conclusions at this point. It really needs to go through a root cause analysis to determine exactly why it is not working correctly. That will in turn tell us if it's the 389-ds code or something in the compiler (or elsewhere) that is the problem. Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: 389-ds-base and freeipa on 32 bit arches
On pe, 23 helmi 2018, Jeff Law wrote: On 02/23/2018 09:58 AM, Randy Barlow wrote: Greetings gcc maintainers! A FESCo issue[0] has been filed due to the dropping of 389-ds-base and freeipa on 32 bit arches for Fedora 28. This was done without a change request being filed, so FESCo is trying to decide how best to handle it. It seems there are some concerns about whether the C tooling correctly handles some cases for 32-bit arches that led to the decision by the IPA maintainers to drop support for 32-bit. FESCo would like to ask for the GCC maintainers' input on the issue. Thanks in advance for your feedback! GCC, binutils, etc all support 32-bit arches just fine. THe current thinking is there are serious concurrency concerns in the freeipa code which are leading to the failures they were seeing on 32 bit platforms (i686 in particular). To be clear there are concerns in 389-ds code that lead to data corruptions on i686. They aren't seen on other 32-bit platforms Fedora supports according to 389-ds developers. FreeIPA has no choice as 389-ds-base was moved to exclude i686 architecture according to the process defined in Fedora. -- / Alexander Bokovoy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: libtool and LDFLAGS build flags injection
Philip Kovacs wrote: My particular concern is not "missing" bind now flags in the elf objects. I am concerned about making sure bind now is omitted because the package cannot operate with that flag. Please tell us the name of the packages, and some indication of why the package does not work with BIND_NOW. Having specific information might help to identify and understand a more-general situation. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Help needed with new segfaults in frame unwinding under gcc8
On Fri, Feb 23, 2018 at 10:56:47AM -0600, Jason L Tibbitts III wrote: > > "JJ" == Jakub Jelinek writes: > > JJ> Can I get detailed info on how to reproduce this (most importantly, > JJ> which src.rpm you are trying to build)? > > Sorry, that was all in the original message. > > The package is cyrus-imapd; all you have to do is check it out and do > fedpkg mockbuild (on the rawhide branch). The test suite should > generate 22 core files, each of which should give a mostly identical > backtrace. Unfortunately I can't get the crash to happen when running > outside of mock. I also can't get it when directly executing the > crashing program while inside the chroot (via mock --shell); it has to > be run by the test suite and in mock. I haven't yet been able to figure > out why. Haven't managed to reproduce it, while there are some testsuite failures, they are due to timeouts and e.g. dmesg doesn't show any segvs nor traps. This was with mock -r fedora-rawhide-x86_64 ./cyrus-imapd-3.0.5-3.fc28.src.rpm Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: 389-ds-base and freeipa on 32 bit arches
On 02/23/2018 09:58 AM, Randy Barlow wrote: > Greetings gcc maintainers! > > A FESCo issue[0] has been filed due to the dropping of 389-ds-base and > freeipa on 32 bit arches for Fedora 28. This was done without a change > request being filed, so FESCo is trying to decide how best to handle it. > > It seems there are some concerns about whether the C tooling correctly > handles some cases for 32-bit arches that led to the decision by the IPA > maintainers to drop support for 32-bit. FESCo would like to ask for the > GCC maintainers' input on the issue. > > Thanks in advance for your feedback! GCC, binutils, etc all support 32-bit arches just fine. THe current thinking is there are serious concurrency concerns in the freeipa code which are leading to the failures they were seeing on 32 bit platforms (i686 in particular). Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: libtool and LDFLAGS build flags injection
My particular concern is not "missing" bind now flags in the elf objects. I am concerned aboutmaking sure bind now is omitted because the package cannot operate with that flag. On Friday, February 23, 2018 11:35 AM, Florian Weimer wrote: On 02/23/2018 05:16 PM, Philip Kovacs wrote: > The bind now issue is a real problem for some packages. I have interacted > with upstream countlesstimes on it and simply lost the fight. Please, > whatever you do, leave some route to disable bind now. Disable it for what? The vast majority of missing BIND_NOW flags has been caused by accidentally dropped LDFLAGS settings. (That, and firmware files which happen to be ELF.) Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
389-ds-base and freeipa on 32 bit arches
Greetings gcc maintainers! A FESCo issue[0] has been filed due to the dropping of 389-ds-base and freeipa on 32 bit arches for Fedora 28. This was done without a change request being filed, so FESCo is trying to decide how best to handle it. It seems there are some concerns about whether the C tooling correctly handles some cases for 32-bit arches that led to the decision by the IPA maintainers to drop support for 32-bit. FESCo would like to ask for the GCC maintainers' input on the issue. Thanks in advance for your feedback! [0] https://pagure.io/fesco/issue/1845 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1544386 signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Help needed with new segfaults in frame unwinding under gcc8
> "JJ" == Jakub Jelinek writes: JJ> Can I get detailed info on how to reproduce this (most importantly, JJ> which src.rpm you are trying to build)? Sorry, that was all in the original message. The package is cyrus-imapd; all you have to do is check it out and do fedpkg mockbuild (on the rawhide branch). The test suite should generate 22 core files, each of which should give a mostly identical backtrace. Unfortunately I can't get the crash to happen when running outside of mock. I also can't get it when directly executing the crashing program while inside the chroot (via mock --shell); it has to be run by the test suite and in mock. I haven't yet been able to figure out why. To get the test suite run before rpm strips out all of the debug information, you can just delete the %check line from the spec before building. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: unresponsive maintainer procedure for konradm (Conrad Meyer)
On Fri, Feb 23, 2018 at 08:34:34AM -0800, Conrad Meyer wrote: > On Fri, Feb 23, 2018 at 8:16 AM, Zbigniew Jędrzejewski-Szmek > wrote: > > If anyone knows how to contact Conrad Meyer / konradm, please do so. > > > > Today one package owned by konradm, xchat-ruby, was retired as a result > > of a FESCo ticket [1]. The remaining ones will be orphaned in two weeks > > if there is no response. > > > > [1] https://pagure.io/fesco/issue/1847 > > > Hi Zbigniew, > > This is the very first email I've gotten on the subject. I'm > definitely still around. I don't think the @tylerc.org address is > still active, but I believe I changed my email address in all of the > relevant project places. Maybe not? Hi, it's great that this got resolved so quickly. Welcome back ;) Please update your e-mail in FAS: https://admin.fedoraproject.org/accounts/user/view/konradm. I see that bugzilla is using a different address, so that's good. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: unresponsive maintainer procedure for konradm (Conrad Meyer)
On Fri, Feb 23, 2018 at 8:16 AM, Zbigniew Jędrzejewski-Szmek wrote: > If anyone knows how to contact Conrad Meyer / konradm, please do so. > > Today one package owned by konradm, xchat-ruby, was retired as a result > of a FESCo ticket [1]. The remaining ones will be orphaned in two weeks > if there is no response. > > [1] https://pagure.io/fesco/issue/1847 Hi Zbigniew, This is the very first email I've gotten on the subject. I'm definitely still around. I don't think the @tylerc.org address is still active, but I believe I changed my email address in all of the relevant project places. Maybe not? Thanks, Conrad ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: libtool and LDFLAGS build flags injection
On 02/23/2018 05:16 PM, Philip Kovacs wrote: The bind now issue is a real problem for some packages. I have interacted with upstream countlesstimes on it and simply lost the fight. Please, whatever you do, leave some route to disable bind now. Disable it for what? The vast majority of missing BIND_NOW flags has been caused by accidentally dropped LDFLAGS settings. (That, and firmware files which happen to be ELF.) Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
unresponsive maintainer procedure for konradm (Conrad Meyer)
Hi, If anyone knows how to contact Conrad Meyer / konradm, please do so. Today one package owned by konradm, xchat-ruby, was retired as a result of a FESCo ticket [1]. The remaining ones will be orphaned in two weeks if there is no response. [1] https://pagure.io/fesco/issue/1847 Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: libtool and LDFLAGS build flags injection
The bind now issue is a real problem for some packages. I have interacted with upstream countlesstimes on it and simply lost the fight. Please, whatever you do, leave some route to disable bind now. On Friday, February 23, 2018 10:55 AM, Florian Weimer wrote: I've seen a fair amount of LDFLAGS injection failures related to libtool. For the most part, -specs=/usr/lib/rpm/redhat/redhat-hardened-ld is dropped, leading to a lack of BIND_NOW in the resulting binary. Is there a way we can fix this in libtool or the auto* tools? I'm also considering moving -Wl,-z,now to the command line from the GCC specs file, which might help here, too. But I'd prefer a direct, unfiltered channel from redhat-rpm-config to the linker invocation in case we need to inject additional flags. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2018
On Thu, Feb 22, 2018 at 06:49:02PM +0100, Marek Polacek wrote: > libguestfs-1.37.35-2.fc28.src.rpm > I'm not sure about these failures, but they don't seem to be GCC bugs. Is there a log file? 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
Summary/Minutes for today's FESCo Meeting (2018-02-23)
=== #fedora-meeting: FESCO (2018-02-23) === Meeting started by nirik at 15:08:16 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2018-02-23/fesco.2018-02-23-15.08.log.html . Meeting summary --- * init process (nirik, 15:08:17) * #1714 Fedora 26 spins process was missed (nirik, 15:10:25) * LINK: https://pagure.io/fesco/issue/1714 (nirik, 15:10:26) * LINK: https://fedoraproject.org/wiki/Astronomy_Spin has an owner section, do the others? (bowlofeggs, 15:21:15) * AGREED: FESco will create the pages and asking on devel and spins lists to populate it and require testing at beta to stay in. (+5,0,0) (nirik, 15:25:58) * #1845 389-ds-base and freeipa on 32 bit arches (nirik, 15:26:09) * LINK: https://pagure.io/fesco/issue/1845 (nirik, 15:26:09) * AGREED: Ask the GCC team to try to help find the source of the corruption. Post to the -devel list to let people know the situation. Revisit in two weeks. (+5,0,0) (nirik, 15:34:43) * ACTION: bowlofeggs to mail devel and gcc maintainers to make them aware of the converstation in bugs. (nirik, 15:40:17) * #1846 F28 approved Changes not in MODIFIED status (considered as not testable) (nirik, 15:40:42) * LINK: https://pagure.io/fesco/issue/1846 (nirik, 15:40:42) * AGREED: changes wishing to defer to f29 can do so now, the rest we revisit next week for response or testable. (+5,0,0) (nirik, 15:47:01) * #1847 Request Permission to Retire w/o Responsive Maintainer (nirik, 15:47:21) * LINK: https://pagure.io/fesco/issue/1847 (nirik, 15:47:21) * AGREED: proceed immediately with retiring xchat-ruby, and open the procedure on fedora-devel for nonresponisve maintainer (+5,0,0) (nirik, 15:50:27) * ACTION: zbyszek to retire xchat-ruby and start non responsive process for developer. (nirik, 15:52:58) * #1848 Request to Authorize Removal of Blender Source Tarballs from Incorrect Place in Repository (nirik, 15:53:05) * LINK: https://pagure.io/fesco/issue/1848 (nirik, 15:53:05) * AGREED: defer this another week for more discussion. (+5,0,0) (nirik, 15:57:17) * next weeks chair (nirik, 15:57:22) * zbyszek to chair next week (nirik, 15:59:30) * Open Floor (nirik, 15:59:34) Meeting ended at 16:04:50 UTC. Action Items * bowlofeggs to mail devel and gcc maintainers to make them aware of the converstation in bugs. * zbyszek to retire xchat-ruby and start non responsive process for developer. Action Items, by person --- * bowlofeggs * bowlofeggs to mail devel and gcc maintainers to make them aware of the converstation in bugs. * zbyszek * zbyszek to retire xchat-ruby and start non responsive process for developer. * **UNASSIGNED** * (none) People Present (lines said) --- * nirik (86) * bowlofeggs (40) * zbyszek (30) * jsmith (26) * jwb (22) * zodbot (13) * tyll (0) * sgallagh (0) * maxamillion (0) * dgilmore (0) -- 15:08:16 #startmeeting FESCO (2018-02-23) 15:08:17 #meetingname fesco 15:08:17 #chair maxamillion dgilmore nirik jsmith sgallagh bowlofeggs tyll jwb zbyszek 15:08:17 #topic init process 15:08:17 Meeting started Fri Feb 23 15:08:16 2018 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:08:17 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:08:17 The meeting name has been set to 'fesco_(2018-02-23)' 15:08:17 The meeting name has been set to 'fesco' 15:08:17 Current chairs: bowlofeggs dgilmore jsmith jwb maxamillion nirik sgallagh tyll zbyszek 15:08:21 who all is around? 15:08:26 .hello2 15:08:27 jsmith: jsmith 'Jared Smith' 15:08:27 hello (again) 15:08:43 .hello2 15:08:44 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:09:39 we need 1 more I guess for quorum... bowlofeggs ? 15:10:02 .hello2 15:10:02 bowlofeggs: bowlofeggs 'Randy Barlow' 15:10:15 cool. Lets go ahead and start then. 15:10:25 #topic #1714 Fedora 26 spins process was missed 15:10:26 .fesco 1714 15:10:26 https://pagure.io/fesco/issue/1714 15:10:28 nirik: Issue #1714: Fedora 26 spins process was missed - fesco - Pagure - https://pagure.io/fesco/issue/1714 15:10:53 maxamillion was going to make these pages... but seems not. 15:10:58 Isn't this just a question of manpower? I.e. everybody thinks this page should exist, but nobody is volunteering? 15:11:09 I can just do so... but that brings up the question if we want to change the process any 15:11:31 zbyszek: that and the "process" is pretty poorly documented/understood I think... 15:11:52 right now I guess fesco is supposed to make the page... but that doesn't give a clear action to one person who will do it. 15:12:31 we could do a divide and conquer, unless that would cause inconsistency 15:13:24 i'd do one 15:13:53 i'm not sure why FESCo took this on 15:14:09 beca
libtool and LDFLAGS build flags injection
I've seen a fair amount of LDFLAGS injection failures related to libtool. For the most part, -specs=/usr/lib/rpm/redhat/redhat-hardened-ld is dropped, leading to a lack of BIND_NOW in the resulting binary. Is there a way we can fix this in libtool or the auto* tools? I'm also considering moving -Wl,-z,now to the command line from the GCC specs file, which might help here, too. But I'd prefer a direct, unfiltered channel from redhat-rpm-config to the linker invocation in case we need to inject additional flags. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2018
Tom Hughes wrote: > On 23/02/18 14:33, Paul Howarth wrote: >> On Thu, 22 Feb 2018 18:49:02 +0100 >> Marek Polacek wrote: >>> proftpd: timeouts in tests, but in koji it's fine >> >> I get this too. If I build with mock --old-chroot then it works fine. > > So the obvious difference is that mock with --old-chroot has networking > enabled while the default (ie --new-chroot) does not. > > Does --enable-network also make it work? > > That doesn't explain koji though, as that has networking disabled. I don't know if this is the same issue, but I noticed that in local mock builds of git, some tests were very slow. The tests that were slow were suffering from socket timeouts while making calls to getaddrinfo (to get the local hostname, for determining the default git user identity). I added --private-network to the nspawn_args in the mock config which eliminated the 5 second timeouts for each of these calls. I made a comment to remind myself about it later: # NOTE (tmz): This should still be the default, I think. Without it, network # calls timeout rather than fail quickly. The typical default socket timeout is # 5 seconds. A simple call like 'git var GIT_AUTHOR_IDENT' saw 4 socket # timeouts and takes 20 seconds to return. With this option, it takes # milliseconds. # # See https://github.com/rpm-software-management/mock/issues/113 where this was # partially dealt with. Unfortunately, the solution there sets a default route # to 127.0.0.1 but copies /etc/resolv.conf from the host system -- regardless of # the use_host_resolv setting because systemd-nspawn overrides mock and copies # the system /etc/resolf.conf to the container. There seems to be no option # other than --private-network to avoid this. I haven't had time to look at it further to see if there are any patches worth submitting to improve the situation (in mock and/or systemd-nspawn). -- Todd ~~ Men have become the tools of their tools. -- Henry David Thoreau (1817-1862) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2018
On 23/02/18 14:33, Paul Howarth wrote: On Thu, 22 Feb 2018 18:49:02 +0100 Marek Polacek wrote: proftpd: timeouts in tests, but in koji it's fine I get this too. If I build with mock --old-chroot then it works fine. So the obvious difference is that mock with --old-chroot has networking enabled while the default (ie --new-chroot) does not. Does --enable-network also make it work? That doesn't explain koji though, as that has networking disabled. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
cfitsio update to 3.420 with so version bump
Hi folks, I'm going to update cfitsio to new version 3.420 this weekend on F28+, this includes a library version bump to 5. As there were no API changes, everything should rebuild fine, I made some test builds so far. I'll take care of the required rebuilds. Affected packages (many of these my own ones): * CCfits * astrometry * bes * cpl * healpix * gdal * indi-apogee * indi-gphoto * indi-sx * kst * kstars * libindi * luminance-hdr * nightview * perl-Astro-FITS-CFITSIO * phd2 * python-astropy * python-fitsio * python-pyfits * root * siril * skyviewer * ufraw * vips * wcslib Greetings, Christian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2018
On Thu, 22 Feb 2018 18:49:02 +0100 Marek Polacek wrote: > proftpd: timeouts in tests, but in koji it's fine I get this too. If I build with mock --old-chroot then it works fine. Paul. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Help needed with new segfaults in frame unwinding under gcc8
On 23/02/18 13:16, Jakub Jelinek wrote:
On Thu, Feb 22, 2018 at 01:34:00PM -0800, John Reiser wrote:
Looking at the code:
= gcc/libgcc/unwind.inc
_Unwind_ForcedUnwind_Phase2 (struct _Unwind_Exception *exc,
struct _Unwind_Context *context,
unsigned long *frames_p)
{
_Unwind_Stop_Fn stop = (_Unwind_Stop_Fn) (_Unwind_Ptr) exc->private_1;
<>
stop_code = (*stop) (1, action, exc->exception_class, exc,
context, stop_argument);
=
we see that function pointer 'stop' is cast from an untyped word 'private_1'
with no checking at all, not even for NULL or < PAGE_SIZE, etc.
This is a giant red flag for unreliable code.
Wrong. Just look at what the callers do:
if (exc->private_1 == 0)
code = _Unwind_RaiseException_Phase2 (exc, &cur_context, &frames);
else
code = _Unwind_ForcedUnwind_Phase2 (exc, &cur_context, &frames);
and
if (exc->private_1 == 0)
return _Unwind_RaiseException (exc);
uw_init_context (&this_context);
cur_context = this_context;
code = _Unwind_ForcedUnwind_Phase2 (exc, &cur_context, &frames);
So, _Unwind_ForcedUnwind_Phase2 is not called if private_1 is NULL.
Judging by the valgrind report it is undefined, and likely has the
value 0x120 or something close to that, which is clearly bogus but
good enough to get past the null check ;-)
Can I get detailed info on how to reproduce this (most importantly, which
src.rpm you are trying to build)?
I believe it's cyrus-imapd.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
How to package a gnome-shell-extension default on?
Is it possible, and if so, how do I package a gnome-shell-extension that is defaulted to on for all users? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On Sun, Feb 18, 2018 at 06:09:40PM +0100, Igor Gnatenko wrote: > > List of packages and respective maintainers: > https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt > > adeltonmod_auth_openidc mod_authnz_pam mod_intercept_form_submit > mod_lookup_identity perl-Cache-Mmap perl-Crypt-DES perl-Sys-CPU I've updated and built mod_authnz_pam mod_intercept_form_submit mod_lookup_identity perl-Cache-Mmap perl-Crypt-DES I'm leaving mod_auth_openidc to John and perl-Sys-CPU to Emmanuel, as I don't want to step on their toes. -- Jan Pazdziora Senior Principal Software Engineer, OpenShift Security Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On 02/18/2018 06:09 PM, Igor Gnatenko wrote: The grep output is located here: https://ignatenkobrain.fedorapeople.org/gcc-removal.txt fbset should be taken care of because I had to touch the package anyway, and it has seen few actual changes over the years. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Help needed with new segfaults in frame unwinding under gcc8
On Thu, Feb 22, 2018 at 01:34:00PM -0800, John Reiser wrote:
> Looking at the code:
> = gcc/libgcc/unwind.inc
> _Unwind_ForcedUnwind_Phase2 (struct _Unwind_Exception *exc,
> struct _Unwind_Context *context,
> unsigned long *frames_p)
> {
>_Unwind_Stop_Fn stop = (_Unwind_Stop_Fn) (_Unwind_Ptr) exc->private_1;
> <>
>stop_code = (*stop) (1, action, exc->exception_class, exc,
> context, stop_argument);
> =
> we see that function pointer 'stop' is cast from an untyped word 'private_1'
> with no checking at all, not even for NULL or < PAGE_SIZE, etc.
> This is a giant red flag for unreliable code.
Wrong. Just look at what the callers do:
if (exc->private_1 == 0)
code = _Unwind_RaiseException_Phase2 (exc, &cur_context, &frames);
else
code = _Unwind_ForcedUnwind_Phase2 (exc, &cur_context, &frames);
and
if (exc->private_1 == 0)
return _Unwind_RaiseException (exc);
uw_init_context (&this_context);
cur_context = this_context;
code = _Unwind_ForcedUnwind_Phase2 (exc, &cur_context, &frames);
So, _Unwind_ForcedUnwind_Phase2 is not called if private_1 is NULL.
Can I get detailed info on how to reproduce this (most importantly, which
src.rpm you are trying to build)?
Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Pull requests for compat-gcc-34
On 22/02/18 16:47 +0100, Rafal Luzynski wrote: 15.02.2018 12:02 Rafal Luzynski wrote: 9.02.2018 11:34 Rafal Luzynski wrote: > [...] > Please: > - backport the solution to F26 and F27 as well, this should be much > easier than in F28 (my pull requests may be helpful), > - mark my pull requests as merged/obsolete/whatever is appropriate, > - mark the bugzilla tickets as fixed (hopefully this is automatic). PING Any chance to fix compat-gcc-34 in F27 and F26 as well? Pull requests have been waiting for about 1.5 months now. PING^2 Updates submitted for f26 and f27 now. You might have noticed the GCC maintainer is a bit busy with rawhide, and compat-gcc-34 is not a high priority :-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: "libcryptopp update to 6.1.0 with ABI change"
Nicolas Chauvet wrote: > Hi, > > I plan to update cryptopp to 6.1.0 release for f28+ later today. ... > The good news, is that upstream accepted my patch to freeze the ABI > with .6, with this lts version. So for more safety, there is a need to > rebuild the few packages using this library: > > clementine > libndn-cxx > pycryptopp New builds underway. -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [modularity] fedora/linux/modular 404
Kevin, Langdon, thanks guys! I'll keep an eye on this so we won't miss this feature. Cheers, milan pá 23. 2. 2018 v 2:21 odesílatel Langdon White napsal: > On Thu, Feb 22, 2018 at 4:51 PM Kevin Fenzi wrote: > >> On 02/22/2018 10:33 AM, milanisko k wrote: >> > Folks, >> > >> > >> > I've just encountered $Subj today, yesterday the same content URL >> > < >> http://dl.fedoraproject.org/pub/fedora/linux/modular/updates/testing/27/Server/x86_64/ >> > >> > worked just OK. Is this expected or rather an exception? In the former >> > case, where can I get the modular content? >> >> Yeah, we never actually released the modular server for f27. A different >> approach was taken for f28: >> >> >> https://communityblog.fedoraproject.org/modularity-dead-long-live-modularity/ >> >> Since we never released it (except as a beta) and never shipped any >> updates for it (except test ones) we removed those repos. >> >> > Thanks! >> > >> > milan >> > >> > >> > PS: I'm figuring out https://pulpproject.org support for modular >> content >> >> Cool. I'm not fully sure how this will look for f28, but likely you >> could ask the releng list or modulariy workgroup. >> >> > If you would like to track progress, we have a ticket open here: > https://pagure.io/releng/issue/7227 > > langdon > > >> kevin >> >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: New "tests" namespace to share test code
On Thursday, February 22, 2018 3:50:38 PM CET Pierre-Yves Chibon wrote: > On Wed, Feb 14, 2018 at 05:28:20PM +0100, Petr Šplíchal wrote: > > When, for a particular package, it is the most efficient way to > > maintain tests in a separate repo why should we discourage from > > this approach? There are packages where it makes more sense to > > store test code directly in dist-git. And it is still an option. > > But why should we enforce this for all? > > My worries are basically that this mechanism is hiding the tests from > the package maintainers. It splits the concerns between people > maintaining the artifacts and people maintaining the tests, which is > exactly what the original plan to bring CI was *not* about. Since we'll have to "hook" the remote repo into dist-git code, I must be missing something. Where do you see the hidden magic? > The idea has always been to bring the tests where the code lives, so > that both can be worked on as one, to make tests be a concern of the > package maintainer very much like updating the artifact (rpms, image..) > is, while getting support from QE for them (the tests). If the tests live in separate repo, they still can "work as one". > In addition, this is what I fear most: > The tests for the package are stored elsewhere, we're not sure where (the > tests > namespace, a random git repo on the internet...), the packager update package > and the tests fail. > What do you think will happen? > a) the packager will look for $random_place_of_the_internet where tests are > and >spend time trying to fix them. Yes, please don't force us to use random_place_of_the_internet, but rather allow maintainers to use standardized place. Then e.g. 'rpmtests/' repo can automatically grant commit access to package maintainers of 'rpms/' to not overcomplicate things, but still, we can grant non-packagers access to 'rpmtests/'. What about proventesters, could we grant them access to all tests, or could we create new role? > b) the packager will turn off the tests because they get in the way Polemics (even below) about turning-off the tests is FUD. Since tests are opt-in feature, why would anyone thought this way? > If the packager wants to turn off the tests, they will have to go through > dist-git to do it, they may very well end up turning the tests off anyway, but > if the tests are right there, they may as well have a quick look at them to > see > if they can fix them quickly before deciding. > > In addition, if the packager turn the tests off and the people maintaining the > tests do not realize that, they will end up spending time maintaining > $somewhere_else tests that aren't being used. > Having them interact directly with the dist-git repo will increase the > chances > that they see/realize when something is turned off. > > If that means we have less tests in dist-git because the maintainers do > not want them, I'd say so be it. In the long term this is their loss, > they are the ones who will get the bug reports and will have to deal > with them, they are the ones who will have to dive into old code rather > than going back into something that is still fresh in their mind. There's no loss, no. Everything is as transparent as with in-dist-git testing, except it gives us more flexibility - to allow more people to contribute. - keep the package's git smaller and concentrated on packaging > As long as, it is clear that they have been approached and that it is their > choice to not merge pull-requests adding tests, I think the people offering to > help should not be the ones blamed. The help here is very much welcome, I wouldn't blame anyone though (I for one only wait for a bit more flexible form of CI). Btw., the far more important problem is that we can not setup CI for non-atomic host packages, and that we can not use the CI for Rawhide gating. Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: New "tests" namespace to share test code
On 22 February 2018 at 15:50, Pierre-Yves Chibon wrote: > On Wed, Feb 14, 2018 at 05:28:20PM +0100, Petr Šplíchal wrote: >> Hi! >> >> During the last days there have been concerns raised regarding >> what is an appropriate content for the tests namespace. [1] My >> original idea was to enable sharing tests even across branches of >> the same component, not only for tests to be used by completely >> different packages. The initial examples might have been a bit >> misleading in this respect. One of the main points still holds: >> >> > * Tests might follow a different branching pattern than the >> >dist-git repo, leading to code duplication >> >> From the feedback from developers I feel they always keep on mind >> and care a lot about the maintenance costs. So it perfectly makes >> sense to me if they want to keep and maintain tests in a separate >> repo instead of merging/cherry-picking between dist-git branches. >> >> When, for a particular package, it is the most efficient way to >> maintain tests in a separate repo why should we discourage from >> this approach? There are packages where it makes more sense to >> store test code directly in dist-git. And it is still an option. >> But why should we enforce this for all? Thanks for sharing your thoughts, Pierre. > My worries are basically that this mechanism is hiding the tests > from the package maintainers. It splits the concerns between > people maintaining the artifacts and people maintaining the > tests, which is exactly what the original plan to bring CI was > *not* about. I do not see a split here but rather potential for enhanced or extended collaboration. Repositories in the tests namespace can be set up with more open access than rpms git. In this way devel can invite qe for direct collaboration on tests. That's one of the reasons why we should try to fix the non-packager access as soon as possible. https://pagure.io/fedora-infrastructure/issue/6361 > The idea has always been to bring the tests where the code > lives, so that both can be worked on as one, to make tests be a > concern of the package maintainer very much like updating the > artifact (rpms, image..) is, while getting support from QE for > them (the tests). I see the benefits of having code with tests at the very same place, I find this very useful especially for unit tests in the project upstream. However, the situation here is a bit different in two respects: 1) The rpms dist git does not include package code itself but rather build metadata only (mainly spec files describing how to build the package) so it makes very good sense to host at this place testing metadata only (how to test the package). This is quite nicely consistent approach. 2) As far as I can see, within the Always Ready Operating System effort we are not looking to cover every and each feature in all packages but rather ensuring the OS works as a whole. Thus basic functionality and integration tests which guard the stability of the packages are more appropriate for testing. These do not need to be kept so close to the package code. I believe we don't want to duplicate upstream unit testing here. We should probably clarify more which test types are appropriate or expected in the Fedora CI. As part of the docs consolidation I added a brief section about test types to the main CI portal: https://fedoraproject.org/wiki/CI#Test_Types Does it decribe well what we are looking for? Shall we extend it? > In addition, this is what I fear most: > The tests for the package are stored elsewhere, we're not sure > where (the tests namespace, a random git repo on the > internet...), the packager update package and the tests fail. I see no hiding of tests from maintainers: Tests are clearly referenced and discoverable from the rpms dist git as defined by the Standard Test Interface and devels have access, see: https://fedoraproject.org/wiki/CI/Share_Test_Code#Examples Devel decides which tests are good for testing, it does not matter where the test code lives. However there needs to be trust to the referenced repo. But this is the same as with any other open source project. > What do you think will happen? > a) the packager will look for $random_place_of_the_internet > where tests are and spend time trying to fix them. > b) the packager will turn off the tests because they get in the way > > If the packager wants to turn off the tests, they will have to > go through dist-git to do it, they may very well end up turning > the tests off anyway, but if the tests are right there, they may > as well have a quick look at them to see if they can fix them > quickly before deciding. It's not random_place_of_the_internet, it's well selected and trusted source where devel can (usually) directly contribute. I meet devels around who see benefit in having tests enabled. So I don't share your concern about turning the test off so easily. > In addition, if the packager turn the tests off and the people > maintaining t
Re: Fedora mass rebuild 2018
2018-02-22 21:47 GMT+01:00 Josh Boyer : > On Thu, Feb 22, 2018 at 12:49 PM, Marek Polacek wrote: >> As many of you know, every year we (the GCC team) rebuild all the Fedora >> packages with the upcoming GCC, so as to reveal as many bugs as possible >> before >> we release the new version. As in the previous years, it is only performed >> on >> x86_64 only; we unfortunately lack the resources to deal with other arches. >> Ideally we'd conclude this mass rebuild *before* the new GCC has gotten into >> the buildroots; alas, this wasn't the case this year. Thank you for your great job. > > josh > >> >> Let's get down to the nitty-gritty: ... >> jalv-1.6.0-3.fc27.src.rpm I tried a mockbuild in current rawhide (jalv-1.6.0-4.fc28.src.rpm) and it was successful. ... >> lv2-x42-plugins-0.3.0-0.3.20170428.fc27.src.rpm I've patched this package (lv2-x42-plugins-0.3.0-0.5.20170428.fc29.src.rpm) and I've sent PRs upstream Ciao Guido fas account: tartina ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
