Re: F20 System Wide Change: ARM as primary Architecture

On 10/14/2013 10:55 AM, Matthew Garrett wrote: On Thu, Jul 11, 2013 at 01:39:21AM -0400, Carlos O'Donell wrote: Next steps: - Verify libssp works correctly on 32-bit ARM. - Look at enhancing the existing support in glibc. - Add TLS stack guard. - Add TLS pointer guard. - Add pointer

Re: F20 System Wide Change: ARM as primary Architecture

On 10/15/2013 12:53 PM, Matthew Garrett wrote: On Tue, Oct 15, 2013 at 12:42:44PM -0400, Carlos O'Donell wrote: On 10/14/2013 10:55 AM, Matthew Garrett wrote: Did the arm32 portions of this end up being completed for F20? For 32-bit ARM on f20: - Stack guard: - Existing glibc support

Re: F20 System Wide Change: ARM as primary Architecture

On 10/15/2013 02:27 PM, Jakub Jelinek wrote: On Tue, Oct 15, 2013 at 02:16:28PM -0400, Carlos O'Donell wrote: There is no effective security difference between accessing the randomized stack guard value from a global variable or a value stored in the dynamic thread vector. It is only

Re: F20 System Wide Change: ARM as primary Architecture

On 07/10/2013 01:36 PM, Jakub Jelinek wrote: On Wed, Jul 10, 2013 at 11:19:33AM -0500, Dennis Gilmore wrote: armv7 has stack protector, aarch64 which is outside of this proposal doesnt yet have it. Only i?86/x86_64/ppc/ppc64/s390/s390x/sparc/sparc64/tilegx/tilepro really have full stack

The GNU C Library will be rebased in F21 to match glibc 2.20.

Fedora, This is a reminder that the glibc team will be rebasing glibc in F21 to match glibc 2.20. The plan remains largely as was written here: http://fedoraproject.org/wiki/Changes/GLIBC220 Only glibc 2.20 has ABI guarantees, and therefore we will move to 2.20 before F21 goes to GA to ensure

Request for testers: glibc update to work around Intel TSX errata microcode_ctl problems.

Developers. Testers wanted immediately for: https://admin.fedoraproject.org/updates/glibc-2.18-16.fc20 and https://admin.fedoraproject.org/updates/glibc-2.20-4.fc21 For Fedora 21 and Fedora 20 we will be disabling Intel TSX support in POSIX threads effective immediately. This disabling of TSX

Re: Request for testers: glibc update to work around Intel TSX errata microcode_ctl problems.

On 09/26/2014 02:34 PM, Carlos O'Donell wrote: Developers. Testers wanted immediately for: https://admin.fedoraproject.org/updates/glibc-2.18-16.fc20 and https://admin.fedoraproject.org/updates/glibc-2.20-4.fc21 For FC21 was missed a case where TSX was being used and had to push one

Re: Request for testers: glibc update to work around Intel TSX errata microcode_ctl problems.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/28/2014 02:17 PM, Reindl Harald wrote: What about the case where the user runs a custom kernel? then he needs to build it right That's not sufficiently conservative for a core runtime. don't get me wrong but you can't seriously disable

Un-retiring ice and mumble?

Devel, I would like to un-retire mumble, but that requires ice. I've just fixed ice to compile on f21 without much effort. So I think I'll un-retire ice and mumble and maintain them unless anyone objects. Is there any reason ice was orphaned and retired other than lack of interest? Cheers,

Re: Un-retiring ice and mumble?

On 03/05/2015 05:08 PM, Sergio Durigan Junior wrote: On Monday, January 12 2015, Carlos O'Donell wrote: Devel, I would like to un-retire mumble, but that requires ice. I've just fixed ice to compile on f21 without much effort. So I think I'll un-retire ice and mumble and maintain them

Re: glibc fix to allow instlangs to really work -- too late for f22?

On 03/23/2015 11:06 AM, Carlos O'Donell wrote: On 03/18/2015 09:05 AM, Josh Boyer wrote: As discussed the change has no impact on code, it's entirely a packaging change, which carries it's own risks, but the same kind of risks as a runtime change. Only users running with kickstart --instLangs

Re: glibc fix to allow instlangs to really work -- too late for f22?

On 03/18/2015 09:05 AM, Josh Boyer wrote: On Wed, Mar 18, 2015 at 8:00 AM, Paul Howarth p...@city-fan.org wrote: On 18/03/15 11:55, Josh Boyer wrote: On Wed, Mar 18, 2015 at 7:50 AM, Matthew Miller mat...@fedoraproject.org wrote: The glibc team has a fix for a longstanding issue, which is

Re: Build-essential packages

On 06/11/2015 02:36 AM, Florian Weimer wrote: On 05/21/2015 10:11 PM, Jason L Tibbitts III wrote: The BuildRequires section of the guidelines has been revised; the exceptions list is gone. The release engineering folks are free to define the buildroot and rpm is free to change its

Re: Build-essential packages

On 06/12/2015 12:11 PM, Dennis Gilmore wrote: On Thursday, June 11, 2015 08:36:38 AM Florian Weimer wrote: On 05/21/2015 10:11 PM, Jason L Tibbitts III wrote: The BuildRequires section of the guidelines has been revised; the exceptions list is gone. The release engineering folks are free to

Removing glibc librtkaio support in Fedora Rawhide.

On July 2003 the rtkaio add-on was added to Fedora in glibc 2.3.2-64. The rtkaio add-on provided a POSIX realtime API interface that used linux kernel Asynchronous IO support (KAIO) to provide high performance AIO for a small subset of files (those using O_DIRECT, and not all file types).

Re: F23 System Wide Change: Glibc locale subpackaging

On 06/22/2015 10:59 AM, Alexander Larsson wrote: On mån, 2015-06-22 at 06:16 -0400, Jan Kurik wrote: = Proposed System Wide Change: Glibc locale subpackaging = https://fedoraproject.org/wiki/Changes/Glibc_locale_subpackaging Change owner(s): * Mike Fabian mfabian At redhat DOT com *

Re: Removing glibc librtkaio support in Fedora Rawhide.

On 08/21/2015 03:23 PM, Carlos O'Donell wrote: * Immediately remove rtkaio from Fedora Rawhide, deprecating the library, and providing a system change notification about the library removal for F24. Both the glibc 2.23 and librtkaio removal system change notifications have now been drafted

Re: F23 System Wide Change: Glibc locale subpackaging

On 06/22/2015 09:01 AM, Jonathan Dieter wrote: On Mon, 2015-06-22 at 06:16 -0400, Jan Kurik wrote: Recently we made it possible to install a small number of locales by supplying the rpm-macro “_install_langs”, for example rpm -i -D _install_langs=en:de_DE glibc-common.rpm will install

Re: Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking

On 08/28/2015 03:23 PM, Josh Stone wrote: > I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64 > this morning, and now I get this stderr output: > > $ /usr/bin/stap -V >/dev/null > /usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in > shared object, consider

Fedora Rawhide glibc-2.22.90-6.fc24 shipping C.UTF-8 locale.

Thanks to some great work by Mike FABIAN the Rawhide glibc is now shipping with a C.UTF-8 locale for use as a default UTF-8 locale. The locale can be referenced as "C.UTF-8" or "C.utf8". Any feedback on the locale is greatly appreciated. The locale is added to the pre-processed memory mapped

Re: Proposal to reduce anti-bundling requirements

On 09/10/2015 03:42 PM, Adam Miller wrote: >> It doesn't matter how rare they are, it'll only take a single bundled >> library handled incorrectly to completely screw a running OS. I don't >> think this is something that can just be swept under the carpet, it >> needs to be addressed as a core

Re: Proposal to reduce anti-bundling requirements

On 09/10/2015 10:42 AM, Florian Weimer wrote: > On 09/10/2015 03:53 PM, Stephen Gallagher wrote: > >> I would like to propose that the no-bundled-libraries policy be >> amended as follows: "Any package that has an existing mechanism to >> link against a shared system library and functions

Re: Fedora Ring 0 definition

On 09/14/2015 05:10 PM, Brendan Conoboy wrote: > You are right that we do need to think about overall goals to be > achieved, then the policies that achieve those goals. For my part I > am interested in distinguishing the OS from the applications that run > on top of it. This might be the

Re: Proposal to reduce anti-bundling requirements

On 09/14/2015 08:29 AM, Florian Weimer wrote: > On 09/11/2015 04:34 PM, Carlos O'Donell wrote: > >>> How do you propose to resolve symbol conflicts if both the system >>> library and the bundled library are loaded into the same process? The >>> current ELF

FYI: Building glibc rpm using --with bootstrap.

I just finished extending the `--with bootstrap` support for rawhide glibc (rawhide glibc is FTBS right now, but that's another reason). The goal is to provide RCM and others in Fedora with the ability to experiment with bootstraps using the standard set of rpm tooling. When bootstrap is active

PSA: Statically linking against the C/C++ runtime is not supported.

Follow the Fedora Guidelines on static linking against a library. If you really need to use static linking, you should know that we can not support statically linking against the C/C++ runtime. This includes the use of the gcc, clang, or ld option: -static -static-.* e.g. -static-libstdc++

Re: Hacks for multilib unclean C headers

On 06/08/2016 10:21 AM, Jonathan Wakely wrote: >> If this is so, I will go to FPC with request the ammend the C guidelines >> with explicit discourage of %{?_isa} on gcc because the main >> architecture supports the secondary targets and because gcc is not >> multilib safe. > > I think -devel

Re: glibc in Fedora rawhide now split by langpacks.

On 02/29/2016 06:32 AM, Petr Pisar wrote: > On 2016-02-27, Ruben Kerkhof wrote: >> I'm now seeing this in mock / koji builds: >> >> perl: warning: Setting locale failed. >> perl: warning: Please check that your locale settings: >> LANGUAGE = (unset), >> LC_ALL = (unset),

Re: glibc in Fedora rawhide now split by langpacks.

On 02/27/2016 08:33 PM, Adam Williamson wrote: > On Fri, 2016-02-26 at 04:47 -0500, Carlos O'Donell wrote: >> The glibc in Fedora rawhide and F24 is now split by >> language packs. We have over 180 supported languages >> in glibc, and those have been split into langpacks >&

Re: glibc in Fedora rawhide now split by langpacks.

On 02/29/2016 10:46 AM, Richard W.M. Jones wrote: > On Mon, Feb 29, 2016 at 01:42:57PM +, Richard W.M. Jones wrote: >> On Sat, Feb 27, 2016 at 08:57:27PM +, Igor Gnatenko wrote: >>> And also I was not able to start gnome-terminal and some other apps. I had >>> to install glibc-langpack-en.

Re: glibc in Fedora rawhide now split by langpacks.

On 02/27/2016 03:44 PM, Adam Williamson wrote: > On Fri, 2016-02-26 at 04:47 -0500, Carlos O'Donell wrote: >> The glibc in Fedora rawhide and F24 is now split by >> language packs. We have over 180 supported languages >> in glibc, and those have been split into langpacks >&

Re: glibc in Fedora rawhide now split by langpacks.

On 02/29/2016 04:22 AM, Vít Ondruch wrote: > > Dne 26.2.2016 v 11:20 Carlos O'Donell napsal(a): >> On 02/26/2016 05:02 AM, Vít Ondruch wrote: >>> You also forget to mention what Rawhide users are supposed to do. >>> >>> I assume that I should do: >>>

Re: glibc in Fedora rawhide now split by langpacks.

On 02/29/2016 01:18 PM, Florian Weimer wrote: > On 02/29/2016 05:18 PM, Adam Williamson wrote: > >> IIRC it would simply terminate claiming the remote host had dropped the >> connection. There wasn't any useful information even with -. I just >> kinda guessed it must have something to do with

glibc in Fedora rawhide now split by langpacks.

The glibc in Fedora rawhide and F24 is now split by language packs. We have over 180 supported languages in glibc, and those have been split into langpacks for transparent install and support via dnf. This greatly reduces the size of a glibc install from 130MB down to a couple of megs. It drops

Re: glibc in Fedora rawhide now split by langpacks.

On 02/26/2016 04:47 AM, Carlos O'Donell wrote: > The glibc in Fedora rawhide and F24 is now split by > language packs. We have over 180 supported languages > in glibc, and those have been split into langpacks > for transparent install and support via dnf. This > greatly reduces the

Re: [GCC6] fatal error: You must enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use these intrinsics.

On 02/18/2016 08:37 PM, Kevin Kofler wrote: > Peter Robinson wrote: >> It's an issue we see occasionally where the package thinks it knows >> better than the explicit CFLAGs being set, I'll get it sorted out. > > But why are those intrinsics now requiring NEON at all? Those are GCC byte > swap

Re: glibc in Fedora rawhide now split by langpacks.

On 02/26/2016 05:02 AM, Vít Ondruch wrote: > You also forget to mention what Rawhide users are supposed to do. > > I assume that I should do: > > # dnf install langpacks-cs > > to have only czech language available and English should be available by > default, right? No languages are available

Re: glibc in Fedora rawhide now split by langpacks.

On 02/26/2016 09:44 AM, Michael Catanzaro wrote: > On Fri, 2016-02-26 at 12:25 +, Richard Hughes wrote: >> What happens if the user isn't using DNF? For the workstation we have >> to support users using just the graphical tools, and we can't rely on >> command line tools for this kind of

Re: glibc in Fedora rawhide now split by langpacks.

On 02/26/2016 10:38 AM, Michael Catanzaro wrote: > On Fri, 2016-02-26 at 10:06 -0500, Carlos O'Donell wrote: >> Correct, 'glibc-all-langpacks' will solve the problem immediately. > > OK, I've added this to comps, to take care of new installs. If anyone > implements support

Re: glibc in Fedora rawhide now split by langpacks.

On 02/26/2016 10:39 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Feb 26, 2016 at 08:56:27AM -0500, Stephen Gallagher wrote: >> On 02/26/2016 08:39 AM, Miroslav Suchý wrote: >>> Dne 26.2.2016 v 11:20 Carlos O'Donell napsal(a): >>>> No languages are available b

Re: glibc in Fedora rawhide now split by langpacks.

On 02/26/2016 07:33 AM, Parag Nemade wrote: > Hi, > > On Fri, Feb 26, 2016 at 3:52 PM, Carlos O'Donell <car...@redhat.com> wrote: >> On 02/26/2016 04:47 AM, Carlos O'Donell wrote: >>> The glibc in Fedora rawhide and F24 is now split by >>> language pack

Re: [LLVM] CommandLine Error: Option 'track-memory' registered more than once!

On 02/17/2016 03:24 AM, Igor Gnatenko wrote: > Hi guys, I see this error when building POCL or Beignet which looks > like a bug in clang or llvm, can you please investigate? > > : CommandLine Error: Option ': CommandLine Error: Option > 'track-memory' registered more than once! > track-memory'

dnf --refresh upgrade vs. CVE-2015-7547 updates.

On 2016-02-16 16:41:27 the glibc rawhide build to fix CVE-2015-7547[1] completed: https://koji.fedoraproject.org/koji/buildinfo?buildID=736361 On 2016-02-17 the rawhide repodiff email showed the build: ~~~ glibc-2.22.90-36.fc24 - * Tue Feb 16 2016 CArlos O'Donell <car

Re: glibc in Fedora rawhide now split by langpacks.

On 02/26/2016 04:47 AM, Carlos O'Donell wrote: > Bug 1238406 - Glibc locale subpackaging > https://bugzilla.redhat.com/show_bug.cgi?id=1238406 > > Changes/Glibc locale subpackaging > https://fedoraproject.org//wiki/Changes/Glibc_locale_subpackaging With glibc-2.23.90-3.fc25 and

Re: No Rich boolean deps in Requires/Recommends for f24

On 04/01/2016 02:51 PM, Kevin Fenzi wrote: > Greetings. > > Recently FPC oked the use of rich boolean deps. However, we have run > into an issue where the tools used to push updates are not able to > correctly handle these new dependencies. > > At today's FESCo meeting we decided to ask

Re: Proposal: Rethink Fedora multilib support (Take Two!)

On 01/09/2017 08:18 PM, Richard W.M. Jones wrote: > On Mon, Jan 09, 2017 at 09:20:20AM +0100, Jakub Jelinek wrote: >> On Sat, Jan 07, 2017 at 11:15:28PM +, Richard W.M. Jones wrote: >>> On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote: On Thursday, January 5, 2017 5:08:16 PM

Re: RFH: Annotating ELF binaries

On 01/16/2017 09:37 AM, Nick Clifton wrote: > Hi H.J. > >> We have 2 different proposals for program properties. Mine: >> >> https://sourceware.org/ml/gnu-gabi/2016-q4/msg00025.html >> >> has a much smaller scope. New features on upcoming Intel platforms, >> like 5-level paging, need this

Re: RFH: Annotating ELF binaries

On 01/18/2017 12:02 PM, Nick Clifton wrote: > Hi Carlos, > >> I've added 2 questions to the Toolchain/Watermark wiki but will post them >> here for posterity: > > Thanks - I'll try answering them here first, and if my answers make sense > then I will update the wiki. > >> (1) What happened to

Re: RFH: Annotating ELF binaries

On 01/20/2017 11:55 AM, H.J. Lu wrote: > We can classify properties into 2 categories: used by run-time loader, > not used by run-time loader. We put properties for run-time loader into > .note.gnu.property section and the rest into GNU attribute section. Agreed. Can we use the same

Re: Fedora 27 mass rebuild at risk

On 07/13/2017 07:01 AM, Carlos O'Donell wrote: > On 07/12/2017 08:10 PM, Carlos O'Donell wrote: >> On 07/11/2017 09:48 PM, Carlos O'Donell wrote: >>> On 07/11/2017 12:37 AM, Carlos O'Donell wrote: >>>> If we're lucky we can get everything ready for the 12th, but

Re: Fedora 27 mass rebuild at risk

On 07/07/2017 08:53 AM, Florian Weimer wrote: > We currently have an invalid IFUNC resolver in libgcc.a on POWER > (rhbz#1467526). glibc in rawhide recently started linking that into the > library and there are significant problems with that (rhbz#1467518). > > I'll be on PTO next week, and it

Re: Fedora 27 mass rebuild at risk

On 07/07/2017 04:20 PM, Carlos O'Donell wrote: > On 07/07/2017 08:53 AM, Florian Weimer wrote: >> We currently have an invalid IFUNC resolver in libgcc.a on POWER >> (rhbz#1467526). glibc in rawhide recently started linking that into the >> library and there are

Re: Fedora 27 mass rebuild at risk

On 07/12/2017 08:10 PM, Carlos O'Donell wrote: > Note: > - I'm doing a local rebuild of golang 1.9.0 with the new glibc looking for > failures > before jacjka wakes up tomorrow in the European time zone. This test shows we have one last ppc64le failure for goland 1.9.0 which I

Re: Fedora 27 mass rebuild at risk

On 07/11/2017 09:48 PM, Carlos O'Donell wrote: > On 07/11/2017 12:37 AM, Carlos O'Donell wrote: >> If we're lucky we can get everything ready for the 12th, but we might >> need another day or two given how long it takes to build gcc on all >> the arches. > > We are g

Re: super-drafty F28 and F29 schedules

On 07/06/2017 09:15 PM, Matthew Miller wrote: > https://fedoraproject.org/wiki/Releases/28/Schedule I encourage Jeff Law and Jakub Jelinek to review these schedules for compiler related issues. This is just a perfunctory review from the glibc perspective with regard to base ABI and API issues in

Re: Fedora 27 mass rebuild at risk

On 07/11/2017 12:37 AM, Carlos O'Donell wrote: > If we're lucky we can get everything ready for the 12th, but we might > need another day or two given how long it takes to build gcc on all > the arches. We are getting more luck. We'll see how tomorrow goes. Status update: * Get the

Re: Fedora 27 mass rebuild at risk

On 07/12/2017 08:10 PM, Carlos O'Donell wrote: > On 07/11/2017 09:48 PM, Carlos O'Donell wrote: >> On 07/11/2017 12:37 AM, Carlos O'Donell wrote: >>> If we're lucky we can get everything ready for the 12th, but we might >>> need another day or two given how long i

Re: Fedora 27 mass rebuild at risk

On 07/12/2017 03:34 AM, Dan Horák wrote: >> * Fix Go 1.8.1 for s390x > > this is https://bugzilla.redhat.com/show_bug.cgi?id=1460254 - > buggy interaction between golang and new binutils That's right, we knew what it was, but fixing it is not that easy since it's generic binutils machinery that

Re: Providing ABI/API assurances for the base runtime in Fedora.

On 09/06/2017 03:50 AM, Petr Pisar wrote: > On 2017-09-06, Petr Pisar wrote: >> Does it mean that when a need for a new feature arises, e.g. adding >> getrandom(3) into glibc >> we will produce >> a new platform stream

Re: [modularity] Modularizing the world fast and iteratively

On 09/07/2017 01:50 PM, Alexander Bokovoy wrote: > The per-symbol API versioning in RPM was proposed five years ago by > ALT Linux people. It actually works well in their RPM fork. > > An isolated version of that code is available at https://github.com/svpv/rpmss > > You may want to read

Providing ABI/API assurances for the base runtime in Fedora.

Fedora Developers, I am working on a way to provide concrete ABI/API assurances for parts of the base runtime. I've written up some of the key ideas here: https://fedoraproject.org/wiki/BaseRuntimeInterface Any feedback would be appreciated, including bikeshed on component name prefix for

Re: Providing ABI/API assurances for the base runtime in Fedora.

On 09/01/2017 10:00 AM, Igor Gnatenko wrote: > On Fri, 2017-09-01 at 09:28 -0500, Carlos O'Donell wrote: >> Fedora Developers, > >> I am working on a way to provide concrete ABI/API assurances for >> parts of the base runtime. > Note that Base Runtime is F26-only th

Re: Providing ABI/API assurances for the base runtime in Fedora.

On 09/04/2017 07:31 AM, Petr Pisar wrote: > On 2017-09-01, Carlos O'Donell <car...@redhat.com> wrote: >> I've written up some of the key ideas here: >> https://fedoraproject.org/wiki/BaseRuntimeInterface >> >> Any feedback would be appreciated, including bik

FYI: Potential delay in toolchain readiness for 64-bit POWER LE transition to 128-bit IEEEE long double.

FYI. As part of the glibc 2.28 development upstream plans to change the ppc64le default ABI for long double from "IBM long double" to "IEEE 128-bit long double", this change is documented here: https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition We have a potential problem here

Rawhide make segfaults.

At present I can't build glibc in rawhide because make segfaults: + make -j4 -O -r 'CFLAGS=-mtune=generic -g -O2 -fstack-clash-protection' make -r PARALLELMFLAGS="" -C .. objdir=`pwd` all make: *** [Makefile:9: all] Segmentation fault (core dumped) error: Bad exit status from

Re: glibc, riscv64, multilib, /lib64 etc

On 02/08/2018 07:14 AM, Richard W.M. Jones wrote: > Or when building glibc, use: > > ./configure --libdir=/usr/lib64 libc_cv_slibdir=/usr/lib64 > libc_cv_rtlddir=/usr/lib64 > > which seems to be sufficent to override the default path choices, > although maybe not completely. This would be a

Re: glibc, riscv64, multilib, /lib64 etc

On 02/08/2018 06:51 AM, david.abdurachma...@gmail.com wrote: >> We could do a downstream patch. > > This would be a minimal patch based on quick look into glibc code. We > could force it to act as, e.g AArch64. I worry, that this would be > custom from what is expected in RISC-V software

Re: Guideline change: glibc malloc as the C/C++/Rust allocator

On 07/26/2018 12:24 PM, Vít Ondruch wrote: > > > Dne 26.7.2018 v 18:03 Jason L Tibbitts III napsal(a): >>> "FW" == Florian Weimer writes: >> FW> I would like to request a change of the Packaging Guidelines, >> FW> advising packagers not to interpose malloc. >> >> How strong of a restriction

Re: Guideline change: glibc malloc as the C/C++/Rust allocator

On 07/26/2018 12:45 PM, R P Herrold wrote: > On Thu, 26 Jul 2018, Florian Weimer wrote: > >> I would like to request a change of the Packaging Guidelines, advising >> packagers not to interpose malloc. > > The use here of 'interpose' is unclear to me -- are you saying > 'substitute a different'

Re: [HEADS UP] gcc/gcc-c++ removal from buildroot and more

On 07/09/2018 07:03 PM, Igor Gnatenko wrote: > today we finally dropped gcc and gcc-c++ from the buildroot > . > This made 12 packages go away along with 134MB installed size. This > means that you need to add gcc/gcc-c++ in the

Re: Guideline change: glibc malloc as the C/C++/Rust allocator

On 07/27/2018 06:43 AM, Florian Weimer wrote: > On 07/26/2018 06:03 PM, Jason L Tibbitts III wrote: >>> "FW" == Florian Weimer writes: >> >> FW> I would like to request a change of the Packaging Guidelines, >> FW> advising packagers not to interpose malloc. >> >> How strong of a

Re: Multilib inconsistencies between fedora/updates/updates-testing composes

On 12/14/18 1:50 PM, Kevin Fenzi wrote: > On 12/14/18 4:06 AM, Florian Weimer wrote: >> * Florian Weimer: >> >>> We have seen reports that glibc-headers.i686 comes and goes from the >>> x86_64 updates compose. Previously, we have seen this only for the >>> updates-testing compose:

Re: Bodhi updates permanently locked in PENDING

On 12/14/18 2:08 PM, Kevin Fenzi wrote: > On 12/14/18 4:38 AM, Florian Weimer wrote: >> I need to make changes to these updates: >> >> https://bodhi.fedoraproject.org/updates/FEDORA-2018-2efb53dc71 >> https://bodhi.fedoraproject.org/updates/FEDORA-2018-0e5b278265 >> >> They have been locked in

Delaying the ppc64le transition to 128-bit IEEE long double.

Just a heads up that the ppc64le ABI transition from IBM long double to 128-bit IEEE long double has been delayed. I've removed the following from F30: https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition (moved it back to ChangePageIncomplete). I've also indicated this is the

Re: clang and Fedora's default C/CXX flags

On 1/3/19 2:49 PM, Michael Cronenworth wrote: > Part of Fedora's default C/CXX flags include -fstack-clash-protection > but clang does not support this flag and has until a few weeks ago[1] > silently ignored the flag. > > What are clang apps who use Fedora's default flags supposed to do? > Are

Fedora Release page on wiki not created?

The Fedora change template here: https://fedoraproject.org/wiki/Changes/EmptyTemplate Says you should reference the "Targeted release" in the status. For F31 and F32 it doesn't appear as if the pages were created: https://fedoraproject.org/wiki/Releases/31/

Re: Fedora Release page on wiki not created?

On 11/20/19 2:22 PM, Ben Cotton wrote: > > > On Wed, Nov 20, 2019, 19:00 Carlos O'Donell <mailto:car...@redhat.com>> wrote: > > The Fedora change template here: > https://fedoraproject.org/wiki/Changes/EmptyTemplate > > Says you should reference the

Re: F35 Change: GNU Toolchain update (gcc 11, glibc 2.34, binutils 2.37, gdb 10.2) (System-Wide Change proposal)

On Tue, Jun 29, 2021 at 2:14 PM Ben Cotton wrote: > > On Tue, Jun 29, 2021 at 2:07 PM Ben Cotton wrote: > > > > == Contingency Plan == > > * Contingency mechanism: If glibc 2.34 provides too disruptive to > > compiling the distribution we could revert to 2.33, but given that > > Rawhide has

Re: F35 Change: tzdata-minimal (Self-Contained Change proposal)

On 7/6/21 2:38 PM, David Cantrell wrote: > On Tue, Jul 06, 2021 at 01:20:47PM -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/tzdata-minimal >> >> == Summary == >> Split the tzdata package into two parts - tzdata and tzdata-minimal. >> tzdata will require tzdata-minimal. 

Re: F35 Change: tzdata-minimal (Self-Contained Change proposal)

On 7/12/21 12:16 PM, Petr Viktorin wrote: > On 06. 07. 21 20:38, David Cantrell wrote: >> On Tue, Jul 06, 2021 at 01:20:47PM -0400, Ben Cotton wrote: >>> https://fedoraproject.org/wiki/Changes/tzdata-minimal >>> >>> == Summary == >>> Split the tzdata package into two parts - tzdata and

Re: F35 Change: libffi 3.4 (late System-Wide Change proposal)

On 7/14/21 3:00 PM, Michael Catanzaro wrote: > On Wed, Jul 14 2021 at 02:28:50 PM -0400, Ben Cotton > wrote: >> Rebase libffi in Fedora 34 > > Is this a typo? F34 or F35? Sorry. Fixed. Typo. We've been carrying this change proposal since F34 as we work with upstream to release libffi 3.4. --

Re: F35 Change: libffi 3.4 (late System-Wide Change proposal)

On 7/14/21 2:33 PM, Samuel Sieb wrote: > On 7/14/21 11:28 AM, Ben Cotton wrote: >> == Upgrade/compatibility impact == >> Packages built on the previous version of libffi will have an >> auto-requires on the old SONAME and will cause dnf to install >> libffi3.1 (compat package with runtime). When

Re: F35 Change: tzdata-minimal (Self-Contained Change proposal)

On 7/13/21 11:17 AM, Petr Viktorin wrote: > On 13. 07. 21 16:31, Carlos O'Donell wrote: >> It's possible to remove all tzdata. >> >> However, without *some* data it is not easy to distinguish between these >> two scenarios if you want to offer a different error me

Re: F35 Change: tzdata-minimal (Self-Contained Change proposal)

On 7/13/21 8:12 AM, Petr Viktorin wrote: > On 12. 07. 21 18:31, Carlos O'Donell wrote: >> If you can minimally provide the tables of possible zones, and >> provide an easy way to detect a zone is missing, then the APIs can >> determine: "Yes you could do that,

Re: Raising the attachment size limit in bugzilla?

On 12/14/21 10:16, Robbie Harwood wrote: > Carlos O'Donell writes: > >> - Life-cycle management (delete attachments). > > Please don't delete attachments. It severely reduces the usefulness of > keeping old bugzillas around - if we're going to do that, we might as

Raising the attachment size limit in bugzilla?

The Fedora SOS reports are ~30MiB today, and this exceeds the Bugzilla attachment limit of 19.5MiB. Do we have the option to raise the attachment size to something that could accommodate the average SOS report limit for Fedora uses? I've had users report SOS tarballs that are ~60MiB in size which

Re: pipewire memory usage

On 12/14/21 07:08, Dominique Martinet wrote: > I've double-checked with traces in load_spa_handle/unref_handle and it > is all free()d as soon as the client disconnects, so there's no reason > the memory would still be used... And I think we're just looking at some > malloc optimisation not

Re: Raising the attachment size limit in bugzilla?

On 12/14/21 12:37, Daniel P. Berrangé wrote: > A sosreport contains a tonne of useful info, but for any single bug > the vast majority is irrelevant. So it is much harder to argue that > requesting this sos report info is proportionate for solving bugs > from Fedora users, especially when

Re: Fedora 35 Mass Rebuild

On 7/20/21 12:02 PM, Tomas Hrcka wrote: > Per the Fedora 35 schedule[1] we will start a mass rebuild for Fedora 35 > on Jul 21st, 2021. We will run a mass rebuild for Fedora 35 for the > changes listed in: > > https://pagure.io/releng/issues?status=Open=mass+rebuild F35 rebase to libffi 3.4

Re: Fedora 35 Mass Rebuild

On 7/22/21 12:13 PM, Tomas Hrcka wrote: > They haven't finished building, so if we cancel both of these, then it > would work: > >> https://koji.fedoraproject.org/koji/taskinfo?taskID=72392389 >> https://koji.fedoraproject.org/koji/taskinfo?taskID=72392356 >> > > > I have canceled both tasks.

Re: F35 Change: libffi 3.4 (late System-Wide Change proposal)

On 7/15/21 6:52 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jul 14, 2021 at 02:28:50PM -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/LIBFFI34 >> >> == Summary == >> Rebase libffi in Fedora 34 from libffi 3.1 to libffi 3.4 (released >> June 28 2021), and provide a

Re: F35 Change: tzdata-minimal (Self-Contained Change proposal)

On 7/15/21 6:34 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jul 06, 2021 at 01:20:47PM -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/tzdata-minimal >> >> == Summary == >> Split the tzdata package into two parts - tzdata and tzdata-minimal. >> tzdata will require

Re: Heads up: libffi 3.4 rebuild in rawhide today

On 1/11/22 13:45, Vít Ondruch wrote: > Thread 1 "ruby" received signal SIGABRT, Aborted. > 0x778a764c in __pthread_kill_implementation () from /lib64/libc.so.6 > Missing separate debuginfos, use: dnf debuginfo-install > glibc-2.34.9000-36.fc36.x86_64 gmp-6.2.1-1.fc36.x86_64 >

Re: F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)

On 1/11/22 13:00, Steve Grubb wrote: > Hello, > > On Wednesday, January 5, 2022 5:05:26 PM EST Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/GNUToolchainF36 >> >> == Summary == >> Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35. >> >> The gcc 12 is currently under

Re: Heads up: libffi 3.4 rebuild in rawhide today

On 1/10/22 14:04, Miro Hrončok wrote: > On 10. 01. 22 18:14, Miro Hrončok wrote: >> On 08. 01. 22 18:09, Carlos O'Donell wrote: >>> On 1/8/22 04:37, Miro Hrončok wrote: >>>> Hello packagers, >>>> >>>> I intent to reb

Re: Heads up: libffi 3.4 rebuild in rawhide today

On 1/8/22 04:37, Miro Hrončok wrote: > Hello packagers, > > I intent to rebuild the following packages with libffi 3.4 in Rawhide side > tag f36-build-side-49314 today. Thank you for helping with the rebuilds! > The previous version remains available as libffi13.1, so failures to build >

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

On 9/27/23 04:43, Peter Robinson wrote: > On Wed, Sep 27, 2023 at 6:24 AM Remi Collet wrote: >> >> Le 26/09/2023 à 19:32, Carlos O'Donell a écrit : >> >>>> In version 8.3 (F40) we'll includes the UTC definition >>>> in our patch to use system tzd

Re: -Werror=implicit-int -Werror=implicit-function-declaration coming to rawhide

On 9/27/23 12:22, Ron Olson wrote: > This is the first time I’ve heard of buildflags.md; where might I find this > file? It is distributed with redhat-rpm-config as part of the documentation of build flags. You can see the rawhide version here:

Re: -Werror=implicit-int -Werror=implicit-function-declaration coming to rawhide

On 9/27/23 12:47, Richard W.M. Jones wrote: > On Wed, Sep 27, 2023 at 11:22:04AM -0500, Ron Olson wrote: >> This is the first time I’ve heard of buildflags.md; where might I find this >> file? > > $ ls -l -h /usr/share/doc/redhat-rpm-config/buildflags.md > -rw-r--r--. 1 root root 28K Feb 28 2023

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

On Mon, Sep 25, 2023 at 4:52 AM Remi Collet wrote: > > Le 25/09/2023 à 10:38, Vít Ondruch a écrit : > > > > Dne 22. 09. 23 v 16:01 Zbigniew Jędrzejewski-Szmek napsal(a): > >> On Fri, Sep 22, 2023 at 10:43:05AM +0200, Vít Ondruch wrote: > >>> https://bugzilla.redhat.com/show_bug.cgi?id=2233281#c3

  1   2   >