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

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 >> * Siddhesh Poyarekar

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). Typica

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

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 we

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 re

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 part

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 correct

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 differe

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

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 loca

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 th

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 whe

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

On 09/28/2014 01:24 PM, drago01 wrote: > On Sun, Sep 28, 2014 at 6:49 PM, Carlos O'Donell wrote: >> On 09/26/2014 02:34 PM, Carlos O'Donell wrote: >>> Developers. >>> >>> Testers wanted immediately for: >>> >>> https://admin.fedora

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 disab

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

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 wrote: >> On 18/03/15 11:55, Josh Boyer wrote: >>> >>> On Wed, Mar 18, 2015 at 7:50 AM, Matthew Miller >>> wrote: The glibc team has a fix for a longstanding issue, which is that "instlangs" h

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 u

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 de

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 f

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

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

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

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 st

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 pack

Retagging a koji build as f17-updates-candidate?

Devs, While pushing out a CVE fix for glibc I received a server error from bodhi. ~~~ [carlos@koi glibc]$ fedpkg build Building glibc-2.15-59.fc17 for f17-candidate Created task: 5143544 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5143544 Watching tasks (this may be safely inter

Re: Retagging a koji build as f17-updates-candidate?

On 03/20/2013 12:54 AM, Mathieu Bridon wrote: > koji tag-pkg f17-updates-candidate glibc-2.15-59.fc17 That worked. I was reading the Koji documentation but didn't understand if I could do that myself or if release engineering had to do it or what the consequences were. That has now allowed me to

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

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 do

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 sign

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 upda

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 s

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

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

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

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 re

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

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

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 in

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 sup

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

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

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

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 availa

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 >

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), >> LANG = "en_US.UTF-8" >>

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/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/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: >&g

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

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

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 maintain

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 extens

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 C

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 SH

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 noun/adjecti

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/ https://fedoraproject.org/wiki/Releases

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

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

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:

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 case

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 th

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 restriction

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

On 6/28/23 03:44, Miroslav Lichvar wrote: > On Mon, Jun 26, 2023 at 04:54:00PM +0100, Aoife Moloney wrote: >> * Other developers: Some packages need to change their spec files from >> `Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if >> all packages switched in this way, but it

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

On 6/27/23 05:38, Jiri Vanek wrote: > JDK will behave similarly. We ave (small) advantage that we have also > in-jdk-bundled tzdata. However fallback in case of removed system > tzdata is not automatic, and requires human touch. Long ago we have a > patch in jdk which looked to system tzdata - if

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

On 6/26/23 16:12, Fabio Valentini wrote: > So all this considered, I'm not sure whether this change is actually > worth it, if tzdata databases of some form will likely be pulled into > installs anyway. Quoting the "Weak Dependencies Policy": "Weak dependencies allow smaller minimal installations

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

On 6/26/23 14:40, Vít Ondruch wrote: > Yep, this is the case for rubygem-tzinfo. It would deserve recommends > at minimum, because in theory, the tzdata can be suplied by > tzinfo-data gem instead. Thank you for adding the `Recommends: tzdata`! -- Cheers, Carlos.

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

On 6/26/23 14:14, Peter Robinson wrote: > On Mon, Jun 26, 2023 at 7:10 PM Miro Hrončok wrote: >> *PEP 615 – Support for the IANA Time Zone Database in the Standard Library* >> says: >> >> >> """ >> Python distributors are encouraged to ensure that time zone data is installed > > The wording of "

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

On 6/28/23 18:24, Fabio Valentini wrote: > On Thu, Jun 29, 2023 at 12:15 AM Carlos O'Donell > wrote: >> >> On 6/26/23 16:12, Fabio Valentini wrote: >>> So all this considered, I'm not sure whether this change is >>> actually worth it, if tzdata da

Re: Red Hat & Fedora -- largely stepping out of this ecosystem

On 6/26/23 18:47, Jeff Law wrote: > What Red Hat has done may be technically legal and perhaps good for > its business. However, to me it's ethically unconscionable. Those > who know me know I'm not an zealot, but I do have a baseline set of > ethical values and Red Hat crossed that line. Why i

Re: Is there a chance to phase out `/lib64` directory?

On 6/27/23 20:21, Kevin Kofler via devel wrote: > Practical cross-compilation to a completely different architecture needs > sysroots anyway. That way, one can also easily target a different > distribution on a different (or even the same) architecture, not just Fedora > on a different architect

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

On 6/29/23 00:44, Miro Hrončok wrote: > On 29. 06. 23 0:31, Carlos O'Donell wrote: >> Can we allow users to create a minimal installation by hand, while still >> complying >> with PEP-615 for default installs? >> >> The size savings for a minimal con

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

On 6/28/23 19:54, Michael Catanzaro wrote: > Because Recommends and Supplements are installed by default, we need > to be careful and use them sparingly, only when it really makes sense > for some package to be pulled in for almost all users of another > package. Thus far, Fedora and RHEL have done

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 >

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

On Mon, Sep 25, 2023 at 4:39 AM Vít Ondruch wrote: > 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 > >> > >> This probably answers my question. So heads up t

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: https://src.fedoraproject.org/rpms/redhat-rpm-conf

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

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: hardened memory allocate port to linux-fedora system for secutiry

On 8/26/22 12:22, Daniel Micay via devel wrote: > Also, you hardened_malloc doesn't use a thread cache for security > reasons. It invalidates many of the security properties. If you compare > to glibc malloc in the light configuration with tcache disabled in glibc > malloc it will compare well, and

Re: Web Assembly on Fedora: interested in a Fedora SIG to work on this?

On 11/18/22 13:41, Michael Dawson wrote: > As Web Assembly (WASM) gains momentum we’d like to create a SIG as a place to > collaborate to ensure that Fedora is a great platform to both build and run > WASM workloads. This includes looking at the toolchains needed to build WASM > as a target and

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 /var/tmp/rpm-tmp.g0o

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 ecosystem

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 m

Re: Need help with LTO running out of memory

On 5/17/22 21:39, Orion Poplawski wrote: > libfabric 1.15.1 builds on x86_64 are failing because the final LTO link > seems to consume all available memory: ... > gcc: fatal error: Killed signal terminated program lto1 > compilation terminated. > lto-wrapper: fatal error: gcc returned 1 exit statu

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

On 6/30/22 04:54, Kevin Kofler via devel wrote: > I am still strongly opposed to degrading performance and size for all users > just to help the handful users of poorly-designed profiling tools. I agree. My career experience has been that the performance impact of having an extra register for c

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 frozen

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

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 wrote: >> I've written up some of the key ideas here: >> https://fedoraproject.org/wiki/BaseRuntimeInterface >> >> Any feedback would be appreciated, including bikeshed on componen

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 distinct from the GA stre

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 http://r

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 releasi

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 tha

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 attachmen

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

  1   2   >