== 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 ins
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
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
ud
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 t
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 simi
== 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
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 hel
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?
___
d
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 2
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.fed
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
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
(-fstac
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-man
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
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:1
= 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 r
= 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 Descripti
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/18
- 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 Fedo
>> 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 thi
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 pus
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/modu
= 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 clas
= 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
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.
= 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 an
= 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
= 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 Googl
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 - y
= 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 fea
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/
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
> b
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
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 yo
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 H
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 s
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
37 matches
Mail list logo