Re: F29 System Wide Change: Hide the grub menu

[Gerald B. Cox]

Here is another bug that was opened in 2014 and closed "WONTFIX because it
was directly tied to F24.  Here we are with F28
and it still exists:  https://bugzilla.redhat.com/show_bug.cgi?id=1166978

Again, if we're concerned about the cleaning up of the boot process, why
are we apparently ignoring bugs that are associated
with processes that fail and throw out spurious messages?

If I issue:  systemctl status, it tells me my system is "degraded" because
of the following:

systemctl list-units --state=failed
  UNITLOAD   ACTIVE SUB
DESCRIPTION
● dbxtool.service loaded failed failed Secure Boot DBX (blacklist)
updater
● mcelog.service  loaded failed failed Machine Check Exception Logging
Daemon
● rngd.serviceloaded failed failed Hardware RNG Entropy Gatherer Daemon

The mcelog.service message is associated with rhbz#1166978
The dbxtool.service message is associated with rhbz#1508808
The rngd.service message is associated with rhbz#1490632






On Sun, Jun 10, 2018 at 10:02 AM, Gerald B. Cox  wrote:

> On Thu, Jun 7, 2018 at 2:07 AM, Hans de Goede  wrote:
>
>> Hi,
>>
>> On 04-06-18 21:17, Adam Williamson wrote:
>>
>>> On Thu, 2018-05-31 at 12:43 +0200, Jan Kurik wrote:
>>>
 = Proposed System Wide Change: Hide the grub menu =
 https://fedoraproject.org/wiki/Changes/HiddenGrubMenu

>>>
>>>
> I've updated this bug:  https://bugzilla.redhat.com/
> show_bug.cgi?id=1406844
>
> Basically, since at least F24 - maybe longer my boot has been interrupted
> by this message:
>
> > sp5100-tco sp5100-tco: I/O address 0x0cd6 already in use
>
> The bug was closed, and then cloned and reopened.
>
> As I mentioned before, I have no problem with the grub change as long as
> there is documentation
> that shows people how to reverse it if they wish - and Hans (thank you
> very much) has agreed to this.
>
> However, seems to me that having this bug (which appears to affect all AMD
> users) languishing
> for years seems to negate the reasoning behind this change.  If we're
> wanting to implement
> a more or less cosmetic change which saves a few seconds, having spurious
> messages
> interrupting and slowing down the boot process should also be resolved.
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LUPXRS7E7MBQEXIAT6EVE5XNMDEVB6YT/

Re: upcoming systemd-239 release — call for testing

[Adam Williamson]

On Mon, 2018-06-18 at 12:16 +, Zbigniew Jędrzejewski-Szmek wrote:
> Hi all,
> 
> we plan to release systemd-239 wednesday-ish and it will be landing in
> rawhide. There's a bunch of new functionality, see
> https://github.com/systemd/systemd/blob/master/NEWS. As always, the
> majority of commits is cleanups and bugfixes and the polishing of
> existing functionality. A big new feature is "portable services",
> currently in preview mode. There are man pages, but an introductory
> blog story is planned around the time of the release, so you might
> want to wait for that.
> 
> Please give it a try and report any bugs either in bugzilla [1] or
> upstream [2]. For testing, rpms are available from copr:
> https://copr.fedorainfracloud.org/coprs/zbyszek/systemd/build/768345/.

Thanks for the heads up on this. I built a test Rawhide netinst image
with the updated systemd and ran it through openQA. It mostly worked,
but several of the tests failed with this error in anaconda:

22:13:42,713 INF threading: Thread Failed: AnaInstallThread (140332673541888)
22:13:42,713 DBG exception: running handleException
22:13:42,716 CRT exception: Traceback (most recent call last):

  File "/usr/lib64/python3.6/site-packages/gi/overrides/BlockDev.py", line 843, 
in wrapped
ret = orig_obj(*args, **kwargs)

  File "/usr/lib64/python3.6/site-packages/gi/overrides/BlockDev.py", line 465, 
in lvm_vgcreate
return _lvm_vgcreate(name, pv_list, pe_size, extra)

GLib.GError: g-dbus-error-quark: Waiting for 'VgCreate' method of the 
'/com/redhat/lvmdbus1/Manager' object to finish failed: Failed to get Complete 
property of the / object: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: 
Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" 
doesn't exist
 (19)

it seems like an intermittent error, as not all the tests that create
LVM VGs failed, and restarting the failed tests mostly resulted in
passes...but I don't think we've seen this particular error, even as an
intermittent one, in recent Rawhide tests with systemd 238, so it seems
like it *could* be caused by the update. Any idea where this may be
coming from?

Here's one of the failed tests:

https://openqa.stg.fedoraproject.org/tests/318564

all log files etc. can be found on the "Logs & Assets" tab.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4EQTDYRY6NNLNIKCMKDP2E5WFVG2OYK6/

libdap 3.19.1 soname bump

[Orion Poplawski]

I'll be building libdap 3.19.1 soon in rawhide.  This includes a soname 
bump so dependencies will be rebuilt as well.


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KTJHDOMCTPLJZN6FJLPEQSN2L366U74N/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Paul Wouters]

On Thu, 14 Jun 2018, Tomas Mraz wrote:


On Wed, 2018-06-13 at 00:45 -0400, Paul Wouters wrote:



I don't think TLS 1.3 will see a wide deployment immediately. Sure,
the
famous top websites and top browsers will, but enterprises will not.
And
especially those with any kind of loggin/auditing requirements cannot
even allow TLS 1.3 with ephemeral DH on their network.

I would personally first try and disable TLS 1.0 in f29 and see how
much
problems that generates. Then in f30 or f31 disable TLS 1.1.


Except from the internet website statistics the TLS-1.1 only or as
maximum TLS version is not deployed. The sites are either TLS-1.0 max
version or they support also TLS-1.2. So this will not make almost any
difference and the impact on compatibility will be practically the same
as disabling even TLS-1.1.


Today a document was submitted to the TLS WG to phase out TLS 1.0 and 1.1:

https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00

I guess it all depends on the lifetime of old cheap android devices :P

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VZAJCPXLWPGNP2JGNZOOVFXILCLBFR5G/

Re: Heads up: Python 3.7 rebuild in progress

[Jerry James]

On Tue, Jun 19, 2018 at 3:42 AM Miro Hrončok  wrote:
> I'm now mass rebuilding everything. Will do a couple of rounds before I
> will look at the logs. If you see you package failing for a
> non-dependencies related reason, please try to fix it and rebuild it with:
>
>  fedpkg build --target=f29-python

I have fixed python-pybtex, python-pybtex-docutils, python-latexcodec,
python-sphinx-testing, and started a build of
python-sphinxcontrib-bibtex which I think has a high chance of
succeeding.  That should unblock the python-BTrees build, which in
turn should unblock the rest of the ZODB/ZEO stack.  Unfortunately,
that is all the time I have for tonight.  I can probably help out
again about 20 hours from now, if needed.

Regards,
--
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SFNXDXPP3FKZTYYD4AO3VCMMTZNFZDLN/

Fedora Rawhide-20180619.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 4/138 (x86_64), 1/2 (arm)

New failures (same test did not fail in Rawhide-20180617.n.0):

ID: 250587  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/250587
ID: 250615  Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/250615

Old failures (same test failed in Rawhide-20180617.n.0):

ID: 250596  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/250596
ID: 250640  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/250640
ID: 250677  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/250677

Soft failed openQA tests: 3/138 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Rawhide-20180617.n.0):

ID: 250705  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/250705
ID: 250706  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/250706
ID: 250720  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/250720

Passed openQA tests: 128/138 (x86_64)

New passes (same test did not pass in Rawhide-20180617.n.0):

ID: 250612  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/250612
ID: 250621  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/250621
ID: 250623  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/250623
ID: 250629  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/250629
ID: 250634  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/250634
ID: 250638  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/250638
ID: 250651  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
base_services_start
URL: https://openqa.fedoraproject.org/tests/250651
ID: 250696  Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/250696

Skipped openQA tests: 1 of 140

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
Used mem changed from 197 MiB to 167 MiB
Previous test data: https://openqa.fedoraproject.org/tests/250179#downloads
Current test data: https://openqa.fedoraproject.org/tests/250589#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
System load changed from 1.59 to 1.87
Used mem changed from 197 MiB to 167 MiB
Previous test data: https://openqa.fedoraproject.org/tests/250180#downloads
Current test data: https://openqa.fedoraproject.org/tests/250590#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
System load changed from 0.40 to 0.25
Previous test data: https://openqa.fedoraproject.org/tests/250200#downloads
Current test data: https://openqa.fedoraproject.org/tests/250610#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
2 packages(s) removed since previous compose: libcryptui, libgnome-keyring
Used swap changed from 6 MiB to 1 MiB
Previous test data: https://openqa.fedoraproject.org/tests/250202#downloads
Current test data: https://openqa.fedoraproject.org/tests/250612#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
2 packages(s) removed since previous compose: libcryptui, libgnome-keyring
System load changed from 2.51 to 2.04
Used swap changed from 5 MiB to 1 MiB
Previous test data: https://openqa.fedoraproject.org/tests/250203#downloads
Current test data: https://openqa.fedoraproject.org/tests/250613#downloads

Installed system changes in test x86_64 Workstation-boot-iso install_default: 
System load changed from 1.84 to 2.38
Used swap changed from 11 MiB to 13 MiB
Previous test data: https://openqa.fedoraproject.org/tests/250216#downloads
Current test data: https://openqa.fedoraproject.org/tests/250626#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
51 packages(s) removed since previous compose: avahi-gobject, bubblewrap, 
cyrus-sasl-md5, cyrus-sasl-scram, farstream02, flatpak, flatpak-libs, 
kaccounts-providers, ktp-accounts-kcm, ktp-approver...
System load changed from 2.07 to 1.81
Previous test data: https://openqa.fedoraproject.org/tests/250219#downloads
Current test data: https://openqa.fedoraproject.org/tests/250629#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
51 packages(s) removed since previous compose: avahi-gobject, bubblewrap, 
cyrus-sasl-md5, 

[Bug 1589471] perl-Email-Address-XS-1.04 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1589471



--- Comment #4 from Fedora Update System  ---
perl-Email-Address-XS-1.04-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/36QOMAJPRQXGR5R4XKCPZNUSRDJDIEE7/

Re: Release criteria proposal: drop kickstart package criterion

[Dusty Mabe]

On 06/19/2018 08:33 PM, Adam Williamson wrote:

> 
> A further update here: it appears releng, at least for the present, is
> inclined to favour manual tagging of just the kickstarts for the actual
> release compose. Given that, I think we should still have a release
> criterion (since this will be a manual process we'd better have
> something to trigger us to make sure it happens). I propose we replace
> the existing criterion with this:
> 
> "At the time of the release, the [https://pagure.io/fedora-kickstarts
> fedora-kickstarts git repository] must have a tag matching the commit used to 
> produce the accepted release candidate compose. The tag's name must clearly 
> and unambiguously match the release number."
> 
> It'd probably be ideal to tag the repo for Beta releases too, but we
> probably only need to *require* the tag to be done for Final.
> 
> How's that sound?
> 

+1 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FEC2P5EETMIFRTKWGQHWNUUIHTNCYPQK/

Fedora rawhide compose report: 20180619.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20180617.n.0
NEW: Fedora-Rawhide-20180619.n.0

= SUMMARY =
Added images:0
Dropped images:  7
Added packages:  3
Dropped packages:0
Upgraded packages:   209
Downgraded packages: 1

Size of added packages:  10.14 MiB
Size of dropped packages:0 B
Size of upgraded packages:   7.90 GiB
Size of downgraded packages: 23.06 MiB

Size change of upgraded packages:   -184.29 MiB
Size change of downgraded packages: 2.41 KiB

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20180617.n.0.iso
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20180617.n.0.s390x.qcow2
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20180617.n.0.iso
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20180617.n.0.iso
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20180617.n.0.s390x.tar.xz
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20180617.n.0.s390x.tar.xz
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20180617.n.0.s390x.raw.xz

= ADDED PACKAGES =
Package: airspyone_host-1.0.9-3.20180615gitbfb66708.fc29
Summary: AirSpy host tools and library
RPMs:airspyone_host airspyone_host-devel
Size:530.58 KiB

Package: perl-Lingua-EN-PluralToSingular-0.19-2.fc29
Summary: Change an English plural to a singular
RPMs:perl-Lingua-EN-PluralToSingular
Size:18.05 KiB

Package: python-visvis-1.11.1-3.fc29
Summary: Python library for visualization of 1D to 4D data in an object 
oriented way
RPMs:python2-visvis python3-visvis
Size:9.61 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  NetworkManager-1:1.12.0-0.1.fc29
Old package:  NetworkManager-1:1.10.6-3.fc29.1
Summary:  Network connection manager and user applications
RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth 
NetworkManager-config-connectivity-fedora NetworkManager-config-server 
NetworkManager-dispatcher-routing-rules NetworkManager-libnm 
NetworkManager-libnm-devel NetworkManager-ovs NetworkManager-ppp 
NetworkManager-team NetworkManager-tui NetworkManager-wifi NetworkManager-wwan
Added RPMs:   NetworkManager-dispatcher-routing-rules
Size: 39.11 MiB
Size change:  2.96 MiB
Changelog:
  * Fri May 11 2018 Beniamino Galvani  - 1:1.10.8-1
  - Update to 1.10.8 release

  * Thu May 31 2018 Lubomir Rintel  - 1:1.11.4-1
  - Update to a development snapshot of NetworkManager 1.12
  - Switch crypto to gnutls
  - Add dispatcher-routing-rules subpackage
  - Switch to Python 3-only build root

  * Sat Jun 16 2018 Thomas Haller  - 1:1.12.0-0.1
  - Update to 1.12-rc1 pre-release


Package:  a2ps-4.14-38.fc29
Old package:  a2ps-4.14-37.fc28
Summary:  Converts text and other types of files to PostScript
RPMs: a2ps
Size: 7.61 MiB
Size change:  -3.16 KiB
Changelog:
  * Mon Jun 18 2018 Zdenek Dohnal  - 4.14-38
  - removing install-info, because now it is done automatically


Package:  ansible-lint-3.4.23-1.fc29
Old package:  ansible-lint-3.4.21-1.fc29
Summary:  Best practices checker for Ansible
RPMs: python3-ansible-lint
Dropped RPMs: python2-ansible-lint
Size: 58.06 KiB
Size change:  -54.07 KiB
Changelog:
  * Tue Apr 03 2018 Dan Callaghan  - 3.4.21-2
  - no longer building Python 2 bits in releases which have dropped Python 2
  - added missing requirements on PyYAML and six

  * Sun Jun 17 2018 Parag Nemade  - 3.4.22-1
  - Update to 3.4.22 version (#1559645)

  * Mon Jun 18 2018 Parag Nemade  - 3.4.23-1
  - Update to 3.4.23 version (#1592159)


Package:  appcenter-0.2.9-2.fc29
Old package:  appcenter-0.2.9-1.fc29
Summary:  Software Center for the Pantheon desktop
RPMs: appcenter
Size: 2.43 MiB
Size change:  672 B
Changelog:
  * Wed Jun 13 2018 Fabio Valentini  - 0.2.9-2
  - Rebuild for granite5 soname bump.


Package:  audience-0.2.5-3.fc29
Old package:  audience-0.2.5-2.fc29
Summary:  Audience video player
RPMs: audience
Size: 1.34 MiB
Size change:  552 B
Changelog:
  * Wed Jun 13 2018 Fabio Valentini  - 0.2.5-3
  - Rebuild for granite5 soname bump.


Package:  bash-4.4.23-1.fc29
Old package:  bash-4.4.19-2.fc29
Summary:  The GNU Bourne Again shell
RPMs: bash bash-devel bash-doc
Size: 20.30 MiB
Size change:  3.68 KiB
Changelog:
  * Tue Jun 12 2018 Siteshwar Vashisht  - 4.4.23-1
  - Update to bash-4.4 patchlevel 23
Resolves: #1585510


Package:  bash-completion-1:2.8-1.fc29
Old package:  bash-completion-1:2.7-4.fc29
Summary:  Programmable completion for Bash
RPMs: bash-completion
Size: 279.36 KiB
Size change:  7.31 KiB
Changelog:
  * Tue Jun 12 2018 Siteshwar Vashisht  - 1:2.8-1

Re: Packages which call install-info in scriptlets

[Jason L Tibbitts III]

Update to texinfo which should fix the problem with info nodes not
automatically being removed:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-066a9994da

Please test and give karma.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GVGXV6O4SBOIHQOF42HTEDWGLKDGOY32/

Re: Release criteria proposal: drop kickstart package criterion

[Adam Williamson]

On Tue, 2018-06-12 at 12:11 -0700, Adam Williamson wrote:
> On Mon, 2018-06-04 at 16:39 -0700, Adam Williamson wrote:
> > Hi, folks!
> > 
> > We currently have a Final release criterion that reads as follows:
> > 
> > "A spin-kickstarts package which contains the exact kickstart files
> > used to build the release must be present in the release repository.
> > The included kickstarts must define the correct set of release
> > repositories.
> > 
> > Why?
> > 
> > This is considered part of Fedora's duty to be 'self-hosting': the
> > kickstarts used to produce the release images are a vital piece of
> > information required to duplicate that release, so they must be
> > preserved along with the release."
> > 
> > Lately this requirement has been fairly annoying in practice. Updating
> > the package prior to release does not appear to be in anyone's regular
> > schedule, so invariably what happens is shortly before the release
> > deadline I realize we haven't built a 'release' spin-kickstarts package
> > and have to file a blocker bug and ping people with the necessary
> > permissions (of which there are only a few) to build one in a tearing
> > hurry. Then we have to approve the blocker bug and push the updated
> > package through the freeze, all wasting time we could be spending on
> > more important fixes.
> > 
> > The benefit here is really fairly tiny, as well. It's arguable whether
> > anyone cares particularly whether a Fedora release, as a frozen
> > artifact, is 100% internally reproducible (and I'm not sure whether our
> > releases actually *are* reproducible in any case, these days, I'm not
> > at all sure we ship all the necessary metadata and so on for *every
> > single deliverable* within the distribution).
> > 
> > These days I'd suggest it should be quite acceptable to simply use git
> > tags for this purpose. It should be quite easy for rel-eng to adjust
> > the release scripts to create a tag in the fedora-kickstarts repo (and
> > why not fedora-comps too, while we're at it) for each 'candidate'
> > compose, named for the compose ID. That would make it very easy to
> > access the correct kickstarts for any Fedora candidate compose just by
> > a 'git checkout', with no need for the cumbersome work of getting the
> > package into the compose.
> > 
> > Naturally this would go along with updates to any relevant docs or wiki
> > pages, recommending to use the git repository instead of the RPM
> > packages, and explaining the tagging scheme. As for the package, we
> > could either keep it but not sweat about updating it for each release,
> > retire it entirely, or change it to contain only a text file pointing
> > to the git repository (or to the doc / wiki page that explains the git
> > repo location and tagging strategy).
> > 
> > Thoughts? Thanks!
> 
> So an update on this: as the response has generally been positive I'm
> planning to go ahead with it, but I think we should make sure the repo
> tagging thing is done *before* we remove the criterion. So I've filed
> https://pagure.io/releng/issue/7568 for that. Once that's resolved I'll
> go ahead with the criterion removal and docs updates.

A further update here: it appears releng, at least for the present, is
inclined to favour manual tagging of just the kickstarts for the actual
release compose. Given that, I think we should still have a release
criterion (since this will be a manual process we'd better have
something to trigger us to make sure it happens). I propose we replace
the existing criterion with this:

"At the time of the release, the [https://pagure.io/fedora-kickstarts
fedora-kickstarts git repository] must have a tag matching the commit used to 
produce the accepted release candidate compose. The tag's name must clearly and 
unambiguously match the release number."

It'd probably be ideal to tag the repo for Beta releases too, but we
probably only need to *require* the tag to be done for Final.

How's that sound?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TYO75UEQZI4O4VLWZ7L4A46CVZASDCPY/

[Bug 1593045] New: perl-File-Find-Object-Rule-0.0309 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1593045

Bug ID: 1593045
   Summary: perl-File-Find-Object-Rule-0.0309 is available
   Product: Fedora
   Version: rawhide
 Component: perl-File-Find-Object-Rule
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: i...@cicku.me, p...@city-fan.org,
perl-devel@lists.fedoraproject.org



Latest upstream release: 0.0309
Current version/release in rawhide: 0.0307-1.fc29
URL: http://search.cpan.org/dist/File-Find-Object-Rule/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/2887/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/FBSJV6LYJ7C7FM45RN26ZFJSMCIMSRRB/

[Bug 1593043] New: perl-CPAN-Perl-Releases-3.64 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1593043

Bug ID: 1593043
   Summary: perl-CPAN-Perl-Releases-3.64 is available
   Product: Fedora
   Version: rawhide
 Component: perl-CPAN-Perl-Releases
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 3.64
Current version/release in rawhide: 3.62-1.fc29
URL: http://search.cpan.org/dist/CPAN-Perl-Releases/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/5881/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/QPV6HETOJ5DBP4ZQ2Y6O2DYBQDD2AOVN/

[Bug 1593041] New: perl-BSON-v1.6.5 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1593041

Bug ID: 1593041
   Summary: perl-BSON-v1.6.5 is available
   Product: Fedora
   Version: rawhide
 Component: perl-BSON
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: v1.6.5
Current version/release in rawhide: 1.6.4-1.fc29
URL: http://search.cpan.org/dist/BSON/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/12628/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/VXJLYXXM4SMFMUS6IIRHDYI6KAWHV3M3/

Re: New FESCo Meeting Time and Ticket Policy

[Josh Boyer]

On Tue, Jun 19, 2018 at 2:56 PM Langdon White  wrote:
>
>
>
> On Tue, Jun 19, 2018 at 2:42 PM Matthew Miller  
> wrote:
>>
>> On Tue, Jun 19, 2018 at 10:57:17AM -0400, Randy Barlow wrote:
>> > I also believe we would be willing to reconsider this policy if it
>> > doesn't work out in practice. We're really just looking for ways for us
>> > to operate more efficiently here.
>>
>> For that matter, if a decision is made and it later becomes clear that
>> it isn't working out, or didn't have enough broad community input, or
>> whatever else, we can always revisit. I mean, we don't want to rehash
>> things forever, but it's not like FESCo decisions get laser-engraved on
>> titanium plates, either.
>
>
>
> How about a once-a-meeting email to devel@ 24hrs before the meeting with 
> which tickets will be expiring as of that meeting? Might this give the best 
> of both?
>
> * FESCo members can vote immediately (or not)
> * email goes out

If someone wants to automate that, it would be good.  If we're relying
on people to do this, it's actually 2x the work we put into creating
an agenda now and I'm not in favor of it.  Particularly with a
rotating chair.

> * community can review and decide to propose issue for discussion by replying 
> to the email or deciding to attend the meeting once a week as in the past
> * during the "agenda creation" portion of the meeting, concerned community 
> members can ask that XYZ issue be discussed and chairperson reviews any email 
> requested tickets, all issues now to be discussed marked with "meeting" tag

There's no "agenda creation" portion of the meeting.  It's set prior
to the meeting.  That being said, there's always an open floor section
and if the voting scheme here works we'll actually have more time for
it and let people bring concerns up therein.

> * Community Member presents the case (either by pointing to issue comment or 
> by doing it real time)

They can do this at any time by commenting the ticket or during Open floor.

> I really want to see pagure allow for tags that non-project-members can 
> assign which would be a simpler way to solve the "email back to chairperson" 
> problem. Not actually sure if there is an RFE for this. Have the same problem 
> with the modularity-wg meeting-tag.

That would be neat.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RRNLJWK674RCWW2FXQHUQILC6XPJ2MJB/

Re: New FESCo Meeting Time and Ticket Policy

[Langdon White]

On Tue, Jun 19, 2018 at 2:42 PM Matthew Miller 
wrote:

> On Tue, Jun 19, 2018 at 10:57:17AM -0400, Randy Barlow wrote:
> > I also believe we would be willing to reconsider this policy if it
> > doesn't work out in practice. We're really just looking for ways for us
> > to operate more efficiently here.
>
> For that matter, if a decision is made and it later becomes clear that
> it isn't working out, or didn't have enough broad community input, or
> whatever else, we can always revisit. I mean, we don't want to rehash
> things forever, but it's not like FESCo decisions get laser-engraved on
> titanium plates, either.
>


How about a once-a-meeting email to devel@ 24hrs before the meeting with
which tickets will be expiring as of that meeting? Might this give the best
of both?

* FESCo members can vote immediately (or not)
* email goes out
* community can review and decide to propose issue for discussion by
replying to the email or deciding to attend the meeting once a week as in
the past
* during the "agenda creation" portion of the meeting, concerned community
members can ask that XYZ issue be discussed and chairperson reviews any
email requested tickets, all issues now to be discussed marked with
"meeting" tag
* Community Member presents the case (either by pointing to issue comment
or by doing it real time)

I really want to see pagure allow for tags that non-project-members can
assign which would be a simpler way to solve the "email back to
chairperson" problem. Not actually sure if there is an RFE for this. Have
the same problem with the modularity-wg meeting-tag.

Langdon

-- 
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BWTDQZIWG5PNAYIPM2UZ6FUXKU2J4FDA/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IKZKUMA44HEKKQ6QVXU4A3SDM4FRDKVX/

[Bug 1589381] perl-Cflow not actually linked to flow-tools since -17

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1589381



--- Comment #5 from Chris Tracy  ---
Figured out how to pull the updated package out of koji.  Works here, thanks. 
Look forward to it moving into EPEL.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/HKOX2UHHXQQFOQ6HHPU2WOCUW62GQF5U/

[Bug 1589381] perl-Cflow not actually linked to flow-tools since -17

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1589381



--- Comment #4 from Chris Tracy  ---
Still waiting for perl-Cflow-1.053-35.el7 to actually show up in the
epel-testing mirrors so I can test it...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/BQCVAQPUQBLNFQKGHWUCO4FYBRENVMPX/

Re: New FESCo Meeting Time and Ticket Policy

[Matthew Miller]

On Tue, Jun 19, 2018 at 10:57:17AM -0400, Randy Barlow wrote:
> I also believe we would be willing to reconsider this policy if it
> doesn't work out in practice. We're really just looking for ways for us
> to operate more efficiently here.

For that matter, if a decision is made and it later becomes clear that
it isn't working out, or didn't have enough broad community input, or
whatever else, we can always revisit. I mean, we don't want to rehash
things forever, but it's not like FESCo decisions get laser-engraved on
titanium plates, either.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BWTDQZIWG5PNAYIPM2UZ6FUXKU2J4FDA/

Re: F29 System Wide Change: Build non-RELRO ELF binaries with .plt.got isolation

[Florian Weimer]

On 06/19/2018 03:24 PM, Peter Pentchev wrote:

...this came along.  So what is supposed to stop an attacker who can
inject arbitrary code into the program from modifying the keys?

Or is this supposed to stop buffer-overflow exploits that overwrite
the GOT and thus cause the attacker's code to be executed later?


Yes, it's about protecting the GOT.  We can't do much about having the 
WRPKRU opcode in the process image.  The restore can be hidden in the 
XRSTOR instruction in the assembler trampoline (which is already there 
today for other reasons), and the initial update (which makes the GOT 
writable) can be hardended somewhat.  But it's about making it harder to 
redirect execution through the GOT in the first place.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SPIRQLYHBIXOZ7YZIMRVU3GX2HAORJGD/

Re: F29 System Wide Change: Make BootLoaderSpec the default

[Chris Murphy]

On Tue, Jun 19, 2018 at 3:40 AM, Lennart Poettering
 wrote:

> The boot loader spec suggests that $BOOT and the ESP are the same
> thing, and I am very sure this is the best and simplest approach for
> all images that have no explicit reason to depart from that. However,
> the spec does not actually require $BOOT to be the same as the
> ESP. The freedom to make $BOOT != ESP was added as a compromise,
> because some folks were adamant that resizing the ESP on multi-boot
> systems should not be done (i personally don't think it's as big a
> prob as people claim though...).

It's effectively not possible because in every layout, from Windows to
all distros, it's wedged in by other file systems. You literally can't
resize it.

All you could do is create a new bigger one, copy over the contents of
old to new, and then wipefs the old one, and change the partition type
GUID or remove the partition entry.

I seriously doubt the installer folks want to take responsibility for
such a thing, and update the various NVRAM boot entries accordingly.


>
> Today, systemd has this generator that will automatically find the ESP
> for you and mount it to /efi or /boot. The idea behind that is that
> installers can choose whether they want to merge $BOOT and the ESP or
> not:
>
> 1. If they are merged, then the ESP (and thus also $BOOT) is mounted
>to /boot, automatically by the generator. No other preparation is
>needed, and /efi does not exist. (Distros could even make /efi a
>symlink → /boot, but I personally wouldn't bother).
>
> 2. If they are not merged, then the ESP is mounted to /efi,
>automatically by the generator. And /boot would be mounted as $BOOT
>via an /etc/fstab entry added by the installer.
>
> And as mentioned, I'd generally recommend everybody to go for option
> #1 because it is a lot simpler, and EFI has trivial access to all
> kernels and such.

Except, it's not simple for installers to migrate to a new bigger ESP
in the dual boot case. And having different layouts for UEFI and BIOS
and whether there's dual boot or single boot, isn't simpler.

If $BOOT is defined as where non-static bootloader config + kernel +
initramfs goes, and if shared $BOOT is a good thing for Linux distros,
then the $BOOT to always create is type 0xEA / bc13c2ff... and not
conflate it with the location for the bootloader binaries: the ESP on
UEFI, and either MBR gap or BIOSBoot on BIOS.

And the volume format for 0xEA / bc13c2ff... I don't know that it's
possible to get consensus. But set that aside, it means the BLS file
format needs a way to reference files on another volume. Assuming all
paths are local doesn't seem workable except in the most narrow case,
and always narrow casing this is what prevents it from being adopted.

Windows, macOS, the various distros - they all have substantial
differences in how they boot. But the one commonality I most
consistently see? The bootloader teaches the pre-boot environment,
right off the bat, how to read a real file system, and from that real
file system the kernel and initramfs are loaded.



>The boot loader can start the EFI shell and its
> trivial to explore the contents and everything and manually boot any
> kernel you like. This approach also means that no /etc/fstab entry is
> needed, and thus things are a lot more self-sufficient and robust.
>
> It would be my assumption that all OS images generated in full by some
> image builder would go for option #1, and option #2 would only be used
> when a traditional installer such as anaconda is used that is supposed
> to add a Fedora installation to a system that is already set up
> otherwise, i.e. already has an EFI partition in place that is
> considered too small. i.e. option #2 is the multi-boot-with-windows
> usecase, while option #1 is for pretty much everything else.

Flowchart that paragraph, it's a frigging maze. This is a Choose Your
Own Adventure spec. This paragraph itself demonstrates the
inconsistency, depending on what firmware you have, and what layout
existed before hand. And that tells me there isn't enough abstraction
that things are that variable and messy.

I don't like the idea of asking users  helping users, to have to be so
familiar with such esoteric things. It makes support, repair,
maintenance, upgrades, testing, documentation harder. There are too
many exceptions.

Just give up. The ESP belongs to the OSLoaders and a static
configuration if needed, so that we can figure out where to jump to
immediately to get the BLS snippets, the kernel, and initramfs. And
make that location consistent no matter the firmware, no matter the
prior layout.



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

[Bug 1592742] perl-CPAN-Perl-Releases-3.62 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1592742



--- Comment #4 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.62-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-eec51163ca

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/TWO4DGIGYKQUCQS2Z27DQU7TWSV25DRN/

[Bug 1592742] perl-CPAN-Perl-Releases-3.62 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1592742

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.62-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-97d336e0e9

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/WTQXWOD5YMEIV3X25AYDTYUS53VFWAVY/

Re: F29 System Wide Change: Make BootLoaderSpec the default

[Chris Murphy]

On Mon, Jun 18, 2018 at 5:37 PM, Andrew Lutomirski  wrote:
>> On Jun 18, 2018, at 3:54 PM, Chris Murphy  wrote:


>> Getting journal support in the bootloader isn't going to happen. I've
>> already talked to the various fs upstreams about it.
>>
>
> Why are you talking to the fs upstreams?  The problem is a bug in
> GRUB, full stop.

OK so you're going to blame uboot and syslinux and others for not
supporting JBD2 and journal replay as well? I disagree that its worth
the effort.

> All this freeze crap that Fedora does is just
> papering over the bug.

Yeah I don't like any of that either, and in retrospect I should not
have bought off on the idea. But that's getting off topic.

>IMO the right thing to do is to get *GRUB*
> upstream to have a fully functional implementation of *one*
> widely-supported fs.  Hmm, GRUB supports F2FS, and F2FS is
> log-structured, right?  So I don't see how GRUB could fail to read a
> dirty filesystem correctly even if it wanted to.

Journaled file systems have the journal bolted on. It's a completely
different beast. To read any structure, there must be code. There's
simply no code to read the XFS or ext3/4 log. It appears there was an
attempt to get GRUB (and I think it's GRUB legacy) to support JBD2 but
it was abandoned. I don't know the history.


> Or someone could design a very simple, highly reliable, filesystem
> designed to make it easy to do atomic-enough updates and to read
> reliably.  Think VFAT-like but with a full atomic swap of all FS
> metadata.  Or a dead-simple log-structured FS.  /me ducks.
>
> Seriously, though, F2FS might be a fantastic choice for this purpose.

UDF might be doable with multisession acting to ensure atomic
operations, but that seems like a lot of work. If UEFI had gone UDF
instead of FAT, it'd be a different story.

F2FS might be sane. I rather like the idea of Fedora IoT leveraging F2FS.

>> So add that to the list of packages that need an ESP syncing daemon if
>> they don't want to be responsible for dynamically mounting and
>> umounting the ESP.

Fair enough.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3ZYMPEURCBOEVP6NJUYQGYCDKQCF4DXD/

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b6c663378c   
unrtf-0.21.9-8.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7948d6772e   
ansible-2.5.5-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

davix-0.6.8-1.el6
python-regex-2018.06.09-1.el6
xawtv-3.105-1.el6

Details about builds:



 davix-0.6.8-1.el6 (FEDORA-EPEL-2018-837f1ea6cd)
 Toolkit for Http-based file management

Update Information:

* new upstream release

ChangeLog:

* Tue Jun 19 2018 Georgios Bitzes  - 0.6.8-1
- davix 0.68 release see RELEASE-NOTES for changes
* Mon Mar 26 2018 Georgios Bitzes  - 0.6.7-4
- Stop depending on unneeded gtest-devel and boost packages
* Mon Feb 12 2018 Andrea Manzi  - 0.6.7-3
- Rebuild for new gsoap
* Wed Feb  7 2018 Fedora Release Engineering  - 
0.6.7-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild




 python-regex-2018.06.09-1.el6 (FEDORA-EPEL-2018-a1b51068fc)
 Alternative regular expression module, to replace re

Update Information:

Update to the latest released version.    Update to the latest released
version.

ChangeLog:

* Mon Jun 18 2018 Thomas Moschny  - 2018.06.09-1
- Update to 2018.06.09.
* Wed Jun  6 2018 Thomas Moschny  - 2018.06.06-1
- Update to 2018.06.06.




 xawtv-3.105-1.el6 (FEDORA-EPEL-2018-27272118d6)
 TV applications for video4linux compliant devices

Update Information:

Update to 3.105

ChangeLog:

* Tue Jun 19 2018 Dmitry Butskoy  - 3.105-1
- Upgrade to 3.105
- spec file cleanup

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/ZFMW626IEGP5VPEXIG5KKUHPTWRE3GHG/

[Bug 1589471] perl-Email-Address-XS-1.04 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1589471



--- Comment #3 from Fedora Update System  ---
perl-Email-Address-XS-1.04-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/S3TK2S2UCTVJT6WNQNTJ5KB3N4ADCQR6/

[Bug 1592914] perl-Archive-Tar-2.30 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1592914

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Archive-Tar-2.30-1.fc2
   ||9
 Resolution|--- |RAWHIDE
Last Closed||2018-06-19 11:29:46



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/GYLUQQYMPSUM3WHYCUQOTKYOG6NFY4PG/

Re: Heads up: Python 3.7 rebuild in progress

[Miro Hrončok]

On 19.6.2018 11:27, Miro Hrončok wrote:
I'm now mass rebuilding everything. Will do a couple of rounds before I 
will look at the logs. If you see you package failing for a 
non-dependencies related reason, please try to fix it and rebuild it with:


     fedpkg build --target=f29-python

Feel free to open bugs, make sure to block PYTHON37 [1].


In any case, please don't rebuild it in f29 without reason, it's not 
helpful.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/message/3W7GRTJNEQJDQDGIQAXWVCKY5GMXHI5Y/

Re: Heads up: Python 3.7 rebuild in progress

[Miro Hrončok]

On 19.6.2018 11:27, Miro Hrončok wrote:
I'm now mass rebuilding everything. Will do a couple of rounds before I 
will look at the logs. If you see you package failing for a 
non-dependencies related reason, please try to fix it and rebuild it with:


     fedpkg build --target=f29-python

Feel free to open bugs, make sure to block PYTHON37 [1].


In any case, please don't rebuild it in f29 without reason, it's not 
helpful.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3W7GRTJNEQJDQDGIQAXWVCKY5GMXHI5Y/

[Bug 1592914] New: perl-Archive-Tar-2.30 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1592914

Bug ID: 1592914
   Summary: perl-Archive-Tar-2.30 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Archive-Tar
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: al...@redhat.com, caillon+fedoraproj...@gmail.com,
john.j5l...@gmail.com, jples...@redhat.com,
ka...@ucw.cz, mbar...@fastmail.com,
perl-devel@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com, st...@silug.org



Latest upstream release: 2.30
Current version/release in rawhide: 2.28-1.fc29
URL: http://search.cpan.org/dist/Archive-Tar/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/2649/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/GRPPHDDMVSUA6YMBHLJRJ5GYJSSHRHRU/

Re: New FESCo Meeting Time and Ticket Policy

[Randy Barlow]

On 06/18/2018 10:28 PM, Kevin Kofler wrote:
> With the previous policy, any issues for FESCo would be tabled for a meeting 
> and announced on this list before the actual meeting. That gave a chance to 
> the community to comment on the ticket and/or attend the meeting to join the 
> discussion. Thus, the community had a chance to point out any issues with 
> the submitted proposal before FESCo started voting.

I also share your concern, but I think in practice our new policy will
still enable us to discuss the controversial topics in a meeting because
it allows us to add the meeting keyword to controversial issues. Usually
the controversial issues become clear rather quickly. I think it's
reasonable for FESCo members to put the meeting tag on issues that end
up spawning large threads on devel. The policy's intention is to help
FESCo be more efficient with the "quiet" topics. Note also that a week
is required before the issue is approved, even if it does get +3.

I agree that FESco should read and weigh community feedback, and as a
FESCo member I do read the big threads to look for angles I haven't
considered. I think our plan should be able to cover your concern here.

I also believe we would be willing to reconsider this policy if it
doesn't work out in practice. We're really just looking for ways for us
to operate more efficiently here.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CMC53OZ57OGRW2K3DYBETQWD7OZX5ATW/

[F29 only] Dropping requirements for initscripts package from specfiles

[David Kaspar [Dee'Kej]]

Hello people,

I'm working on making Fedora being able to function completely without the
'initscripts' package (hopefully) some day in the future. I have done some
cleanup in initscripts recently, and I would like to ask maintainers of
packages listed below to check if their package(s) still really need the
initscripts package to function properly (for any reason).

It seems that for many packages the requirement of initscripts is just a
leftover from past. If the package does not need the initscripts any
longer, please remove the requirement in Rawhide (F29) and forward. (Do not
backport this change into F28 or F27, it would break things.)

NOTE: In case you are depending on initscripts because of networking
scripts (ifup/ifdown, etc.), then you will need to update your specfile to
depend directly on new package 'network-scripts' (instead of 'initscripts').

I've opened bug reports for each of the packages listed here, and created a
tracking BZ for it:
https://bugzilla.redhat.com/show_bug.cgi?id=1592330

List of packages still depending on initscripts (some of them were already
fixed):
 3proxy
 barry
 boomaga-selinux
 Canna
 clamsmtp
 conmux
 crossfire-selinux
 cyphesis
 device-mapper-multipath
 dpm-xrootd
 ebnetd-common
 exim
 exim-clamav
 foghorn
 freeipa-client
 glpi
 groonga-munin-plugins
 groonga-server-gqtp
 iipsrv
 isdn4k-utils
 kbd
 libstoragemgmt
 mailman-3
 nightview-server
 node
 ntop
 numad
 omniORB
 openslp-server
 os-net-config
 pcp
 pcsc-cyberjack
 pgbouncer
 plymouth
 ppp
 pure-ftpd-selinux
 ratbox-services
 sagator-core
 spacewalk-config
 spamassassin
 spawn-fcgi
 sslogger
 systemtap-initscript
 systemtap-server
 tigervnc-server-minimal
 torque-mom
 torque-scheduler
 torque-server
 trafficserver
 varnish
 vdsm
 vhostmd
 vpnc
 vte
 vte291
 vte3
 wine-desktop
 xboxdrv

Thank you, and best regards! :)

David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*

RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat .
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MRI2HG2WTDJ2BGZTZMZ3JLUMKGEFWM6P/

[Bug 1574102] perl-Crypt-OpenSSL-RSA-0.30 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1574102

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Crypt-OpenSSL-RSA-0.30
   ||-1.fc29
 Resolution|--- |RAWHIDE
   Assignee|wjhns...@hardakers.net  |jples...@redhat.com
Last Closed||2018-06-19 10:54:52



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/EISRMTQHXC7EDCZFXH5V7UJWLEQMAGRC/

[Bug 1567450] perl-Crypt-OpenSSL-Random-0.15 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1567450

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Crypt-OpenSSL-Random-0
   ||.15-1.fc29
 Resolution|--- |RAWHIDE
   Assignee|wjhns...@hardakers.net  |jples...@redhat.com
Last Closed||2018-06-19 10:15:53



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/7723MMARBJVL4T6Y5EV4JTT3AHJV3HIJ/

[Bug 1567450] perl-Crypt-OpenSSL-Random-0.15 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1567450
Bug 1567450 depends on bug 1592426, which changed state.

Bug 1592426 Summary: Review Request: perl-Crypt-OpenSSL-Guess - Guess OpenSSL 
include path
https://bugzilla.redhat.com/show_bug.cgi?id=1592426

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org/message/O7W4YCRRCKIYK57W5VZX4C63VJJ43TMY/

Re: F29 System Wide Change: Build non-RELRO ELF binaries with .plt.got isolation

[Peter Pentchev]

On Mon, Jun 18, 2018 at 09:28:04AM +0200, Jan Kurik wrote:
> = Proposed System Wide Change: Build non-RELRO ELF binaries with
> .plt.got isolation =
> https://fedoraproject.org/wiki/Changes/.plt.got_Isolation
> 
> 
> Owner(s):
>   * Florian Weimer 
> 
> 
> Fedora 23 enabled  hardening for all packages. However, some ELF
> binaries still use lazy binding. This change proposes additional
> hardening for them.

Hi,

First of all, thanks a lot for all your work!  I apologize in advance,
since I'd not even heard of memory protection keys until reading this
today, so my question below is probably quite stupid.

> == Detailed description ==
> With the RELRO and BIND_NOW dynamic linker features, it is possible to
> make the array of function pointers which is used to implement dynamic
> linking (the GOT) read-only at run time. This makes it harder for
> exploit writers to overwrite these function pointers and redirect
> execution.
> However, some ELF binaries are still built and linked without these
> hardening features. Sometimes, this is due to package maintainer
> preferences. Sometimes, there are technical reasons which preclude the
> use of BIND_NOW because the way the application is written, it relies
> on lazy binding.
> This change proposes to link ELF binaries in such a way that the
> .plt.got section is loaded as a separated page at run
> time. As a result, it is possible to use a kernel feature called
> [http://man7.org/linux/man-pages/man7/pkeys.7.html memory protection
> keys] to make the GOT with its function pointer array read-only most
> of the time.

A sentence in this page jumped out at me - the one about the WRPKRU
instruction being completely unprivileged and so memory protection
keys not being very useful if the attacker may execute arbitrary
instructions.  So I thought "well maybe they have in mind something
like allocate a key, make the page read-only, then trash the key and
start executing the program", but then...

> When the dynamic linker needs to perform a function
> symbol binding, it can make the GOT temporarily writable, for the
> current thread only.

...this came along.  So what is supposed to stop an attacker who can
inject arbitrary code into the program from modifying the keys?

Or is this supposed to stop buffer-overflow exploits that overwrite
the GOT and thus cause the attacker's code to be executed later?
If so, then I apologize again, since it seems that this may be
sufficient to prevent that type of attack indeed.

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RXKTYQKBHLQ66QVAHBNWI3CEGZKSQ7ZB/

Re: New FESCo Meeting Time and Ticket Policy

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jun 19, 2018 at 01:18:04PM +0200, Vít Ondruch wrote:
> 
> 
> Dne 19.6.2018 v 12:37 Josh Boyer napsal(a):
> > On Tue, Jun 19, 2018 at 3:48 AM Vít Ondruch  wrote:
> >>
> >>
> >> Dne 19.6.2018 v 04:28 Kevin Kofler napsal(a):
> >>> Stephen Gallagher wrote:
>  * Most FESCo votes will be performed in the tickets. FESCo members will
>  have one week[1] from the creation of the ticket to vote. So long as at
>  least three members have voted, the majority of votes at the end of that
>  week will be counted as the result. If three votes are not received in 
>  the
>  first week, voting will be extended by one additional week and the 
>  minimum
>  required responses reduced to a single vote. If by the end of that second
>  week no votes have been counted, it will be treated as a vote *against*
>  any change requested by the reporter, thus preserving the current status
>  however it stands. We do not expect this clause to ever be invoked.
> >>> Ouch!
> >>>
> >>> With the previous policy, any issues for FESCo would be tabled for a 
> >>> meeting
> >>> and announced on this list before the actual meeting.
> >> I think this ^^ is very valid point. I was used to review the tickets
> >> once they were announced they will be discussed on the meeting.
> > Out of curiosity, why did you wait?
> 
> I don't really want to monitor FESCo activity every day. If there was
> meeting announced, there was announced what is going to be discussed, so
> it was enough to check once per week.

I share your concern, to an extent, and I understand the motivation behind
the change too. Briefly, the motivation stems from the fact that many tickets
*are* completely non-controversial and we don't gain anything by waiting
for a FESCo meeting, and neither do we get anything by discussing in during
the meeting. But I feel that discussion is important, and during free
discussion additional questions or doubts might be raised that would not
appear in the more formal setting of a ticket. Thus, I plan to set the
'meeting' tag on all non-trivial tickets, as in [1].

Let's give it a try, maybe this will result in a slightly more efficient
FESCo (even though I think it was pretty good in this regard already).

[1] https://pagure.io/fesco/issue/1913#comment-517240

Zbyszek

> 
> >   There have been tickets in the
> > past that were already dealt with in this manner and never brought to
> > a meeting.
> 
> Sadly. But hopefully they were not that important.
> 
> >
> >>> That gave a chance to
> >>> the community to comment on the ticket and/or attend the meeting to join 
> >>> the
> >>> discussion. Thus, the community had a chance to point out any issues with
> >>> the submitted proposal before FESCo started voting.
> >>>
> >>> With the new policy, the voting starts immediately with the creation of 
> >>> the
> >>> ticket (of which FESCo members get notified by mail, whereas the community
> >>> at large does not) and has a short deadline of 1 week, encouraging voting
> >>> sooner rather than later. As a result, FESCo members will now almost 
> >>> always
> >>> vote based on only the submitter's biased writeup (the submitter of a
> >>> proposal will rarely point out, or even be aware of, all of its drawbacks)
> >>> before anybody from the community even gets a chance to see the ticket, 
> >>> let
> >>> alone reply.
> > Perhaps we could simply configure the FESCo queue to send email to the
> > devel list.  That would give everyone the same notification and
> > opportunity to comment.
> 
> Notification about new issues could be enough.
> 
> Although still, the FESCo meeting agenda used to be place, where it was
> obvious, that something probably happened with the ticket and it needs
> FESCo (and possibly my) attention. The notification of new issues would
> not replace the convenience FESCO meeting agenda, but better than nothing.
> 
> 
> V.
> 
> >
> > josh
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/V6B4IU6AMV5B4PXOGGIWQDELQRDCQFLI/
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BYMYR2AV2X7M44N44QK6GHFP3YPRAU7U/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 

Re: New FESCo Meeting Time and Ticket Policy

[Jan Kurik]

On Tue, Jun 19, 2018 at 12:37 PM, Josh Boyer  wrote:
> On Tue, Jun 19, 2018 at 3:48 AM Vít Ondruch  wrote:
>>
>>
>>
>> Dne 19.6.2018 v 04:28 Kevin Kofler napsal(a):
>> > Stephen Gallagher wrote:
>> >> * Most FESCo votes will be performed in the tickets. FESCo members will
>> >> have one week[1] from the creation of the ticket to vote. So long as at
>> >> least three members have voted, the majority of votes at the end of that
>> >> week will be counted as the result. If three votes are not received in the
>> >> first week, voting will be extended by one additional week and the minimum
>> >> required responses reduced to a single vote. If by the end of that second
>> >> week no votes have been counted, it will be treated as a vote *against*
>> >> any change requested by the reporter, thus preserving the current status
>> >> however it stands. We do not expect this clause to ever be invoked.
>> > Ouch!
>> >
>> > With the previous policy, any issues for FESCo would be tabled for a 
>> > meeting
>> > and announced on this list before the actual meeting.
>>
>> I think this ^^ is very valid point. I was used to review the tickets
>> once they were announced they will be discussed on the meeting.
>
> Out of curiosity, why did you wait?  There have been tickets in the
> past that were already dealt with in this manner and never brought to
> a meeting.
>
>> > That gave a chance to
>> > the community to comment on the ticket and/or attend the meeting to join 
>> > the
>> > discussion. Thus, the community had a chance to point out any issues with
>> > the submitted proposal before FESCo started voting.
>> >
>> > With the new policy, the voting starts immediately with the creation of the
>> > ticket (of which FESCo members get notified by mail, whereas the community
>> > at large does not) and has a short deadline of 1 week, encouraging voting
>> > sooner rather than later. As a result, FESCo members will now almost always
>> > vote based on only the submitter's biased writeup (the submitter of a
>> > proposal will rarely point out, or even be aware of, all of its drawbacks)
>> > before anybody from the community even gets a chance to see the ticket, let
>> > alone reply.
>
> Perhaps we could simply configure the FESCo queue to send email to the
> devel list.  That would give everyone the same notification and
> opportunity to comment.

Anyone who is interested in receiving notifications from the FESCo
queue can just start to watch the FESCo Pagure repo [1] (the button
with an eye in top right corner). IMO there is no need to increase the
traffic on devel@ mailing list.

[1] https://pagure.io/fesco

Jan
> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/V6B4IU6AMV5B4PXOGGIWQDELQRDCQFLI/



-- 
Jan Kuřík
JBoss EAP 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NJISDCGZVDR7G772KFIMNPNO3N6UC22L/

Re: New FESCo Meeting Time and Ticket Policy

[Vít Ondruch]

Dne 19.6.2018 v 12:37 Josh Boyer napsal(a):
> On Tue, Jun 19, 2018 at 3:48 AM Vít Ondruch  wrote:
>>
>>
>> Dne 19.6.2018 v 04:28 Kevin Kofler napsal(a):
>>> Stephen Gallagher wrote:
 * Most FESCo votes will be performed in the tickets. FESCo members will
 have one week[1] from the creation of the ticket to vote. So long as at
 least three members have voted, the majority of votes at the end of that
 week will be counted as the result. If three votes are not received in the
 first week, voting will be extended by one additional week and the minimum
 required responses reduced to a single vote. If by the end of that second
 week no votes have been counted, it will be treated as a vote *against*
 any change requested by the reporter, thus preserving the current status
 however it stands. We do not expect this clause to ever be invoked.
>>> Ouch!
>>>
>>> With the previous policy, any issues for FESCo would be tabled for a meeting
>>> and announced on this list before the actual meeting.
>> I think this ^^ is very valid point. I was used to review the tickets
>> once they were announced they will be discussed on the meeting.
> Out of curiosity, why did you wait?

I don't really want to monitor FESCo activity every day. If there was
meeting announced, there was announced what is going to be discussed, so
it was enough to check once per week.

>   There have been tickets in the
> past that were already dealt with in this manner and never brought to
> a meeting.

Sadly. But hopefully they were not that important.

>
>>> That gave a chance to
>>> the community to comment on the ticket and/or attend the meeting to join the
>>> discussion. Thus, the community had a chance to point out any issues with
>>> the submitted proposal before FESCo started voting.
>>>
>>> With the new policy, the voting starts immediately with the creation of the
>>> ticket (of which FESCo members get notified by mail, whereas the community
>>> at large does not) and has a short deadline of 1 week, encouraging voting
>>> sooner rather than later. As a result, FESCo members will now almost always
>>> vote based on only the submitter's biased writeup (the submitter of a
>>> proposal will rarely point out, or even be aware of, all of its drawbacks)
>>> before anybody from the community even gets a chance to see the ticket, let
>>> alone reply.
> Perhaps we could simply configure the FESCo queue to send email to the
> devel list.  That would give everyone the same notification and
> opportunity to comment.

Notification about new issues could be enough.

Although still, the FESCo meeting agenda used to be place, where it was
obvious, that something probably happened with the ticket and it needs
FESCo (and possibly my) attention. The notification of new issues would
not replace the convenience FESCO meeting agenda, but better than nothing.


V.

>
> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/V6B4IU6AMV5B4PXOGGIWQDELQRDCQFLI/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BYMYR2AV2X7M44N44QK6GHFP3YPRAU7U/

[Bug 1588760] CVE-2018-12015 perl: Directory traversal in Archive::Tar

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1588760

Cedric Buissart  changed:

   What|Removed |Added

 Whiteboard|impact=moderate,public=2018 |impact=moderate,public=2018
   |0607,reported=20180607,sour |0607,reported=20180607,sour
   |ce=cve,cvss3=3.3/CVSS:3.0/A |ce=cve,cvss3=5.4/CVSS:3.0/A
   |V:L/AC:L/PR:N/UI:R/S:U/C:N/ |V:N/AC:L/PR:N/UI:R/S:U/C:N/
   |I:L/A:N,cwe=CWE-22,fedora-a |I:L/A:L,cwe=CWE-22,fedora-a
   |ll/perl-Archive-Tar=affecte |ll/perl-Archive-Tar=affecte
   |d,rhel-5/perl-Archive-Tar=w |d,rhel-5/perl-Archive-Tar=w
   |ontfix,rhel-6/perl=wontfix, |ontfix,rhel-6/perl=wontfix,
   |rhel-7/perl-Archive-Tar=aff |rhel-7/perl-Archive-Tar=aff
   |ected,rhel-8/perl-Archive-T |ected,rhel-8/perl-Archive-T
   |ar=notaffected,rhscl-3/rh-p |ar=notaffected,rhscl-3/rh-p
   |erl526-perl-Archive-Tar=aff |erl526-perl-Archive-Tar=aff
   |ected,rhscl-3/rh-perl524-pe |ected,rhscl-3/rh-perl524-pe
   |rl-Archive-Tar=affected,rhs |rl-Archive-Tar=affected,rhs
   |cl-3/rh-perl520-perl-Archiv |cl-3/rh-perl520-perl-Archiv
   |e-Tar=wontfix   |e-Tar=wontfix


--- Doc Text *updated* ---
It was found that the Archive::Tar module did not properly sanitize symbolic 
links when extracting tar archives. An attacker able to provide a specially 
crafted archive for processing could use this flaw to write or overwrite 
arbitrary files in the context of the perl interpreter.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/57J7AAMQRW2GZBL6VBK5GNKMCGELMX4X/

[Bug 1588760] CVE-2018-12015 perl: Directory traversal in Archive::Tar

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1588760

Cedric Buissart  changed:

   What|Removed |Added

 Whiteboard|impact=moderate,public=2018 |impact=moderate,public=2018
   |0607,reported=20180607,sour |0607,reported=20180607,sour
   |ce=cve,cvss3=3.3/CVSS:3.0/A |ce=cve,cvss3=3.3/CVSS:3.0/A
   |V:L/AC:L/PR:N/UI:R/S:U/C:N/ |V:L/AC:L/PR:N/UI:R/S:U/C:N/
   |I:L/A:N,cwe=CWE-22,fedora-a |I:L/A:N,cwe=CWE-22,fedora-a
   |ll/perl-Archive-Tar=affecte |ll/perl-Archive-Tar=affecte
   |d,rhel-5/perl-Archive-Tar=w |d,rhel-5/perl-Archive-Tar=w
   |ontfix,rhel-6/perl=wontfix, |ontfix,rhel-6/perl=wontfix,
   |rhel-7/perl-Archive-Tar=aff |rhel-7/perl-Archive-Tar=aff
   |ected,rhel-8/perl-Archive-T |ected,rhel-8/perl-Archive-T
   |ar=notaffected,rhscl-3/rh-p |ar=notaffected,rhscl-3/rh-p
   |erl526-perl-Archive-Tar=aff |erl526-perl-Archive-Tar=aff
   |ected,rhscl-3/rh-perl524-pe |ected,rhscl-3/rh-perl524-pe
   |rl-Archive-Tar=affected,rhs |rl-Archive-Tar=affected,rhs
   |cl-3/rh-perl520-perl-Archiv |cl-3/rh-perl520-perl-Archiv
   |e-Tar=affected  |e-Tar=wontfix



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/RNBOSOVIIMK4HIZ2NFUETQYG2O2ZRUW3/

[Bug 1588760] CVE-2018-12015 perl: Directory traversal in Archive::Tar

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1588760

Cedric Buissart  changed:

   What|Removed |Added

 Depends On||1592804, 1592806, 1592803,
   ||1592805



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/GWMMIZHL7AW7YMDVMEIEIERWMJIJXDAN/

Re: F29 System Wide Change: Make BootLoaderSpec the default

[Lennart Poettering]

On Di, 19.06.18 11:14, Daniel P. Berrangé (berra...@redhat.com) wrote:

> On Tue, Jun 19, 2018 at 11:48:39AM +0200, Lennart Poettering wrote:
> > On Mo, 18.06.18 16:54, R P Herrold (herr...@owlriver.com) wrote:
> > 
> > > On Mon, 18 Jun 2018, Lennart Poettering wrote:
> > > 
> > > > On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote:
> > > > 
> > > > > The cited BLS spec is the original one, [1]
> > > 
> > > ... later: L.P.:
> > > > [reduce] the size of the spec if possible, and drop as many 
> > > > bits of it as we can, i.e. the stuff noone implements 
> > > > anyway.
> > > > 
> > > > > The cited BLS spec requires $BOOT be VFAT, are we doing that?
> > > 
> > > Will cgroup and SElinux protections work in VFAT ?
> > 
> > cgroups and file systems have little to do with each other.
> > 
> > VFAT won't store selinux labels of course, but you can assign a fixed
> > label to all files of a vfat file system when mounting it. It's what
> > Fedora does when dealing with the ESP already. So regarding selinux
> > it's not whether to do selinux or not to do it, but whether is really
> > necessary to label the initrd file and the kernel differently, or
> > whether it's ok to give all files in /boot the same label. I am pretty
> > sure that's actually what already happens anyway, even if you have
> > ext4, but then again i am not running grub nor ext4, so I don't really know.
> 
> Mostly everything is labelled with boot_t, but System.map files get
> given system_map_t, and there's a few filesystem house keeping labels
> too. You can view it with semanage:
> 
> # semanage fcontext -l | grep '^/boot'
> /boot  all files  
> system_u:object_r:boot_t:s0 
> /boot/.*   all files  
> system_u:object_r:boot_t:s0 
> /boot/System\.map(-.*)?regular file   
> system_u:object_r:system_map_t:s0 
> /boot/\.journalall files  <>
> /boot/a?quota\.(user|group)regular file   
> system_u:object_r:quota_db_t:s0 
> /boot/efi(/.*)?/System\.map(-.*)?  regular file   
> system_u:object_r:system_map_t:s0 
> /boot/lost\+found  directory  
> system_u:object_r:lost_found_t:s0 
> /boot/lost\+found/.*   all files  <>

Since the quota and lost+found stuff doesn't apply to vfat there are
only two labels left: boot_t and system_map_t. The question is whether
there's really benefit in separating these two... 

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UAD6KQPIMEEQJKE2CTKGIWBOZMCYX75U/

Re: New FESCo Meeting Time and Ticket Policy

[Josh Boyer]

On Tue, Jun 19, 2018 at 3:48 AM Vít Ondruch  wrote:
>
>
>
> Dne 19.6.2018 v 04:28 Kevin Kofler napsal(a):
> > Stephen Gallagher wrote:
> >> * Most FESCo votes will be performed in the tickets. FESCo members will
> >> have one week[1] from the creation of the ticket to vote. So long as at
> >> least three members have voted, the majority of votes at the end of that
> >> week will be counted as the result. If three votes are not received in the
> >> first week, voting will be extended by one additional week and the minimum
> >> required responses reduced to a single vote. If by the end of that second
> >> week no votes have been counted, it will be treated as a vote *against*
> >> any change requested by the reporter, thus preserving the current status
> >> however it stands. We do not expect this clause to ever be invoked.
> > Ouch!
> >
> > With the previous policy, any issues for FESCo would be tabled for a meeting
> > and announced on this list before the actual meeting.
>
> I think this ^^ is very valid point. I was used to review the tickets
> once they were announced they will be discussed on the meeting.

Out of curiosity, why did you wait?  There have been tickets in the
past that were already dealt with in this manner and never brought to
a meeting.

> > That gave a chance to
> > the community to comment on the ticket and/or attend the meeting to join the
> > discussion. Thus, the community had a chance to point out any issues with
> > the submitted proposal before FESCo started voting.
> >
> > With the new policy, the voting starts immediately with the creation of the
> > ticket (of which FESCo members get notified by mail, whereas the community
> > at large does not) and has a short deadline of 1 week, encouraging voting
> > sooner rather than later. As a result, FESCo members will now almost always
> > vote based on only the submitter's biased writeup (the submitter of a
> > proposal will rarely point out, or even be aware of, all of its drawbacks)
> > before anybody from the community even gets a chance to see the ticket, let
> > alone reply.

Perhaps we could simply configure the FESCo queue to send email to the
devel list.  That would give everyone the same notification and
opportunity to comment.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/V6B4IU6AMV5B4PXOGGIWQDELQRDCQFLI/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

[Kevin Kofler]

Gerd Hoffmann wrote:
> If someone wants keep 32bit fedora alive for pre-sse2 hardware I think
> the only reasonable thing would be to undust the i586 target, then go
> build software which requires sse2 as --target i686 and everything else
> as --target i586, i.e. basically stop the effort to patch software for
> non-sse2 hardware.  pre-sse2 hardware would have the i586 packages
> available only.

Most upstreams that hardcode SSE2 also do not distinguish between various 
i*86. They just check for x86 and use SSE2 instructions there, or even just 
use SSE2 instructions unconditionally (making them entirely x86/x86_64-
only). So --target i586 isn't going to do anything for them. Rust seems to 
be the one case where it would help.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GYH5MNU5IIRRXWS2M6PH7HGKFDLQIP54/

Re: F29 System Wide Change: Make BootLoaderSpec the default

[Daniel P . Berrangé]

On Tue, Jun 19, 2018 at 11:48:39AM +0200, Lennart Poettering wrote:
> On Mo, 18.06.18 16:54, R P Herrold (herr...@owlriver.com) wrote:
> 
> > On Mon, 18 Jun 2018, Lennart Poettering wrote:
> > 
> > > On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote:
> > > 
> > > > The cited BLS spec is the original one, [1]
> > 
> > ... later: L.P.:
> > > [reduce] the size of the spec if possible, and drop as many 
> > > bits of it as we can, i.e. the stuff noone implements 
> > > anyway.
> > > 
> > > > The cited BLS spec requires $BOOT be VFAT, are we doing that?
> > 
> > Will cgroup and SElinux protections work in VFAT ?
> 
> cgroups and file systems have little to do with each other.
> 
> VFAT won't store selinux labels of course, but you can assign a fixed
> label to all files of a vfat file system when mounting it. It's what
> Fedora does when dealing with the ESP already. So regarding selinux
> it's not whether to do selinux or not to do it, but whether is really
> necessary to label the initrd file and the kernel differently, or
> whether it's ok to give all files in /boot the same label. I am pretty
> sure that's actually what already happens anyway, even if you have
> ext4, but then again i am not running grub nor ext4, so I don't really know.

Mostly everything is labelled with boot_t, but System.map files get
given system_map_t, and there's a few filesystem house keeping labels
too. You can view it with semanage:

# semanage fcontext -l | grep '^/boot'
/boot  all files  
system_u:object_r:boot_t:s0 
/boot/.*   all files  
system_u:object_r:boot_t:s0 
/boot/System\.map(-.*)?regular file   
system_u:object_r:system_map_t:s0 
/boot/\.journalall files  <>
/boot/a?quota\.(user|group)regular file   
system_u:object_r:quota_db_t:s0 
/boot/efi(/.*)?/System\.map(-.*)?  regular file   
system_u:object_r:system_map_t:s0 
/boot/lost\+found  directory  
system_u:object_r:lost_found_t:s0 
/boot/lost\+found/.*   all files  <>


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6B7P3Y7YCCKDODAHXWCJTVQX2SRQFO3Q/

[Bug 1592742] perl-CPAN-Perl-Releases-3.62 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1592742



--- Comment #2 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.62-1.fc27 has been submitted as an update to Fedora
27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-97d336e0e9

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/FILHC3BVC4MI5CKLW67LMZ22Y426Q5RG/

[Bug 1592742] perl-CPAN-Perl-Releases-3.62 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1592742



--- Comment #1 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.62-1.fc28 has been submitted as an update to Fedora
28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-eec51163ca

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/NI3TA7SEVLXPYQVNHYD2GZKUSAF6PI7U/

Re: F29 System Wide Change: Make BootLoaderSpec the default

[Lennart Poettering]

On Mo, 18.06.18 16:54, R P Herrold (herr...@owlriver.com) wrote:

> On Mon, 18 Jun 2018, Lennart Poettering wrote:
> 
> > On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote:
> > 
> > > The cited BLS spec is the original one, [1]
> 
> ... later: L.P.:
> > [reduce] the size of the spec if possible, and drop as many 
> > bits of it as we can, i.e. the stuff noone implements 
> > anyway.
> > 
> > > The cited BLS spec requires $BOOT be VFAT, are we doing that?
> 
> Will cgroup and SElinux protections work in VFAT ?

cgroups and file systems have little to do with each other.

VFAT won't store selinux labels of course, but you can assign a fixed
label to all files of a vfat file system when mounting it. It's what
Fedora does when dealing with the ESP already. So regarding selinux
it's not whether to do selinux or not to do it, but whether is really
necessary to label the initrd file and the kernel differently, or
whether it's ok to give all files in /boot the same label. I am pretty
sure that's actually what already happens anyway, even if you have
ext4, but then again i am not running grub nor ext4, so I don't really know.

> > Why would we? I mean the idea is that $BOOT can be shared among
> > multiple OSes installed. Which means one really should settle on a
> 
> I see a lot of need in [1] for re-partitioning and optionally 
> adding a /boot partition where none was specified, to make 
> this work
> 
> The move toward containers includes getting away from more 
> than a single partition (and so, a separate /boot partition, 
> as mostly irrelavant).  Getting rid of a separate /boot 
> partition is a win, as it  removes the need for a separate 
> mountpoint in /etc/fstab for a '/boot/'. partition, and all 
> the gyrations as to partitioning in [1]

Well, my personal opinion is that the ESP is where kernels should be
placed if at all possible, in order to simplify things. You need the
ESP anyway, there's no way around it, hence if you can just unify the
pre-root stuff there, and then only have the ESP and your root dir as
necessary partitions.

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/H7GJBIFU56PESKBRNDDXZO5WHFV3JOK3/

Re: F29 System Wide Change: Make BootLoaderSpec the default

[Lennart Poettering]

On Mo, 18.06.18 16:50, Ondřej Lysoněk (olyso...@redhat.com) wrote:

> Hi,
> 
> On 18.6.2018 15:27, Lennart Poettering wrote:
> > On Do, 14.06.18 14:20, Chris Murphy (li...@colorremedies.com) wrote:
> > 
> >> The cited BLS spec is the original one, not the more thoroughly
> >> discussed and thought through variant by Matthew Garrett [1] some
> >> years ago.
> > 
> > Quite frankly, as one of the authors of the original BLS spec, I can'd
> > say Matthew's version was much discussed with me...
> > 
> > I mean, I am open to extending the spec, but we should do this bit by
> > bit.
> > 
> > Zbigniew suggested to move the spec into docbook or markdown format,
> > and then accept changes via usual github PRs. If there's interest
> > still in extending the spec with some of Matthew's ideas we can
> > certainly look into that, but in general I'd actually prefer to reduce
> > the size of the spec if possible, and drop as many bits of it as we
> > can, i.e. the stuff noone implements anyway.
> 
> It would be great if we could extend the spec with optional support for
> multiple initrd images (the Tuned daemon depends on that). Fedora's
> GRUB2 already supports multiple initrd images (it allows specifying
> multiple lines with the "initrd" key), but I'd like to make sure that
> whoever implements BLS in the future and decides to support multiple
> initrds will not choose a different syntax for it. Would you be open to
> extending the spec with that?

Sure, allowing multiple initrd keys in the snippets makes a ton of sense.

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KKC7KFBNLSZQLA3756ECZEFJPIC2UO6W/

Re: F29 System Wide Change: Make BootLoaderSpec the default

[Lennart Poettering]

On Mo, 18.06.18 10:30, Chris Murphy (li...@colorremedies.com) wrote:

> >> The cited BLS spec requires $BOOT be VFAT, are we doing that?
> >
> > Why would we? I mean the idea is that $BOOT can be shared among
> > multiple OSes installed. Which means one really should settle on a
> > format anyone can read. And VFAT certainly qualifies as that, most
> > other file systems do not.
> 
> Do you mean "why wouldn't we?" Flipping over everyone's /boot to
> become the ESP on VFAT is a substantial change so I'm asking the
> question, yet again. This was asked a long time ago with the original
> conversations on this list about BootLoaderSpec, and those questions
> and answers are addressed in Matthew Garrett's derivative of the
> spec.

The boot loader spec suggests that $BOOT and the ESP are the same
thing, and I am very sure this is the best and simplest approach for
all images that have no explicit reason to depart from that. However,
the spec does not actually require $BOOT to be the same as the
ESP. The freedom to make $BOOT != ESP was added as a compromise,
because some folks were adamant that resizing the ESP on multi-boot
systems should not be done (i personally don't think it's as big a
prob as people claim though...).

Today, systemd has this generator that will automatically find the ESP
for you and mount it to /efi or /boot. The idea behind that is that
installers can choose whether they want to merge $BOOT and the ESP or
not:

1. If they are merged, then the ESP (and thus also $BOOT) is mounted
   to /boot, automatically by the generator. No other preparation is
   needed, and /efi does not exist. (Distros could even make /efi a
   symlink → /boot, but I personally wouldn't bother).

2. If they are not merged, then the ESP is mounted to /efi,
   automatically by the generator. And /boot would be mounted as $BOOT
   via an /etc/fstab entry added by the installer.

And as mentioned, I'd generally recommend everybody to go for option
#1 because it is a lot simpler, and EFI has trivial access to all
kernels and such. The boot loader can start the EFI shell and its
trivial to explore the contents and everything and manually boot any
kernel you like. This approach also means that no /etc/fstab entry is
needed, and thus things are a lot more self-sufficient and robust.

It would be my assumption that all OS images generated in full by some
image builder would go for option #1, and option #2 would only be used
when a traditional installer such as anaconda is used that is supposed
to add a Fedora installation to a system that is already set up
otherwise, i.e. already has an EFI partition in place that is
considered too small. i.e. option #2 is the multi-boot-with-windows
usecase, while option #1 is for pretty much everything else.

> > 1) The chance that the ESP remains in a clean state is maximized, as
> >the file system is unmounted whenever possible, and only mounted
> >for a short time window around actual disk accesses. This is the
> >behaviour you really want for something as fragile as the ESP.
> >
> > 2) It's compatible with current behaviour, as the path is always
> >accessible under a fixed name, requiring no explicit mounting.
> >
> > 3) There's no need to configure any lines for the ESP in /etc/fstab
> >anymore. Instead the system will discover the ESP automatically and
> >make it available. This means the installer can be simpler, and
> >things are generally more robust as /efi (or /boot) will follow
> >what is in place, instead of require a separate layer of
> >configuration that has a good chance of getting out of sync.
> 
> I've got no complaints with this although as mentioned in the other
> thread "f29 bootloader changes / raid1 installs + efi" this generator
> lacks the intelligence needed to support multiple ESPs for any RAID
> use case, e.g. md or LVM or Btrfs RAID1.

Well, if you really want to cover this, then using the automount stuff
actually allows you to solve this much nicer than traditional setups:
write a service (possibly just a script around dd with some locking
might suffice) that is pulled in by the .mount unit that the
.automount unit is backed by, and is ordered before the .mount
unit. This then means its ExecStart= and ExecStop= line would run
before and after the mount is around. In ExecStop= you could then dd
the mounted file system onto the other copies. And we'd do though
automatically after each series of accesses.

> > I'd love to see Fedora adopt this generator. Primarily this would mean
> > some chnages to anaconda I guess. It would make things simpler and
> > more robust. That said, the generator only cares about the ESP, not
> > for cases where $BOOT is backed by any other partition.
> 
> Ok so you're saying if $BOOT is type 0xEA, or type
> bc13c2ff-59e6-4262-a352-b275fd6f7172, the generator will not automount
> it at /boot ?

systemd will do the discovery and automount unit generation only for
the ESP, and it's very defensive, 

Re: Heads up: Python 3.7 rebuild in progress

[Miro Hrončok]

On 13.6.2018 15:14, Miro Hrončok wrote:
I've just started to build the bootstrap sequence in a side tag 
(f29-python).


This should not affect you mostly but if you have a Python 3 package and 
you are going to update it with new buildtime dependencies, please let 
me know or wait until this is done.


The initial order is in 
https://github.com/hroncok/rpm-list-builder/blob/python37/python37.yaml


The initial order was built (except for failing python-alembic [0] and 
dependent bodhi, fedpkg).


I'm now mass rebuilding everything. Will do a couple of rounds before I 
will look at the logs. If you see you package failing for a 
non-dependencies related reason, please try to fix it and rebuild it with:


fedpkg build --target=f29-python

Feel free to open bugs, make sure to block PYTHON37 [1].

If you see a dependency problem, just wait (unless you know the 
dependency is circular and a bootstrapping is required, in that case, 
please do the bootstrapping).


Thanks


[0] https://bugzilla.redhat.com/show_bug.cgi?id=1592127
[1] http://bugzilla.redhat.com/show_bug.cgi?id=PYTHON37

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3Q3KGSI3K45KKP2GNXTHQSWJOTUWH4PQ/

[Bug 1592742] perl-CPAN-Perl-Releases-3.62 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1592742

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-CPAN-Perl-Releases-3.6
   ||2-1.fc29



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/CRUELSYMWLDPU5JD7SHIHZNIVZP2GVKA/

[Bug 1592606] perl-Net-Netmask-1.9103 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1592606

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Net-Netmask-1.9103-1.f
   ||c29
 Resolution|--- |RAWHIDE
Last Closed||2018-06-19 04:55:25



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/YDFPTKDPYPUZ3QPLIZ3KM3H4UWZ6Z3EF/

[Bug 1592742] New: perl-CPAN-Perl-Releases-3.62 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1592742

Bug ID: 1592742
   Summary: perl-CPAN-Perl-Releases-3.62 is available
   Product: Fedora
   Version: rawhide
 Component: perl-CPAN-Perl-Releases
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 3.62
Current version/release in rawhide: 3.60-1.fc29
URL: http://search.cpan.org/dist/CPAN-Perl-Releases/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/5881/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/SYBTN4BFIWDK2BXBP2DNG5QFMLLBEZEE/

REMINDER: Fedora 29 Change Checkpoint: Proposal submission deadline (System Wide Changes) in two weeks

[Jan Kurik]

Hi everyone!

The submission deadline for System Wide Change Proposals of Fedora 29
[1] is coming pretty soon - in two weeks on July 3rd.

Please, submit your System Wide Changes by this deadline, earlier
better. As the deadline applies for System Wide Changes it is always
good to have most of Self Contained Changes proposed as well. The
deadline for Self Contained Change Proposals is planned on July 24th.

In case you'll need any help with your Change proposals, feel free to
contact me.

[1] https://fedoraproject.org/wiki/Releases/29/Schedule

Best Regards,
Jan
-- 
Jan Kuřík
JBoss EAP 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/W5K2POXCPSJMFKCQXE27CQRDB6MZ7QZ6/

Today we have reached the Submission deadline for Change proposals of Fedora 29 requiring mass rebuild

[Jan Kurik]

Hi everyone!

The submission deadline for Changes of Fedora 29 [1], requiring mass
rebuild, takes effect today (on June 19th). All the Changes requiring
mass rebuild sent for review are going to be moved to Fedora 30
release.
The mass rebuild it self is planned on July 11th.

In case you'll need any help with your Change proposals, feel free to
contact me.

[1] https://fedoraproject.org/wiki/Releases/29/Schedule

Best Regards,
Jan
-- 
Jan Kuřík
JBoss EAP 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LXU7WQNZYHKHHT4AZEU7FUDQ24Z3CLV2/

Today we have reached the Submission deadline for Change proposals of Fedora 29 requiring mass rebuild

[Jan Kurik]

Hi everyone!

The submission deadline for Changes of Fedora 29 [1], requiring mass
rebuild, takes effect today (on June 19th). All the Changes requiring
mass rebuild sent for review are going to be moved to Fedora 30
release.
The mass rebuild it self is planned on July 11th.

In case you'll need any help with your Change proposals, feel free to
contact me.

[1] https://fedoraproject.org/wiki/Releases/29/Schedule

Best Regards,
Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/LXU7WQNZYHKHHT4AZEU7FUDQ24Z3CLV2/

[Bug 1592602] perl-File-ShareDir-1.112 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1592602

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-File-ShareDir-1.112-1.
   ||fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-06-19 04:15:09



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/JTJFYUW5UTFI7NIEXT3SDN5LDOXM7CDJ/

F29 System Wide Change: Rename Atomic Workstation to Silverblue

[Jan Kurik]

= Proposed System Wide Change: Rename Atomic Workstation to Silverblue =
https://fedoraproject.org/wiki/Changes/Silverblue


Owner(s):
  * Matthias Clasen 


The Atomic Workstation variant is being renamed to Fedora Silverblue.


== Detailed description ==
The Atomic Workstation is being rebranded as Fedora Silverblue, to
give this project more visibility and realize its full potential for
bringing new users to Fedora. There is new website,
www.teamsilverblue.org, which is gathering information and resources
around this effort.


== Scope ==
Concrete suggested changes:
** Change ostree repo branch name to fedora/29/x86_64/silverblue
** Change /etc/os-release to say Silverblue in the appropriate places
** Provide branding in fedora-logos package that says Silverblue
** Change install media name to Fedora-Silverblue-ostree-...

* Proposal owners:
** Provide patches for /etc/os-release and fedora-logos

* Other developers:
** Change lorax templates to refer to new branch name
** Change anaconda install media:
https://github.com/rhinstaller/anaconda/issues/1504
** Create a Silverblue install class in anaconda:
https://github.com/rhinstaller/anaconda/issues/1505
** Make necessary changes in pungi: https://pagure.io/pungi/issue/982

* Release engineering:
#7579 [https://pagure.io/releng/issue/7579]

** List of deliverables:
*** The Fedora Atomic Workstation iso will be renamed to
Fedora-Silverblue-x86_64...
*** The getfedora.org webpage will need corresponding adjustments

* Policies and guidelines:
No changes

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/G45DZJ52GKJU727PKAVRSIXIZR35YCSV/

F29 Self Contained Change: glibc 32 Build Adjustments

[Jan Kurik]

= Proposed Self Contained Change: glibc 32 Build Adjustments =
https://fedoraproject.org/wiki/Changes/glibc32_Build_Adjustments


Owner(s):
  * Florian Weimer 


The glibc32 package is a special package used by gcc and a few other
packages to work around the lack of RPM multilib repository support in
Koji [https://pagure.io/koji/issue/273]. It is difficult to maintain,
and the current approach raises questions regarding (L)GPL compliance.


== Detailed description ==
Some packages build non-64-bit code on 64-bit architectures, using GCC
switches such as "-m32" and "-m31".  Those that do not use "-nostdlib"
at the same time need a non-64-bit glibc as well. However, Koji cannot
currently provide such multilib RPMs; all RPM packages are either of
the build architecture or noarch packages.
In particular, GCC has a dependency on the non-64-bit (32-bit or
31-bit) glibc library.
The current hack to support GCC's need (and a few other packages) is
that a separate package, glibc32, contains pre-built 32-bit/31-bit
binaries extracted from RPMs built in Fedora some time in the past.
Since these binaries are pre-built, they can be built (actually copied
around) on any architecture, including the relevant 64-bit
architectures.
This primarily affects the x86_64 architecture and its i686 multilib
RPMs.  Historically, the same problem occurred on ppc64 (with ppc as
the multilib architecture) and s390x (with s390). However, Fedora no
longer builds non-64-bit RPM packages on these architectures.  This
also means that the ppc and s390 binaries in the glibc32 package can
no longer be recreated within Fedora, which is not sustainable.  At
the very least, these two sets of binaries would have to be removed,
effectively making the glibc32 package specific to the x86_64
architecture.
It appears that on ppc64 we still need to build GCC in such a way that
the "-m32" option is supported.  This means that some cross-package
coordination is necessary.  (A first check showed that the s390x boot
loader support is built as 64-bit binary, so "-m31" support in glibc
does not seem to be necessary for bootloader purposes.)
There are two ways to address these problems:
* Continue the current copy-based approach.  It is simplified somewhat
due to the switch to libxcrypt.  Modify the (fully manual) extraction
procedure so that the source RPM of the binary files is included as
well, to provide airtight LGPL compliance.
* Build glibc32 and libgcc32 subpackages from the glibc and gcc
packages, which are then filtered by pungi from all composes
[https://pagure.io/releng/issue/7576].  (Currently, the buildroot-only
nature of glibc32 is achieved by tagging builds appropriately in Koji,
which is rather fragile.)  The big advantage of this approach is that
the glibc32 package will always be in sync with the actual 64-bit
library.


== Scope ==
* Proposal owners:
** Drop ppc and s390 RPM contents from glibc32.  Adapt the build
procedure as agreed.

* Other developers:
** Fedora GCC developers will need to drop the build dependency on
`/usr/lib/libc.so` on ppc64 and s390x.  It may be necessary to
configure GCC with "--enable-targets=all", to support "-m32" for
building boot loaders and other freestanding code.
** The compat-gcc-* and ghdl packages may need similar adjustments.
** Other packages with a "/usr/lib/libc.so.6" build dependency
(chromium, systemtap, valgrind) appear to restricted to x86_64
already.
** If the filtered subpackage approach is chosen for Fedora 29, the
gcc package will need to be updated to build a new subpackage,
libgcc32, that contains the multilib libraries.  These will be
required for building glibc32 as a subpackage.

* Release engineering:
#7578 [https://pagure.io/releng/issue/7578]

** 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
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/SBGG4BZDJ4N2J33U5QCFNDS2NN4K2HQB/

F29 System Wide Change: Rename Atomic Workstation to Silverblue

[Jan Kurik]

= Proposed System Wide Change: Rename Atomic Workstation to Silverblue =
https://fedoraproject.org/wiki/Changes/Silverblue


Owner(s):
  * Matthias Clasen 


The Atomic Workstation variant is being renamed to Fedora Silverblue.


== Detailed description ==
The Atomic Workstation is being rebranded as Fedora Silverblue, to
give this project more visibility and realize its full potential for
bringing new users to Fedora. There is new website,
www.teamsilverblue.org, which is gathering information and resources
around this effort.


== Scope ==
Concrete suggested changes:
** Change ostree repo branch name to fedora/29/x86_64/silverblue
** Change /etc/os-release to say Silverblue in the appropriate places
** Provide branding in fedora-logos package that says Silverblue
** Change install media name to Fedora-Silverblue-ostree-...

* Proposal owners:
** Provide patches for /etc/os-release and fedora-logos

* Other developers:
** Change lorax templates to refer to new branch name
** Change anaconda install media:
https://github.com/rhinstaller/anaconda/issues/1504
** Create a Silverblue install class in anaconda:
https://github.com/rhinstaller/anaconda/issues/1505
** Make necessary changes in pungi: https://pagure.io/pungi/issue/982

* Release engineering:
#7579 [https://pagure.io/releng/issue/7579]

** List of deliverables:
*** The Fedora Atomic Workstation iso will be renamed to
Fedora-Silverblue-x86_64...
*** The getfedora.org webpage will need corresponding adjustments

* Policies and guidelines:
No changes

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G45DZJ52GKJU727PKAVRSIXIZR35YCSV/

F29 Self Contained Change: glibc 32 Build Adjustments

[Jan Kurik]

= Proposed Self Contained Change: glibc 32 Build Adjustments =
https://fedoraproject.org/wiki/Changes/glibc32_Build_Adjustments


Owner(s):
  * Florian Weimer 


The glibc32 package is a special package used by gcc and a few other
packages to work around the lack of RPM multilib repository support in
Koji [https://pagure.io/koji/issue/273]. It is difficult to maintain,
and the current approach raises questions regarding (L)GPL compliance.


== Detailed description ==
Some packages build non-64-bit code on 64-bit architectures, using GCC
switches such as "-m32" and "-m31".  Those that do not use "-nostdlib"
at the same time need a non-64-bit glibc as well. However, Koji cannot
currently provide such multilib RPMs; all RPM packages are either of
the build architecture or noarch packages.
In particular, GCC has a dependency on the non-64-bit (32-bit or
31-bit) glibc library.
The current hack to support GCC's need (and a few other packages) is
that a separate package, glibc32, contains pre-built 32-bit/31-bit
binaries extracted from RPMs built in Fedora some time in the past.
Since these binaries are pre-built, they can be built (actually copied
around) on any architecture, including the relevant 64-bit
architectures.
This primarily affects the x86_64 architecture and its i686 multilib
RPMs.  Historically, the same problem occurred on ppc64 (with ppc as
the multilib architecture) and s390x (with s390). However, Fedora no
longer builds non-64-bit RPM packages on these architectures.  This
also means that the ppc and s390 binaries in the glibc32 package can
no longer be recreated within Fedora, which is not sustainable.  At
the very least, these two sets of binaries would have to be removed,
effectively making the glibc32 package specific to the x86_64
architecture.
It appears that on ppc64 we still need to build GCC in such a way that
the "-m32" option is supported.  This means that some cross-package
coordination is necessary.  (A first check showed that the s390x boot
loader support is built as 64-bit binary, so "-m31" support in glibc
does not seem to be necessary for bootloader purposes.)
There are two ways to address these problems:
* Continue the current copy-based approach.  It is simplified somewhat
due to the switch to libxcrypt.  Modify the (fully manual) extraction
procedure so that the source RPM of the binary files is included as
well, to provide airtight LGPL compliance.
* Build glibc32 and libgcc32 subpackages from the glibc and gcc
packages, which are then filtered by pungi from all composes
[https://pagure.io/releng/issue/7576].  (Currently, the buildroot-only
nature of glibc32 is achieved by tagging builds appropriately in Koji,
which is rather fragile.)  The big advantage of this approach is that
the glibc32 package will always be in sync with the actual 64-bit
library.


== Scope ==
* Proposal owners:
** Drop ppc and s390 RPM contents from glibc32.  Adapt the build
procedure as agreed.

* Other developers:
** Fedora GCC developers will need to drop the build dependency on
`/usr/lib/libc.so` on ppc64 and s390x.  It may be necessary to
configure GCC with "--enable-targets=all", to support "-m32" for
building boot loaders and other freestanding code.
** The compat-gcc-* and ghdl packages may need similar adjustments.
** Other packages with a "/usr/lib/libc.so.6" build dependency
(chromium, systemtap, valgrind) appear to restricted to x86_64
already.
** If the filtered subpackage approach is chosen for Fedora 29, the
gcc package will need to be updated to build a new subpackage,
libgcc32, that contains the multilib libraries.  These will be
required for building glibc32 as a subpackage.

* Release engineering:
#7578 [https://pagure.io/releng/issue/7578]

** 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
JBoss EAP 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SBGG4BZDJ4N2J33U5QCFNDS2NN4K2HQB/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

[Gerd Hoffmann]

  Hi,

> > effort, and nobody outside of Fedora cares about non-SSE2 anymore. Even 
> > distros that claim to support non-SSE2 hardware just ship QtWebEngine as 
> > SSE2 only. I haven't seen any other distro even picking up my patch, let 
> > alone working on it. The Fedora Chromium, V8 and Node.js packagers also do 
> > not care.
> 
> I suspect Firefox may also be sse2-only, at least indirectly from Rust.
> I just checked the rustc target spec for i686-unknown-linux-gnu, and by
> default it's targeting "pentium4".  There is an i585-unknown-linux-gnu
> which targets only "pentium" though.
> 
> But Firefox has been building with Rust on all arches for over a year
> now, and apparently, nobody has noticed this in practice...

Probably modern web browsers simply don't run with reasonable
performance any more on hardware that old, so nobody is doing that.
Same for most/all other software requiring sse2.

Most pre-sse2 hardware still in use is probably a headless machine
sitting in some corner, running sshd / apache / samba / cups / whatelse,
but no desktop workload.

If someone wants keep 32bit fedora alive for pre-sse2 hardware I think
the only reasonable thing would be to undust the i586 target, then go
build software which requires sse2 as --target i686 and everything else
as --target i586, i.e. basically stop the effort to patch software for
non-sse2 hardware.  pre-sse2 hardware would have the i586 packages
available only.

But I somehow doubt that even that is worth the effort ...

cheers,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/N4L46UR55TY3F5XBY7EGSLHVPVGRY5IT/

Re: New FESCo Meeting Time and Ticket Policy

[Vít Ondruch]

Dne 19.6.2018 v 04:28 Kevin Kofler napsal(a):
> Stephen Gallagher wrote:
>> * Most FESCo votes will be performed in the tickets. FESCo members will
>> have one week[1] from the creation of the ticket to vote. So long as at
>> least three members have voted, the majority of votes at the end of that
>> week will be counted as the result. If three votes are not received in the
>> first week, voting will be extended by one additional week and the minimum
>> required responses reduced to a single vote. If by the end of that second
>> week no votes have been counted, it will be treated as a vote *against*
>> any change requested by the reporter, thus preserving the current status
>> however it stands. We do not expect this clause to ever be invoked.
> Ouch!
>
> With the previous policy, any issues for FESCo would be tabled for a meeting 
> and announced on this list before the actual meeting.

I think this ^^ is very valid point. I was used to review the tickets
once they were announced they will be discussed on the meeting.

Vít

> That gave a chance to 
> the community to comment on the ticket and/or attend the meeting to join the 
> discussion. Thus, the community had a chance to point out any issues with 
> the submitted proposal before FESCo started voting.
>
> With the new policy, the voting starts immediately with the creation of the 
> ticket (of which FESCo members get notified by mail, whereas the community 
> at large does not) and has a short deadline of 1 week, encouraging voting 
> sooner rather than later. As a result, FESCo members will now almost always 
> vote based on only the submitter's biased writeup (the submitter of a 
> proposal will rarely point out, or even be aware of, all of its drawbacks) 
> before anybody from the community even gets a chance to see the ticket, let 
> alone reply.
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4TH6DJD33OQXSPJKL4KGFPOICVMIBY2W/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XOB6HGTBKQMGAOEEFIKQ5WRQ2CHPMZCT/

[Bug 1588761] CVE-2018-12015 perl-Archive-Tar: perl: Directory traversal in Archive::Tar [fedora-all]

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1588761

Cedric Buissart  changed:

   What|Removed |Added

   Priority|low |medium
Summary|CVE-2018-12015  |CVE-2018-12015
   |perl-Archive-Tar: Directory |perl-Archive-Tar: perl:
   |traversal in Archive::Tar   |Directory traversal in
   |[fedora-all]|Archive::Tar [fedora-all]
   Severity|low |medium



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/6NHXS7VFX3WXAZ3W4GBRZMK4JJ4JYZXJ/

[Bug 1588760] CVE-2018-12015 perl: Directory traversal in Archive::Tar

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1588760

Cedric Buissart  changed:

   What|Removed |Added

   Priority|low |medium
 Whiteboard|impact=low,public=20180607, |impact=moderate,public=2018
   |reported=20180607,source=cv |0607,reported=20180607,sour
   |e,cvss3=3.3/CVSS:3.0/AV:L/A |ce=cve,cvss3=3.3/CVSS:3.0/A
   |C:L/PR:N/UI:R/S:U/C:N/I:L/A |V:L/AC:L/PR:N/UI:R/S:U/C:N/
   |:N,cwe=CWE-22,fedora-all/pe |I:L/A:N,cwe=CWE-22,fedora-a
   |rl-Archive-Tar=affected,rhe |ll/perl-Archive-Tar=affecte
   |l-5/perl-Archive-Tar=wontfi |d,rhel-5/perl-Archive-Tar=w
   |x,rhel-6/perl=wontfix,rhel- |ontfix,rhel-6/perl=wontfix,
   |7/perl-Archive-Tar=affected |rhel-7/perl-Archive-Tar=aff
   |,rhel-8/perl-Archive-Tar=no |ected,rhel-8/perl-Archive-T
   |taffected,rhscl-3/rh-perl52 |ar=notaffected,rhscl-3/rh-p
   |6-perl-Archive-Tar=affected |erl526-perl-Archive-Tar=aff
   |,rhscl-3/rh-perl524-perl-Ar |ected,rhscl-3/rh-perl524-pe
   |chive-Tar=affected,rhscl-3/ |rl-Archive-Tar=affected,rhs
   |rh-perl520-perl-Archive-Tar |cl-3/rh-perl520-perl-Archiv
   |=affected   |e-Tar=affected
   Severity|low |medium



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/AIIM2NXBBNRDICAJDNZCNQHLRXZ45P7S/