Re: RPM for libblocksruntime?
Dne 3.1.2018 v 20:44 Ron Olson napsal(a): > I know this has come up before, though I apologize that I couldn't find the > info, but what is preventing Fedora from > including "libblocksruntime" as an available RPM? Debian provides it: > > https://packages.debian.org/source/jessie/libblocksruntime > > and it's a requirement for compiling Apple's Swift programming language on > Fedora. > > If it's just a question of somebody doing it, I'm happy to volunteer assuming > there isn't some hard-block that would > prevent it from being accepted. No. It is not in Fedora and neither in package review queue. So feel free to package it. There is one package in Copr https://copr.fedorainfracloud.org/coprs/tcg/devel/package/libblocksruntime/ you can use it as your starting point. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Specs coding standard (Was: Re: [Proposal] Mass change: remove executing gtk-update-icon-cache in %post/%postu/%postrans to update hicolor theme cache)
On 3 January 2018 at 22:51, Adam Williamson wrote: [..] > If you still want to do it, I mean, you do you, but it would be a > *terrible* idea to bundle clear and obvious technical improvements in > with the idea of some kind of spec style guide (and enforcement). > Please treat it as an entirely separate proposal. Thanks. I'm not proposing such spec style guide in native language. This could be done by simple indentation script over which must be filtered every spec file. I've already posted example of such script. This script needs to be updated (because in this form it was used more than decade ago) then used. On first time all spec files should be used and each new enhancements. Indentation is it is not a mater personal preferences. It is the same IMPORTANT as using exact indentation in C or other languages source code. it makes spec files code easier to read and understand by other people. It makes easier to find bugs by simple relaying on some coding patterns. I remember that on start use such indentation tool was possible not only bring the same style but find as well some number spec of CODING BUGS. Generally what I'm proposing is not kind of revolution but more evolution by use initially only few coding patterns which I've already listed like: - put in exact order spec fields in spec preamble - format all %description to 80 cols - put in spec exact order of %packages, %files and other sections - substitute exact strings to use macros After this such list can be extended and each time after passing agreement/voting to use exact new patterns all specs should be changed in one go. At some point on git server side this script could be hooked into commit filters to refuse commits of the specs if this script will be able to add some changes. In other words apply exact coding standard should be kind of continuous process. kloczek PS. I was wrong that it will be possible to modify 90% of the specs automatically. In reality proportions are completely opposite and only less than 10% is possible to change using some text substitution. This is clear indicator how really bad is with all Fedora spec common coding standards. -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
src.fedoraproject.org pull request merging
How is this supposed to work? I clicked on Merge in: https://src.fedoraproject.org/rpms/glibc/pull-request/3 But the task remains in the PENDING state, apparently indefinitely: “ Waiting We are waiting for your task to finish. This page should be refreshed automatically, but if not click Here Your task is currently PENDING ” Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: src.fedoraproject.org pull request merging
On Thu, Jan 04, 2018 at 09:44:44AM +0100, Florian Weimer wrote: > How is this supposed to work? I clicked on Merge in: > > https://src.fedoraproject.org/rpms/glibc/pull-request/3 > > But the task remains in the PENDING state, apparently indefinitely: > > “ > Waiting > > We are waiting for your task to finish. This page should be refreshed > automatically, but if not click Here > > Your task is currently PENDING > ” It looks like the workers did not survived the reboot from yesterday, I just restarted them, so it may take a little while to process all the pending tasks but it will get to it eventually :) Thanks for the heads-up and sorry for the inconvenience. Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Proposal] Mass change: remove executing gtk-update-icon-cache in %post/%postu/%postrans to update hicolor theme cache
If I am not mistaken, EPEL still needs quite large chunk of such scriptlets[1]. What would be the best way to maintain a SPEC file for both. https://fedoraproject.org/wiki/EPEL:Packaging#Scriptlets ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Proposal] Mass change: remove executing gtk-update-icon-cache in %post/%postu/%postrans to update hicolor theme cache
EPEL is maintained in separate branch and git is good in cherrypicking. That should be enough IMO. Vít Dne 4.1.2018 v 10:23 Samuel Rakitničan napsal(a): > If I am not mistaken, EPEL still needs quite large chunk of such > scriptlets[1]. What would be the best way to maintain a SPEC file for > both. > > https://fedoraproject.org/wiki/EPEL:Packaging#Scriptlets > ___ > 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
Fwd: Retiring OmegaT and considerations about its dependencies
Just reporting these actions: Retired package: - https://src.fedoraproject.org/rpms/OmegaT/ Orphaned packages: - https://src.fedoraproject.org/rpms/vldocking - https://src.fedoraproject.org/rpms/svnkit/ - https://src.fedoraproject.org/rpms/sqljet/ - https://src.fedoraproject.org/rpms/gnudiff/ - https://src.fedoraproject.org/rpms/sequence-library/ - https://src.fedoraproject.org/rpms/htmlparser/ Transfered main admin packages: - https://src.fedoraproject.org/rpms/snip/ - https://src.fedoraproject.org/rpms/jsap/ - https://src.fedoraproject.org/rpms/rundoc FYI -- Forwarded message -- From: Ismael Olea Date: Wed, Jan 3, 2018 at 2:41 PM Subject: Retiring OmegaT and considerations about its dependencies To: Discussion list for java related Fedora development < java-de...@lists.fedoraproject.org> Hi all: I delayed this for time enough. It's impossible to me to keep updated OmegaT in Fedora. Their development rhythm is pretty nice but they are adding frequent new dependencies and I can't make the effort to add them to Fedora. The good part is I'm working in the Flatpak approach which is less strict with dependencies and is multidistro too so Fedora users will get an alternative in the coming weeks.. Retiring OmegaT bring to discuss what to do with the dependencies which I honestly prefer to abandon. This is the situation: Packages to retire: - OmegaT, for the explained reasons (last version in Fedora: 2.6.3, last version upstream: 3.6.0/4.1.3) - svnkit, only used by OmegaT and broken in the current Fedora version - sqljet, only required by OmegaT and svnkit, broken in Fedora too - sequence-library, only required by svnkit and broken too OmegaT exclusive dependencies to be orphaned/retired: - gnudfif - htmlparser - vldocking OmegaT dependencies I want to delegate bc used by other package: - jsap, used by java-wakeonlan Actions: - Since I supposed there would be no interest on them I'll retire OmegaT, svnkit, sqljet and sequence-library - I'm gladly transfer maintenance of gnudiff, htmlparser and vldocking to anyone interest, so I'm going to orphan them - This message is cc:'d to Leamas, the maintainer of java-wakeonlan to offer him the ownership, if he declines I'll orphan it too. I'm open to your feedback, if any. Thanks! -- Ismael Olea http://olea.org/diario/ -- Ismael Olea http://olea.org/diario/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 Self Contained Change: Fontconfig 2.13
= Proposed Self Contained Change: Fontconfig 2.13 = https://fedoraproject.org/wiki/Changes/Fontconfig_2.13 Change owner(s): * Akira TAGOH Update fontconfig package to the latest version. == Detailed Description == Update fontconfig package to the latest version which contains the following features and bug fixes: * config file description support * allow sharing caches under the bind-mounted dirs * improve footprint on creating caches * variable fonts suppport == Scope == * Proposal owners: Package new version of fontconfig bug fixes (if any) Other developers: N/A (not a System Wide Change) Release engineering: #7223: https://pagure.io/releng/issue/7223 List of deliverables: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
GSoC Organization Applications Open Today
Hi All, I am going to start working on the Fedora GSoC Organizational application. I will also work on the structure for suggesting projects. # If you want to mentor Please use this time to start thinking about potential projects for GSoC Students. There are no wiki pages to update yet - you'll hear about those soon. (I think we might try something new this year to try and get more feedback on ideas). # If you want to help in a general or administrative way Contact me directly off list and we can figure out what works for you regards, bex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 Self Contained Change: Japanese Default Fonts to Google Noto
= Proposed Self Contained Change: Japanese Default Fonts to Google Noto = https://fedoraproject.org/wiki/Changes/JPDefaultFontsToNoto Change owner(s): * Akira TAGOH Changes the default fonts for Japanese to Google Noto. == Detailed Description == Changes the default fonts for Japanese to Google Noto. each typefaces will be changed as the following: * sans-serif * * VL Gothic -> Noto Sans JP * serif * * (No default serif) -> Noto Serif JP * monospace * * VL Gothic -> Noto Sans Mono CJK JP == Scope == * Proposal owners: - Update packages with the proper priority of fontconfig config file (vlgothic*fonts and google-cjk-noto-*-jp-fonts) - Update comps * Other developers: N/A (not a System Wide Change) * Release engineering: #7224: https://pagure.io/releng/issue/7224 * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 Self Contained Change: Korean Default Fonts to Google Noto
= Proposed Self Contained Change: Korean Default Fonts to Google Noto = https://fedoraproject.org/wiki/Changes/KRDefaultFontsToNoto Change owner(s): * Akira TAGOH Changes the default fonts for Korean to Google Noto. == Detailed Description == Changes the default fonts for Korean to Google Noto. each typefaces will be changed as the following: * sans-serif * * VL Gothic -> Noto Sans KR * serif * * (No default serif) -> Noto Serif KR * monospace * * VL Gothic -> Noto Sans Mono CJK KR == Scope == * Proposal owners: - Update packages with proper priority of fontconfig config file (naver-nanum-gothic*fonts and google-cjk-noto-*-kr-fonts) - Update comps * Other developers: N/A (not a System Wide Change) * Release engineering: #7225: https://pagure.io/releng/issue/7225 * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 Self Contained Change: VirtualBox Guest Integration
= Proposed Self Contained Change: VirtualBox Guest Integration = https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration Change owner(s): * Hans de Goede VirtualBox is popular, easy to use virtual-machine software. The purpose of this change is to ship the VirtualBox guest-drivers and -tools by default in the Fedora workstation product. == Detailed Description == VirtualBox runs on Windows. MacOS and Linux and is used by many users to try it Linux for the first time. As such it is important for Fedora to work well in VirtualBox virtual-machines. Like other virtual-machines VirtualBox virtual-machines can offer an enhanced user-experience when some VirtualBox specific guest-drivers and guest-tools are installed. This change is about adding the guest-drivers to the Fedora kernel package, packaging the userspace-tools (VirtualBox Guest Additions) and adding the VirtualBox Guest Additions package to the default package list for the Workstation product. == Scope == * Proposal owners: - The VirtualBox guest drivers have been merged into linux-next and will be in 4.16, the kernel-release with which F28 will ship. The separate vboxsf kernel-driver has been submitted upstream and is awaiting review upstream. If the vboxsf driver does not get accepted upstream in time we can ship with VirtualBox guest integration without shared-folder support. - Package VirtualBox Guest Additions userspace parts (Review Request) - Add VirtualBox Guest Additions package to the default package list for the Workstation product * Other developers: N/A (not a System Wide Change) * Release engineering: https://pagure.io/releng/issue/6880 * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: EXTERNAL: Re: After suspension
On 01/02/2018 01:18 PM, Al Stone wrote: On 12/26/2017 12:23 PM, Wells, Roger K. wrote: Small inconvenience but new and annoying: Machine is Thinkpad x260 uname -a: Linux rwells-x260 4.14.7-300.fc27.x86_64 #1 SMP Mon Dec 18 16:06:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Desktop: Gnome 3.26.4-1.fc27.x86_64 When the lid is opened on the suspended machine the screen saver appears and the clock proceeds to update until the enter key is hit. Then the clock stops updating for 27 seconds followed by the login entry dialog appearing. Then everything is back to normal. This began right after the upgrade from F26 to F27 and has persisted through one or two subsequent routine updates. There are inconsistencies, sometimes it only does it when there is only wireless connections and no wired options. Sometimes it doesn't do it at all, no pattern here. Sometimes the 27 second delay is much shorter but this is quite rare. I have been running Fedora/Gnome for years and have never seen this. Any thoughts or things to try to help pin it down will be appreciated. thanks There have been a lot of recent changes in ACPI code for suspend and hibernate; it's always possible that something got tweaked in a recent kernel that could affect this particular model of machine. That being said, the 27 second delay sounds like the laptop hibernated (not suspended); if you waited a variable length of time to open the lid again, it might explain some of the variation -- sometimes it suspended, sometimes it was caught before hibernation was complete, sometime it was caught after it had fully hibernated. The other things that occur to me are that perhaps hibernate was not working before for this model of laptop and now it does; or, the power settings changed defaults, or did not retain settings when updating; or, some of the recent changes for lid notification aren't quite right for this laptop (there have been a few cases of that). Those are some of the places where I would start looking, at least... It turns out that this delay only occurs when the suspend happened when an external filesystem is mounted. In this case a cifs mount, and IIRC there have been some issues related to version changes that necessitated specifying "vers=1.0" in the fstab file. I will do some experiments and report back if anything interesting develops. -- Roger Wells, P.E. leidos 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) roger.k.we...@leidos.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 System Wide Change: GHC 8.2
= System Wide Change: GHC 8.2 = https://fedoraproject.org/wiki/Changes/GHC_8.2 Change owner(s): * Jens Petersen * Haskell_SIG Update the Haskell GHC compiler from major version 8.0.2 to 8.2.2. == Detailed Description == This change involves updating the GHC Haskell compiler in Fedora to the latest major version and rebuilding all the Haskell packages in Fedora with it. GHC 8.2 bring a number of important performance improvements and new features, including improved DWARF support and support for the Backpack modular packaging system. There are more details the upstream release notes linked below. == Scope == * Proposal owners: rebuild updated Haskell packages in f28-ghc - we will base package versions off [LTS 10] - installation of shared libraries in common directory to speed up startup of executables * Other developers: None really, Haskell SIG can rebuild all packages as far as possible * Release engineering: https://pagure.io/releng/issue/7216 * List of deliverables: Updated Fedora packages * Policies and guidelines: None planned, but will review * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 System Wide Change: Hardening Flags Updates for Fedora 28
= System Wide Change: Hardening Flags Updates for Fedora 28 = https://fedoraproject.org/wiki/Changes/HardeningFlags28 Change owner(s): * Florian Weimer This system-wide change covers changes to the hardening flags in Fedora 28. == Detailed Description == * Compile all binaries with stack clash protection (-fstack-clash-protection). As a result, all stack overflows (i.e., situations where the allocated stack is completely exhausted) will reliably result in crashes. * Enable C++ standard library hardening with -D_GLIBCXX_ASSERTIONS. This turns on cheap range checks for C++ arrays, vectors, and strings. * Enable control flow protection on x86-64 using -fcf-protection=full -mcet. * Enable .got.plt isolation in binutils, to support a read-only GOT with lazy binding on systems which provide support for memory protection keys. == Scope == * Proposal owners: Propose changes to redhat-rpm-config to implement the new flags. redhat-rpm-config: Enable -fstack-clash-protection * Other developers: The redhat-rpm-config changes need to be merged. For packages which bypass the RPM compiler flags injection mechanism, developers need to manually implement the new flags. * Release engineering: #7220: https://pagure.io/releng/issue/7220 * List of deliverables: Not affected * Policies and guidelines: N/A (not needed for this Change; covered by the existing Packaging Guidelines) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Proposal] Mass change: remove executing gtk-update-icon-cache in %post/%postu/%postrans to update hicolor theme cache
On 4 January 2018 at 10:23, Samuel Rakitničan wrote: > If I am not mistaken, EPEL still needs quite large chunk of such > scriptlets[1]. What would be the best way to maintain a SPEC file for > both. $ rpm -q --filetriggers glib2 transfiletriggerin scriptlet (using /bin/sh) -- /usr/lib64/gio/modules gio-querymodules-64 /usr/lib64/gio/modules &> /dev/null || : transfiletriggerpostun scriptlet (using /bin/sh) -- /usr/lib64/gio/modules gio-querymodules-64 /usr/lib64/gio/modules &> /dev/null || : transfiletriggerin scriptlet (using /bin/sh) -- /usr/share/glib-2.0/schemas glib-compile-schemas /usr/share/glib-2.0/schemas &> /dev/null || : [ -e /app/share/glib-2.0/schemas ] && glib-compile-schemas /app/share/glib-2.0/schemas &> /dev/null || : transfiletriggerpostun scriptlet (using /bin/sh) -- /usr/share/glib-2.0/schemas glib-compile-schemas /usr/share/glib-2.0/schemas &> /dev/null || : [ -e /app/share/glib-2.0/schemas ] && glib-compile-schemas /app/share/glib-2.0/schemas &> /dev/null || : So as you see https://fedoraproject.org/wiki/EPEL:Packaging#Scriptlets art can be now removed and all those %post/%postun/posttrans glib schema caches updates can be removed as well. This is on my ToDo list however feel free take care remove this part from Fedora documentation and wipe out all those scriptlets as well. I really do not understand why someone who introduced those file triggers did not take care update Fedora documentation and apply all specs to remove all %post/%postun/posttrans. What is the reason? Just laziness or to high level of the Fedora bureaucracy making such mass changes to difficult? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Test-Announce] Re: Call for testing: updates to address today's CPU/kernel vulnerability
Brendan Conoboy wrote: > This is probably where the "AMD is safe" rumor started, but that is > only 1/3, maybe 2/3. Now that the context is public let's be clear: > even AMD processors are vulnerable without the patched kernel Adam has > asked for help testing. But the patched kernel that was pushed includes this patch: https://src.fedoraproject.org/cgit/rpms/kernel.git/tree/x86-cpu-x86-pti-Do-not-enable-PTI-on-AMD-processors.patch?h=f27&id=4c66c4ff79b96a5725f65cc7447dff3d2e851fd8 which means the changes have no effect whatsoever on AMD CPUs unless you explicitly boot with pti=on. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Test-Announce] Re: Call for testing: updates to address today's CPU/kernel vulnerability
>> This is probably where the "AMD is safe" rumor started, but that is >> only 1/3, maybe 2/3. Now that the context is public let's be clear: >> even AMD processors are vulnerable without the patched kernel Adam has >> asked for help testing. > > But the patched kernel that was pushed includes this patch: > https://src.fedoraproject.org/cgit/rpms/kernel.git/tree/x86-cpu-x86-pti-Do-not-enable-PTI-on-AMD-processors.patch?h=f27&id=4c66c4ff79b96a5725f65cc7447dff3d2e851fd8 > which means the changes have no effect whatsoever on AMD CPUs unless you > explicitly boot with pti=on. As far as currently known, AMD CPUs are not affected by "meltdown" - the security vulnerability which pti tries to close. There are other issues known as "Spectre" where pti does not help and which does not only affect Intel CPUs. Best regards, Clemens ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
FYI Fwd: Status of the second bootstrap of Fedora/RISC-V
- Forwarded message from "Richard W.M. Jones" - Date: Thu, 4 Jan 2018 11:29:51 + From: "Richard W.M. Jones" To: sw-...@groups.riscv.org Subject: [sw-dev] Status of the second bootstrap of Fedora/RISC-V I've almost reached the end of the allotted time available for bootstrapping Fedora/RISC-V for a second time, so this is a status report describing what I found and how far I got. Background -- Fedora is a binary Linux distribution. I first bootstrapped Fedora on RISC-V at the end of 2016 (the "first bootstrap"). https://fedoraproject.org/wiki/Architectures/RISC-V To do a Linux distro sanely we need full ABI guarantees at least between userspace and the kernel, so that involves mainly glibc and the kernel, and at that time the ABI was changing which meant we would need to go through the very costly process of re-bootstrapping everything multiple times. So after porting a large percentage (I think about 1/3rd) of all Fedora packages to the (then-) old glibc, I stopped work on it for about a year. glibc is supposed to go upstream in a few months from now, and that will guarantee a stable ABI between userspace and the kernel, allowing us to sanely build a Linux distro. I therefore put aside some time now to practice bootstrapping Fedora again (the "second bootstrap"). When glibc finally goes upstream we will need to do the third and final bootstrap, and from that point on older Fedora/RISC-V releases will be used to build each new Fedora release. Bootstrapping stages [These are historically named and based on the stages we used for aarch64.] stages 1 & 2: QEMU and cross-compiler are built from riscv-qemu and riscv-tools. https://github.com/rwmjones/fedora-riscv-bootstrap/blob/1858bd496378ddcce88a63c5ceda5483d7b4fdbe/Makefile#L21 https://github.com/rwmjones/fedora-riscv-bootstrap/blob/1858bd496378ddcce88a63c5ceda5483d7b4fdbe/Makefile#L71 stage 3: We build a minimal Fedora/x86_64 chroot and remove all x86_64 ELF binaries and libraries. Using the hosted cross-compiler we build RISC-V binaries and libraries and to replace the x86 ones. We then build a disk image from the chroot (it has many other hacky aspects to it) and boot it under qemu. https://github.com/rwmjones/fedora-riscv-bootstrap/blob/1858bd496378ddcce88a63c5ceda5483d7b4fdbe/Makefile#L117 The stage 3 disk image is just enough to run ‘rpmbuild’ and ‘gcc’ and a small handful of other tools, which is just enough to build RPMs. https://github.com/rwmjones/fedora-riscv-bootstrap/blob/1858bd496378ddcce88a63c5ceda5483d7b4fdbe/Makefile#L1386 stage 4: Using only RPMs generated from stage 3 we build a pristine disk image. This disk image contains only files controlled by RPMs [actually there are two additional files needed: /init and a poweroff binary, both eventually will be replaced by systemd]. https://github.com/rwmjones/fedora-riscv-bootstrap/blob/1858bd496378ddcce88a63c5ceda5483d7b4fdbe/Makefile#L1420 Using the stage 4 disk image we then build the rest of the Fedora packages. This requires some manual intervention, usually to break circular chains of dependencies of which there are many. There is also an autobuilder which can build packages from Fedora alphabetically or by shadowing the Fedora Koji build system. The autobuilder will need rewriting at some point since it can be made much more efficient now that we have working networking. Status of the second bootstrap -- I spent about 10 working days on this, and got a large part of the way through stage 3. You can see the status and download built packages here: https://github.com/rwmjones/fedora-riscv-bootstrap There is also a stage3 disk image here: http://oirase.annexia.org/riscv/ The eagle-eyed will notice that I'm still building some Fedora 24/25 packages (latest is Fedora 27). This is because those packages contain all the fixes from the first time around so it's convenient to use them for the moment. Even with these packages it should be sufficient to build Fedora 27 in stage 4 (particularly as packages get replaced with the new versions as we go along). Unfortunately I did not yet get a working stage 4 disk image. A glibc RPM is required for stage 4 since almost all packages depend on it, but the glibc build is hanging at some point for unclear reasons. Debugging anything inside the stage 3 QEMU instance is a recipe for pain and also debugging tools don't work inside stage 3. QEMU user networking (with virtio-net virtual device) worked fine for me, but I wasn't able to compile enough dependencies to get dhcp to work. Problems There is definitely a problem with GCC miscompiling with -O2 (which can be worked around using -O0). It affected at least 4 packages, but I was not able to produce any sort of minimal test case or common cause. The issue is being tracked in: https://github.com/riscv/riscv-gcc/issues/100 There is some bug in the kernel which causes it to hit a BUG_ON in fs/buffer.c
Fedora Rawhide-20180104.n.0 compose check report
Missing expected images: Workstation live i386 Kde live i386 Failed openQA tests: 20/128 (x86_64), 4/22 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20180103.n.0): ID: 184123 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/184123 ID: 184144 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/184144 ID: 184180 Test: x86_64 Atomic-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/184180 ID: 184190 Test: x86_64 universal install_sata@uefi URL: https://openqa.fedoraproject.org/tests/184190 ID: 184202 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/184202 ID: 184222 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/184222 ID: 184258 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/184258 ID: 184268 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/184268 ID: 184269 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/184269 Old failures (same test failed in Rawhide-20180103.n.0): ID: 184130 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/184130 ID: 184176 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/184176 ID: 184177 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/184177 ID: 184205 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/184205 ID: 184218 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/184218 ID: 184230 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/184230 ID: 184231 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/184231 ID: 184232 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/184232 ID: 184233 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/184233 ID: 184235 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/184235 ID: 184236 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/184236 ID: 184237 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/184237 ID: 184238 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/184238 ID: 184239 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/184239 ID: 184240 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/184240 ID: 184241 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/184241 Soft failed openQA tests: 67/128 (x86_64), 17/22 (i386) (Tests completed, but using a workaround for a known bug) New soft failures (same test did not soft fail in Rawhide-20180103.n.0): ID: 184140 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/184140 ID: 184141 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/184141 ID: 184162 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/184162 ID: 184253 Test: i386 universal install_blivet_no_swap URL: https://openqa.fedoraproject.org/tests/184253 ID: 184254 Test: i386 universal install_package_set_minimal URL: https://openqa.fedoraproject.org/tests/184254 ID: 184255 Test: i386 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/184255 ID: 184256 Test: i386 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/184256 ID: 184257 Test: i386 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/184257 ID: 184259 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/184259 ID: 184260 Test: i386 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/184260 ID: 184261 Test: i386 universal install_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/184261 ID: 184262 Test: i386 universal install_ext3 URL: https://openqa.fedoraproject.org/tests/184262 ID: 184263 Test: i386 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/184263 ID: 184264 Test: i386 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/184264 ID: 184265 Test: i386 universal install_blivet_btrfs URL: https://openqa.fedoraproject.org/tests/184265 ID: 184266 Test: i386
F28 System Wide Change: Strong crypto settings
= System Wide Change: Strong crypto settings = https://fedoraproject.org/wiki/Changes/StrongCryptoSettings Change owner(s): * Nikos Mavrogiannopoulos This change is about updating the current system-wide crypto policy to disable legacy and unused cryptographic protocols. == Detailed Description == Fedora includes several cryptographic components who's security doesn't remain constant over time. Algorithms such as (cryptographic) hashing and encryption typically have a lifetime after which they are considered either too risky to use or plain insecure. That would mean we need to phase out such algorithms from the default settings, or completely disable if they could cause irreparable issue. While in the past we did not disable algorithms in a consistent way (different applications utilized different policies), today we have a system-wide policy followed by a large part of Fedora components. That allows us to move consistently and deprecate algorithms system-wide. For rationale see RFC 7457 for a more complete list of attacks taking advantage of legacy crypto algorithms. The propose changes for default policy are: * Keep only TLS 1.2 (and TLS 1.3 when available) as enabled protocols and move the TLS 1.x, x<=1 to legacy level. * Require finite field parameters (RSA, Diffie-Hellman) of 2048 and more in the default settings That is a policy of: LEGACY MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc) Curves: all prime >= 255 bits (including bernstein curves) Signature algorithms: SHA-1 hash or better (not RIPEMD) Ciphers: all available > 112-bit key, >= 128-bit block (no rc4, but with 3DES) key exchange: ECDHE, RSA, DHE DH params size: >=1024 RSA params size: >=1024 TLS protocols: TLS >= 1.0 DEFAULT MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc) Curves: all prime >= 255 bits (including bernstein curves) Signature algorithms: with SHA-1 hash or better Ciphers: >= 128-bit key, >= 128-bit block (aes, camellia, chacha20, including aes-cbc) key exchange: ECDHE, RSA, DHE DH params size: >= 2048 RSA params size: >= 2048 TLS protocols: TLS >= 1.2 FUTURE MACs: All HMAC with SHA256 or better + all modern MACs (poly1305 etc) Curves: all prime >= 384 bits (including bernstein curves) Signature algorithms: SHA-384 hash or better Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated Encryption (AE) ciphers key exchange: ECDHE, DHE DH params size: >= 3072 RSA params size: >= 3072 TLS protocols: TLS >= 1.2 == Scope == * Proposal owners: The policies include in crypto-policies package need to be updated. * Other developers: * Crypto policies are updated to the settings above * OpenSSL is updated to allow setting policies for TLS versions * Release engineering: #7235: https://pagure.io/releng/issue/7235 * List of deliverables: * Crypto policies are updated to the settings above * OpenSSL, NSS, GnuTLS and all applications covered under the Fedora Crypto Policies follow the new crypto settings. * Policies and guidelines: No changes to packaging or other guidelines is needed. * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F28 Self Contained Change: Glibc collation update and sync with cldr
= Proposed Self Contained Change: Glibc collation update and sync with cldr = https://fedoraproject.org/wiki/Changes/Glibc_collation_update_and_sync_with_cldr Change owner(s): * Mike Fabian Update collation data in glibc to an ISO file from 2015 (in sync with Unicode 8.0.0) and sync collation rules of the locales with CLDR. == Detailed Description == The collation data in glibc is extremely out of date, most locales base their collation rules on an iso14651_t1_common file which has not been updated for probably more than 15 years. Therefore, all characters added in later Unicode versions are missing and not sorted at all which causes bugs like [[1]]. This change is about updating that iso146541_t1_common file to the latest available version from ISO which is from 2015 and up-to-date with Unicode 8.0.0. Because additions and changes in the syntax of the new iso146541_t1_common file, updating that file requires changing the collation rules of almost all locales. Because all these collation rules have to be touched anyway, this is a good opportunity to fix bugs in the collation ruies and sync them with the collation rules in CLDR. == Scope == * Proposal owners: Work with upstream, file bugs and provide patches where required. * Other developers: This change will impact glibc and everything which sorts strings using the collation functions from glibc. Other Developers do not need to make any changes from their end, but they need to watch how their application behaves with improved localedata. We need proper testing to see that it does not break any application. * Release engineering: #7234: https://pagure.io/releng/issue/7234 List of deliverables: N/A (not a System Wide Change) Policies and guidelines: No, this change does not require any updates to Policies or packaging guideline updates. Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: EXTERNAL: Re: After suspension
On 01/04/2018 06:18 AM, Wells, Roger K. wrote: > On 01/02/2018 01:18 PM, Al Stone wrote: >> On 12/26/2017 12:23 PM, Wells, Roger K. wrote: >>> Small inconvenience but new and annoying: >>> Machine is Thinkpad x260 >>> uname -a: Linux rwells-x260 4.14.7-300.fc27.x86_64 #1 SMP Mon Dec 18 >>> 16:06:12 >>> UTC 2017 x86_64 x86_64 x86_64 GNU/Linux >>> Desktop: Gnome 3.26.4-1.fc27.x86_64 >>> >>> When the lid is opened on the suspended machine the screen saver appears >>> and the >>> clock proceeds to update until >>> the enter key is hit. Then the clock stops updating for 27 seconds >>> followed by >>> the login entry dialog appearing. >>> Then everything is back to normal. >>> This began right after the upgrade from F26 to F27 and has persisted >>> through one >>> or two subsequent routine updates. >>> There are inconsistencies, sometimes it only does it when there is only >>> wireless >>> connections and no wired options. >>> Sometimes it doesn't do it at all, no pattern here. >>> Sometimes the 27 second delay is much shorter but this is quite rare. >>> I have been running Fedora/Gnome for years and have never seen this. >>> >>> Any thoughts or things to try to help pin it down will be appreciated. >>> >>> thanks >> There have been a lot of recent changes in ACPI code for suspend and >> hibernate; >> it's always possible that something got tweaked in a recent kernel that could >> affect this particular model of machine. >> >> That being said, the 27 second delay sounds like the laptop hibernated (not >> suspended); if you waited a variable length of time to open the lid again, it >> might explain some of the variation -- sometimes it suspended, sometimes it >> was >> caught before hibernation was complete, sometime it was caught after it had >> fully hibernated. The other things that occur to me are that perhaps >> hibernate >> was not working before for this model of laptop and now it does; or, the >> power >> settings changed defaults, or did not retain settings when updating; or, some >> of the recent changes for lid notification aren't quite right for this laptop >> (there have been a few cases of that). Those are some of the places where I >> would start looking, at least... >> > It turns out that this delay only occurs when the suspend happened when an > external filesystem is mounted. > In this case a cifs mount, and IIRC there have been some issues related to > version changes that necessitated specifying "vers=1.0" in the fstab file. > I will do some experiments and report back if anything interesting develops. > Interesting. Could there be an ordering dependency somewhere on resume? E.g., I need to start file system but can't do that until network is ready but the info I need to start the network is on the file system ... some weirdness like that? -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: EXTERNAL: Re: After suspension
On Thu, Jan 4, 2018 at 8:18 AM, Wells, Roger K. wrote: > It turns out that this delay only occurs when the suspend happened when an > external filesystem is mounted. > In this case a cifs mount, and IIRC there have been some issues related to > version changes that necessitated specifying "vers=1.0" in the fstab file. > I will do some experiments and report back if anything interesting develops. If you have external network mounts, such as CIFS and NFS, you might consider using autofs or automounts or whatever your OS supports, rather than /etc/fstab mounts, to enable them by default. There's nothing quite like needing to resolve an uncommitted change, or a release a mount that is being opened by a GUI file browser, to mess with reboot processes. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Self Introduction: Kevin Howell
Hi Kevin! Welcome aboard and and happy new year! Good to have you here around. Kind regards, Silvia FAS: Lailah 2018-01-03 19:28 GMT+01:00 Kevin Howell : > Hi folks, > > I'm a Red Hat employee since 2014 and have been a long-time user of > Fedora. On the job I work on mostly subscription-manager ( > https://github.com/candlepin/subscription-manager ) and also candlepin ( > https://github.com/candlepin/candlepin ). I dabble in various other tiny > side-projects (feel free to see https://github.com/kahowell if curious), > and have contributed a few PRs to a few other open source projects. > > I'm hoping to get started in packaging for Fedora, especially for > packaging subscription-manager and related packages, and I also aspire to > package other projects (outside of my day job) at some point. > > I'm looking for sponsorship into the packager group for this purpose. > Lately, I've been doing most of the release work for subscription-manager > (and packaging for RHEL). > > I go by khowell at Red Hat and Fedora; I'm kahowell on GitHub and FreeNode. > > Also, Happy 2018! > > Warm regards, > Kevin Howell > > ___ > 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: F28 System Wide Change: Hardening Flags Updates for Fedora 28
On 01/04/2018 05:28 AM, Jan Kurik wrote: = System Wide Change: Hardening Flags Updates for Fedora 28 = https://fedoraproject.org/wiki/Changes/HardeningFlags28 This change might be on a fast track to failure. == Detailed Description == * Compile all binaries with stack clash protection (-fstack-clash-protection). As a result, all stack overflows (i.e., situations where the allocated stack is completely exhausted) will reliably result in crashes. "All stack overflows"? That would be a feat. I tried to test, but: There is no such flag in gcc-7.2.1-2 (current f27). updates-testing for f27 has no update for gcc. Fedora 28 Rawhide 20180103.n.0 nightly compose cannot run Terminal. * Enable control flow protection on x86-64 using -fcf-protection=full -mcet. The wiki page https://fedoraproject.org/wiki/Changes/HardeningFlags28 links to (Documentation: Flow Enforcement Technology) https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf%7CControl which displays that site's HTTP-404 "Link not found" catch-all. I'd comment on the wiki page, but cannot login because I have only FAS "cla" access. I tried to get "cla+1" by joining a group, but the only groups with Join buttons were Marketing-related, and I'm not interested there. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Hardening Flags Updates for Fedora 28
On Thu, Jan 04, 2018 at 10:37:03AM -0800, John Reiser wrote: > I'd comment on the wiki page, but cannot login because I have only FAS "cla" > access. > I tried to get "cla+1" by joining a group, but the only groups > with Join buttons were Marketing-related, and I'm not interested there. Posting here is probably better than commenting on the wiki page, anyway -- I don't think people reliably track the wiki discussion pages. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Glibc collation update and sync with cldr
Hi, Shouldn't iso definition files (or unicode.org files) have their own package, so they are not buried deep inside glibc, and it is clear a periodic upstream sync is necessary ? Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Hardening Flags Updates for Fedora 28
On Thu, 2018-01-04 at 14:28 +0100, Jan Kurik wrote: > = System Wide Change: Hardening Flags Updates for Fedora 28 = > https://fedoraproject.org/wiki/Changes/HardeningFlags28 > > Change owner(s): > * Florian Weimer > > > This system-wide change covers changes to the hardening flags in > Fedora 28. I'm mostly in favor of this, but as the perpetrator of the current hardening flag hack in r-r-c, I really do wish there was a better way to set these defaults than -specs=blah. The current implementation is fragile and leaks out to the rest of the OS in weird ways. I'm aware that fixing this "sanely" would probably require fixing the toolchain to (allow us to) declare more intent about the destination of an ET_REL object when it's being built; fine, let's do that. Is anyone looking at this change from that perspective? - ajax ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
linux-firmware, microcode_ctl, libvirt, qemu updates?
Red Hat has released linux-firmware, microcode_ctl, libvirt, and qemu updates in addition to the kernel updates to mitigate against Meltdown and Spectre. Is anyone working on those updates for Fedora? Is there anything I can do to help with those? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: linux-firmware, microcode_ctl, libvirt, qemu updates?
On Thu, Jan 4, 2018 at 3:55 PM, Chuck Anderson wrote: > Red Hat has released linux-firmware, microcode_ctl, libvirt, and qemu > updates in addition to the kernel updates to mitigate against Meltdown > and Spectre. Is anyone working on those updates for Fedora? Is there > anything I can do to help with those? I'll be looking into linux-firmware. As far as I'm aware, there was nothing specific pushed upstream recently. If updates have shipped in RHEL I'd need to see if they added out-of-tree patches or if we're already covered by the fact that we keep linux-firmware very up to date. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Hardening Flags Updates for Fedora 28
== Detailed Description == * Compile all binaries with stack clash protection (-fstack-clash-protection). As a result, all stack overflows (i.e., situations where the allocated stack is completely exhausted) will reliably result in crashes. Rawhide-Live gcc-7.2.1-5.fc28.x86_64 recognizes -fstack-clash-protection but the flag has no effect on generated code. https://bugzilla.redhat.com/show_bug.cgi?id=1531283 "-fstack-clash-protection fails to check some stack allocations" -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Glibc collation update and sync with cldr
4.01.2018 16:59 Jan Kurik wrote: > [...] Therefore, all > characters added in later Unicode versions are missing and not sorted > at all which causes bugs like [[1]]. Seems like a link is missing. While at this, there is one more change in glibc, not directly related with this one but kinda similar. The ldconfig utility now forces the "C" sorting order while processing the files from /etc/ld.so.conf.d directory. Previously the sorting order was locale dependent which could be the same as the default "C" locale or slightly different. I'm not aware of any Fedora package where the order of the config files does matter, there was an example from Debian where they allow installing multiple versions of the same library and they add numerical prefixes to the file names to enforce the order. However, I hope this heads up is worth posting. Links: https://sourceware.org/bugzilla/show_bug.cgi?id=22505 https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=7d38eb3 https://sourceware.org/ml/libc-alpha/2017-12/msg00048.html Regards, Rafal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Glibc collation update and sync with cldr
4.01.2018 20:19 nicolas.mail...@laposte.net wrote: > > > Hi, > > Shouldn't iso definition files (or unicode.org files) have their own package, > so they are not buried deep inside glibc, and it is clear a periodic upstream > sync is necessary ? > I'm afraid it would be a huge effort to implement this because, as you have already noticed, the locale data are already buried deep inside glibc upstream. The process would require unbundling them and then either repackaging from the same source or update from CLDR if CLDR is newer than glibc. It's easier to contribute upstream and get a complete glibc tarball with CLDR data updated. OTOH, the locale data from glibc are already split into subpackages (langpacks) but the aim is not to distribute them all together (e.g., in a Live DVD) and not to force the user to install them all. They are still built from the same tarball. Regards, Rafal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Glibc collation update and sync with cldr
On Fri, 5 Jan 2018, Rafal Luzynski wrote: > be the same as the default "C" locale or slightly different. I'm not > aware of any Fedora package where the order of the config files does > matter apache cares in /etc/httpd/conf.d/ with virtual host enablement on ports along with multiple vhosts udev does in /etc/udev/rules.d/ notwithstanding a convention of doing manual application order with leading digits Indeed an undocumented switch mid release in RHEL 7 from a 'ls' type enumeration of a single directory, to a 'find' one not constrained by '-maxdepth' causes us some heartburn, as we previously had 'stashed' un-used initscripts ?? I fergit ?? down in /etc/sysconfig/network-scripts/attic/ that were mysteriously being applied. Not sort order related on the last, but still, I would tread lightly here -- Russ herrold ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: Glibc collation update and sync with cldr
5.01.2018 00:22 R P Herrold wrote: > > > On Fri, 5 Jan 2018, Rafal Luzynski wrote: > > > be the same as the default "C" locale or slightly different. I'm not > > aware of any Fedora package where the order of the config files does > > matter > > apache cares in /etc/httpd/conf.d/ with virtual host > enablement on ports along with multiple vhosts > [...] Sorry, I was not precise enough. I meant only files placed in /etc/ld.so.conf.d which may (and usually do) belong to different packages. So, again, I'm not aware of any Fedora package which puts a config file into /etc/ld.so.conf.d and cares about whether this config file is processed by ldconfig before or after other config files. Of course, other utilities may have also other config files and may have some rules of their order. They are not changed. This is a change only in ldconfig utility which belongs to glibc. Regards, Rafal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 System Wide Change: Hardening Flags Updates for Fedora 28
== Detailed Description == * Compile all binaries with stack clash protection (-fstack-clash-protection). As a result, all stack overflows (i.e., situations where the allocated stack is completely exhausted) will reliably result in crashes. Further investigation reveals that the intent is to insure that for each thread the in-use portion of the stack has no "holes" of pages that are not mapped and present in the virtual memory of the process, and any interval of stack pages belongs to exactly one thread. The mechanism is an explicit probe which writes ~0 into [one word on] each page [incrementally] whenever a new page or pages might be added to the stack such that there could be a gap of PAGE_SIZE or more. Infinite recursion is aborted by demanding (assuming) that a page with PROT_NONE separates the growing edge of the stack from any non-stack pages. The mechanism has consequences that I have not seen mentioned in the documentation: 1) Each on-stack allocation (both fixed- and variable-sized [alloca()]) always is present and "dirty". The stack probe (or the incremental growth of <= PAGE_SIZE bytes at a time) forces it to consume separate, real RAM. In a local declaration such as this, the comment is not valid: char temp[100]; /* only a prefix matters for resource consumption */ 2) The explicit write by the stack probe can mask a memcheck(valgrind) violation, at least until memcheck groks the probe. 3) The stack must be at least one page of real RAM, with at least one terminating guard page that has PROT_NONE. No more threads with small stacks packed sequentially adjacent. 4) All code must be generated by a compiler that enforces the probing policy, and all language support run-time routines also must enforce the policy. No mixing of old or foreign compilers with the new gcc. No mixing of old or foreign C libraries with the new glibc. Direct use by an app developer of the 'clone' system call is forbidden. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
