Re: Any direction please
It seems that you want to learn something about R, right? Then I'd suggest you get in touch with the R developers as they have more experience with it. Here the people have mostly knowledge about Fedora. It seems that the distribution you run R on seems rather unimportant. So perhaps you want to try your luck there: https://www.r-project.org/mail.html :-) -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
F25 System Wide Change: PHP 7.0
= Proposed System Wide Change: PHP 7.0 = https://fedoraproject.org/wiki/Changes/php70 Change owner(s): * Remi Collet and PHP SIG Update the PHP stack in Fedora to latest version 7.0.x == Detailed Description == Update the PHP stack in Fedora to latest version 7.0.x, which brings a big performance improvement. PHP 7.0.0 was released in December 2015. PHP 7.1.0 is planed for end of year, but is probably not compatible with our Schedule, will probably be a Fedora 26 feature Compatibility for PHP code is very good, while internal API have big changes, implying a major rewrite of C extensions. == Scope == * Proposal owners: Check Koschei status. Test with latest version to ensure compatibility. Work with upstream on bug fixing. * Other developers: All PHP package owners: test with latest version to ensure compatibility. Work with upstream on bug fixing. * Release engineering: Needed mass rebuild (C extensions) done but change owner. * List of deliverables: N/A (not affected by this Change) * Policies and guidelines: N/A (not affected by this Change) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Notice on WebKitGTK+ API/ABI compatibility
On Tuesday, 14 June 2016 at 04:47, Michael Catanzaro wrote: > On Fri, 2016-06-10 at 10:11 +0200, Dominik 'Rathann' Mierzejewski > wrote: > > Could you put this on a page in Fedora wiki and possibly add a link > > in WebKitGTK+ package description and README file? > > Hi, > > Just want to let you know I am planning to document it on the WebKit > wiki and also downstream somewhere (seems like a README might be better > than a wiki page?). That's excellent, thank you! Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20160614.n.0 changes
OLD: Fedora-Rawhide-20160613.n.0 NEW: Fedora-Rawhide-20160614.n.0 = SUMMARY = Added images:10 Dropped images: 2 Added packages: 6 Dropped packages:3 Upgraded packages: 95 Downgraded packages: 0 Size of added packages: 4.95 MiB Size of dropped packages:13.78 MiB Size of upgraded packages: 1.85 GiB Size of downgraded packages: 0.00 B Size change of upgraded packages: 50.95 MiB Size change of downgraded packages: 0.00 B = ADDED IMAGES = Image: LXDE live x86_64 Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20160614.n.0.iso Image: Robotics live i386 Path: Labs/i386/iso/Fedora-Robotics-Live-i386-Rawhide-20160614.n.0.iso Image: Cinnamon live i386 Path: Spins/i386/iso/Fedora-Cinnamon-Live-i386-Rawhide-20160614.n.0.iso Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20160614.n.0.iso Image: Robotics live x86_64 Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20160614.n.0.iso Image: Astronomy_KDE live i386 Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-Rawhide-20160614.n.0.iso Image: SoaS live x86_64 Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20160614.n.0.iso Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20160614.n.0.iso Image: LXDE live i386 Path: Spins/i386/iso/Fedora-LXDE-Live-i386-Rawhide-20160614.n.0.iso Image: SoaS live i386 Path: Spins/i386/iso/Fedora-SoaS-Live-i386-Rawhide-20160614.n.0.iso = DROPPED IMAGES = Image: Security live x86_64 Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20160613.n.0.iso Image: Security live i386 Path: Labs/i386/iso/Fedora-Security-Live-i386-Rawhide-20160613.n.0.iso = ADDED PACKAGES = Package: elog-3.1.1-5.fc25 Summary: Logbook system to manage notes through a Web interface RPMs:elog elog-client Size:4509064 bytes Package: multilib-rpm-config-1-4.fc25 Summary: Multilib packaging helpers RPMs:multilib-rpm-config Size:16638 bytes Package: nc6-1.0-24.fc25 Summary: Netcat with IPv6 Support RPMs:nc6 Size:148218 bytes Package: perl-Test2-Plugin-SpecDeclare-0.03-1.fc25 Summary: Syntax keywords for Test2::Tools::Spec RPMs:perl-Test2-Plugin-SpecDeclare Size:21430 bytes Package: perl-rdapper-0.08-1.fc25 Summary: Command-line RDAP client RPMs:perl-rdapper Size:24154 bytes Package: python-zope-testrunner-4.5.0-3.fc25 Summary: Zope testrunner script RPMs:python2-zope-testrunner python3-zope-testrunner Size:473560 bytes = DROPPED PACKAGES = Package: cinepaint-1.4-14.fc24 Summary: Painting and image retouching program RPMs:cinepaint cinepaint-devel cinepaint-libs Size:13335574 bytes Package: sectool-0.9.5-17.fc24 Summary: A security audit system and intrusion detection system RPMs:sectool sectool-gui Size:1008844 bytes Package: xcm-0.5.3-7.fc24 Summary: X Color Management tools RPMs:xcm Size:102654 bytes = UPGRADED PACKAGES = Package: 389-ds-base-1.3.5.5-1.fc25 Old package: 389-ds-base-1.3.5.4-1.fc25.1 Summary: 389 Directory Server (base) RPMs: 389-ds-base 389-ds-base-devel 389-ds-base-libs 389-ds-base-snmp 389-ds-base-tests Added RPMs: 389-ds-base-snmp 389-ds-base-tests Size: 10819954 bytes Size change: 3003436 bytes Changelog: * Mon Jun 13 2016 Noriko Hosoi - 1.3.5.5-1 - Release 1.3.5.5-1 - Ticket 48848 - modrdn deleteoldrdn can fail to find old attribute value, perhaps due to case folding - Ticket 48832 - CI test - fix ticket failures - Ticket 48833 - 389 showing inconsistent values for shadowMax and shadowWarning in 1.3.5.1 - Ticket 48873 - Backend should accept the reduced cache allocation when issane == 1 - Ticket 48815 - ns-accountstatus.pl - fix DN normalization - Ticket 48880 - adding pre/post extop ability - Ticket 48449 - Import readNSState from richm's repo - Ticket 48877 - Fixes for RPM spec with spectool - Ticket 48404 - libslapd owned by libs and devel - Ticket 48326 - Move CI test to config test suite and refactor - Ticket 48755 - CI test: test case for ticket 48755 - Ticket 48755 - moving an entry could make the online init fail - Ticket 48870 - Correct plugin execution order due to changes in exop - Ticket 48799 - Test cases for objectClass values being dropped. - Ticket 48863 - remove check for vmsize from util_info_sys_pages - Ticket 48872 - Fix segfault and use after free in plugin shutdown - Ticket 48862 - At startup DES to AES password conversion causes timeout in start script - Ticket 48275 - search returns no entry when OR filter component contains non readable attribute - Ticket 47911 - split out snmp agent into a subpackageTicket 47911 - Ticket 48336 - setup-ds should detect if port is already defined - Ticket 48858 - Segfault changing nsslapd-rootpw - Ticket 48855 - Add basic pwdPolicy tests - Ticket 48747 - dirsrv service fails to start when nsslapd-listenhost is confi
Fedora 24 compose report: 20160614.n.0 changes
OLD: Fedora-24-20160613.n.0 NEW: Fedora-24-20160614.n.0 = SUMMARY = Added images:8 Dropped images: 4 Added packages: 0 Dropped packages:2 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0.00 B Size of dropped packages:12.82 MiB Size of upgraded packages: 0.00 B Size of downgraded packages: 0.00 B Size change of upgraded packages: 0.00 B Size change of downgraded packages: 0.00 B = ADDED IMAGES = Image: Mate live i386 Path: Spins/i386/iso/Fedora-MATE_Compiz-Live-i386-24-20160614.n.0.iso Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-24-20160614.n.0.iso Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-24-20160614.n.0.iso Image: Astronomy_KDE live i386 Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-24-20160614.n.0.iso Image: Atomic raw-xz x86_64 Path: CloudImages/x86_64/images/Fedora-Atomic-24-20160614.n.0.x86_64.raw.xz Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-24-20160614.n.0.iso Image: Atomic qcow2 x86_64 Path: CloudImages/x86_64/images/Fedora-Atomic-24-20160614.n.0.x86_64.qcow2 Image: Games live i386 Path: Labs/i386/iso/Fedora-Games-Live-i386-24-20160614.n.0.iso = DROPPED IMAGES = Image: Docker_Base docker armhfp Path: Docker/armhfp/images/Fedora-Docker-Base-24-20160613.n.0.armhfp.tar.xz Image: Docker_Base docker x86_64 Path: Docker/x86_64/images/Fedora-Docker-Base-24-20160613.n.0.x86_64.tar.xz Image: Cinnamon live i386 Path: Spins/i386/iso/Fedora-Cinnamon-Live-i386-24-20160613.n.0.iso Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-24-20160613.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = Package: cinepaint-1.4-14.fc24 Summary: Painting and image retouching program RPMs:cinepaint cinepaint-devel cinepaint-libs Size:13335574 bytes Package: xcm-0.5.3-7.fc24 Summary: X Color Management tools RPMs:xcm Size:102654 bytes = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = Broken deps for armhfp -- [IQmol] IQmol-2.3.0-9.fc24.armv7hl requires libOpenMeshCore.so.3.2 IQmol-2.3.0-9.fc24.armv7hl requires libboost_iostreams.so.1.58.0 IQmol-2.3.0-9.fc24.armv7hl requires libboost_serialization.so.1.58.0 [accumulo] accumulo-core-1.6.4-5.fc24.noarch requires mvn(org.apache.hadoop:hadoop-client) accumulo-examples-1.6.4-5.fc24.noarch requires mvn(org.apache.hadoop:hadoop-client) accumulo-gc-1.6.4-5.fc24.noarch requires mvn(org.apache.hadoop:hadoop-client) accumulo-master-1.6.4-5.fc24.noarch requires mvn(org.apache.hadoop:hadoop-client) accumulo-server-base-1.6.4-5.fc24.noarch requires mvn(org.apache.hadoop:hadoop-client) accumulo-tracer-1.6.4-5.fc24.noarch requires mvn(org.apache.hadoop:hadoop-client) accumulo-tserver-1.6.4-5.fc24.noarch requires mvn(org.apache.hadoop:hadoop-client) [avro] avro-mapred-1.7.5-13.fc24.noarch requires hadoop-client avro-mapred-1.7.5-13.fc24.noarch requires hadoop-mapreduce [glusterfs-hadoop] glusterfs-hadoop-2.3.2-7.fc24.noarch requires mvn(org.apache.hadoop:hadoop-common) glusterfs-hadoop-2.3.2-7.fc24.noarch requires mvn(org.apache.hadoop:hadoop-yarn-server-nodemanager) [golang-github-kubernetes-heapster] golang-github-kubernetes-heapster-devel-0.16.1-3.fc24.noarch requires golang(github.com/google/cadvisor/client) golang-github-kubernetes-heapster-devel-0.16.1-3.fc24.noarch requires golang(github.com/google/cadvisor/info/v1) [golang-github-mistifyio-go-zfs] golang-github-mistifyio-go-zfs-devel-0-0.1.git1b4ae6f.fc24.noarch requires zfs-fuse [golang-github-samalba-dockerclient] golang-github-samalba-dockerclient-devel-0-0.3.gitc37a52f.fc24.noarch requires golang(github.com/docker/docker/pkg/timeutils) [qgis] qgis-grass-2.14.0-2.fc24.armv7hl requires grass = 0:6.4.4 qgis-grass-2.14.0-2.fc24.armv7hl requires libgrass_I.so.6.4 qgis-grass-2.14.0-2.fc24.armv7hl requires libgrass_datetime.so.6.4 qgis-grass-2.14.0-2.fc24.armv7hl requires libgrass_dbmibase.so.6.4 qgis-grass-2.14.0-2.fc24.armv7hl requires libgrass_dbmiclient.so.6.4 qgis-grass-2.14.0-2.fc24.armv7hl requires libgrass_gis.so.6.4 qgis-grass-2.14.0-2.fc24.armv7hl requires libgrass_gproj.so.6.4 qgis-grass-2.14.0-2.fc24.armv7hl requires libgrass_vect.so.6.4 [qt-virt-manager] qt-virt-manager-0.27.50-3.fc24.armv7hl requires nc6 Broken deps for i386 -- [IQmol] IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2 IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0 [accumulo] accumulo-core-1.6.4-5.fc24.noarch requires mvn
pghmcfc uploaded Hash-Util-FieldHash-Compat-0.11.tar.gz for perl-Hash-Util-FieldHash-Compat
8574f75d421b221bb34ee9c58097204a Hash-Util-FieldHash-Compat-0.11.tar.gz http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Hash-Util-FieldHash-Compat/Hash-Util-FieldHash-Compat-0.11.tar.gz/md5/8574f75d421b221bb34ee9c58097204a/Hash-Util-FieldHash-Compat-0.11.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org
Re: Fedora 23
On Tue, 2016-06-14 at 09:59 +0530, Akshay Shipurkar wrote: > Hi Hamish Brunker > > Check out the documentation at the link below > > https://docs.fedoraproject.org/en-US/Fedora/23/html/Installation_Guid > e/ Hi, I think we shouldn't be pointing new users at that whole guide; it's way too complicated. Text mode, PXE boot, installing using VNC, a step- by-step walkthrough of all the Anaconda spokes? The sections from that guide that are needed here are "Preparing for Installation" and "Booting the Installation" as those are the steps that are difficult and unclear for new users. Once you've got the thing booted, you can follow the pretty instructions on the screen, or use the new built-in help system. Michael -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Self Introduction: Oliver Haessler
Hi everyone, my name is Oliver and I am working for Red Hat in the internal IT department. I am responsible for the internal RHEL desktop build we use for our employees. I maintain extra config packages that we add to the existing Red Hat Enterprise Linux, so our employees are getting productive faster. A while ago I decided to give something back to the Open Source community by contributing to the Fedora project. I am co-maintaining several packages I am using myself, or that employees asked for to be included in our internal repositories. One of my goals is to extend the contribution to also include package/release testing and reporting of bugs via bugzilla. I am looking very much forward to work with a lot of interesting people in the community, and learn a lot new things. Cheers Oliver -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
pghmcfc pushed to perl-Hash-Util-FieldHash-Compat (master). "Update to 0.11 (..more)"
From db5043144b6016e026553701eaae2caf367bf59e Mon Sep 17 00:00:00 2001
From: Paul Howarth
Date: Tue, 14 Jun 2016 15:43:18 +0100
Subject: Update to 0.11
- New upstream release 0.11
- Be gentle to older toolchains by avoiding the use of Module::Metadata in
configure-requires (CPAN RT#115310)
- BR: perl-generators where available
- Simplify find command using -delete
---
perl-Hash-Util-FieldHash-Compat.spec | 18 +-
sources | 2 +-
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/perl-Hash-Util-FieldHash-Compat.spec
b/perl-Hash-Util-FieldHash-Compat.spec
index ddca6ec..73cd419 100644
--- a/perl-Hash-Util-FieldHash-Compat.spec
+++ b/perl-Hash-Util-FieldHash-Compat.spec
@@ -1,6 +1,6 @@
Name: perl-Hash-Util-FieldHash-Compat
-Version: 0.10
-Release: 4%{?dist}
+Version: 0.11
+Release: 1%{?dist}
Summary: Use Hash::Util::FieldHash or ties, depending on availability
License: GPL+ or Artistic
URL: http://search.cpan.org/dist/Hash-Util-FieldHash-Compat/
@@ -11,9 +11,10 @@ BuildRequires: coreutils
BuildRequires: findutils
BuildRequires: make
BuildRequires: perl
-BuildRequires: perl(CPAN::Meta::Requirements)
+%if 0%{?fedora} > 20 || 0%{?rhel} > 7
+BuildRequires: perl-generators
+%endif
BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(Module::Metadata)
# Module Runtime
BuildRequires: perl(constant)
BuildRequires: perl(Exporter)
@@ -46,7 +47,7 @@ make %{?_smp_mflags}
%install
make pure_install DESTDIR=%{buildroot}
-find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -type f -name .packlist -delete
%{_fixperms} %{buildroot}
%check
@@ -64,6 +65,13 @@ make test
%{_mandir}/man3/Hash::Util::FieldHash::Compat::Heavy.3*
%changelog
+* Tue Jun 14 2016 Paul Howarth - 0.11-1
+- Update to 0.11
+ - Be gentle to older toolchains by avoiding the use of Module::Metadata in
+configure-requires (CPAN RT#115310)
+- BR: perl-generators where available
+- Simplify find command using -delete
+
* Sun May 15 2016 Jitka Plesnikova - 0.10-4
- Perl 5.24 rebuild
diff --git a/sources b/sources
index dd14b9a..d607ba1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-56251f1ce4037bca14efadc1487c9ab1 Hash-Util-FieldHash-Compat-0.10.tar.gz
+8574f75d421b221bb34ee9c58097204a Hash-Util-FieldHash-Compat-0.11.tar.gz
--
cgit v0.12
http://pkgs.fedoraproject.org/cgit/perl-Hash-Util-FieldHash-Compat.git/commit/?h=master&id=db5043144b6016e026553701eaae2caf367bf59e
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org
Fedora 24-20160614.n.0 compose check report
Missing expected images: Cloud_base raw-xz i386 Failed openQA tests: 2/83 (x86_64), 1/17 (i386), 1/2 (arm) ID: 22508 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/22508 ID: 22520 Test: arm Minimal-raw_xz-raw.xz base_services_start_arm URL: https://openqa.fedoraproject.org/tests/22520 ID: 22586 Test: x86_64 universal install_kickstart_firewall_disabled URL: https://openqa.fedoraproject.org/tests/22586 ID: 22597 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/22597 Passed openQA tests: 81/83 (x86_64), 16/17 (i386), 1/2 (arm) -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Self Introduction: Oliver Haessler
Il 14/Giu/2016 16:46, "Oliver Haessler" ha scritto: > > Hi everyone, > Welcome Oliver! > my name is Oliver and I am working for Red Hat in the internal IT department. > I am responsible for the internal RHEL desktop build we use for our employees. > I maintain extra config packages that we add to the existing Red Hat Enterprise Linux, > so our employees are getting productive faster. > > A while ago I decided to give something back to the Open Source community by > contributing to the Fedora project. I am co-maintaining several packages I am using > myself, or that employees asked for to be included in our internal repositories. > > One of my goals is to extend the contribution to also include package/release testing and > reporting of bugs via bugzilla. > > I am looking very much forward to work with a lot of interesting people in the community, > and learn a lot new things. > > Cheers > Oliver > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide-20160614.n.0 compose check report
Missing expected images: Cloud_base raw-xz i386 Atomic raw-xz x86_64 Kde raw-xz armhfp Minimal raw-xz armhfp Failed openQA tests: 16/83 (x86_64), 5/17 (i386) ID: 22402 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/22402 ID: 22407 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/22407 ID: 22408 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/22408 ID: 22410 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/22410 ID: 22411 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/22411 ID: 22412 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/22412 ID: 22413 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/22413 ID: 22432 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/22432 ID: 22433 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/22433 ID: 22448 Test: x86_64 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/22448 ID: 22458 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/22458 ID: 22460 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/22460 ID: 22472 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/22472 ID: 22476 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/22476 ID: 22477 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/22477 ID: 22482 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/22482 ID: 22483 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/22483 ID: 22488 Test: i386 universal install_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/22488 ID: 22490 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/22490 ID: 22495 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/22495 ID: 22496 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/22496 Passed openQA tests: 63/83 (x86_64), 12/17 (i386) Skipped openQA tests: 4 of 100 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Self Introduction: Oliver Haessler
On Tue, Jun 14, 2016 at 10:45:36AM -0400, Oliver Haessler wrote: > Hi everyone, > > my name is Oliver and I am working for Red Hat in the internal IT department. > I am responsible for the internal RHEL desktop build we use for our employees. > I maintain extra config packages that we add to the existing Red Hat > Enterprise Linux, > so our employees are getting productive faster. > > A while ago I decided to give something back to the Open Source community by > contributing to the Fedora project. I am co-maintaining several packages I am > using > myself, or that employees asked for to be included in our internal > repositories. > > One of my goals is to extend the contribution to also include package/release > testing and > reporting of bugs via bugzilla. > > I am looking very much forward to work with a lot of interesting people in > the community, > and learn a lot new things. Welcome Oliver, nice to see you here :) Pierre -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Self Introduction: Oliver Haessler
Hi everyone, my name is Oliver and I am working for Red Hat in the internal IT department. I am responsible for the internal RHEL desktop build we use for our employees. I maintain extra config packages that we add to the existing Red Hat Enterprise Linux, so our employees are getting productive faster. A while ago I decided to give something back to the Open Source community by contributing to the Fedora project. I am co-maintaining several packages I am using myself, or that employees asked for to be included in our internal repositories. One of my goals is to extend the contribution to also include package/release testing and reporting of bugs via bugzilla. I am looking very much forward to work with a lot of interesting people in the community, and learn a lot new things. Cheers Oliver -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Self Introduction: Oliver Haessler
2016-06-14 16:45 GMT+02:00 Oliver Haessler : > Hi everyone, > > my name is Oliver and I am working for Red Hat in the internal IT department. > I am responsible for the internal RHEL desktop build we use for our employees. > I maintain extra config packages that we add to the existing Red Hat > Enterprise Linux, > so our employees are getting productive faster. > > A while ago I decided to give something back to the Open Source community by > contributing to the Fedora project. I am co-maintaining several packages I am > using > myself, or that employees asked for to be included in our internal > repositories. > > One of my goals is to extend the contribution to also include package/release > testing and > reporting of bugs via bugzilla. > > I am looking very much forward to work with a lot of interesting people in > the community, > and learn a lot new things. > > Cheers > Oliver Welcome Oliver, nice to see you on this side of the firewall :) -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Proposal: remove insecure WebKitGTK+ packages for F27
On Sun, 12 Jun 2016 11:28:00 - "Christian Stadelmann" wrote: > I like this idea very much, thank you! > > Independent to whether this proposal is accepted or not, I'd like to > point out that it would be very useful to notify all maintainers of > this issue, probably by filing a bug to every package that uses one > of these packages (webkitgtk, webkitgtk3), adding a link to your > statement above and tell the maintainer to take action: Contact > upstream. If upstream will be porting the package to Webkit2Gtk, ship > it in Fedora. If not, try to build without WebKit support. If that > fails, deprecate a package by filing bugs to all packages relying on > it. > > Sadly, I don't know any way to automate this and filing ~50 bugs is > quite much. I'll note that if someone is going to do this, please read and follow https://fedoraproject.org/wiki/Mass_bug_filing Thanks. kevin pgp5xcho49IBC.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora development of Snap packages
So I was rather surprised by this Softpaedia article today: http://news.softpedia.com/news/snap-packages-become-the-universal-binary-format-for-all-gnu-linux-distributions-505241.shtml It claims that Canonical state that they have been working with Fedora developers to make this the universal packaging format. The snapcraft.io site instructions say to use a COPR by a Canonical employee who is not a Fedora packager. Does anyone in marketing or development now what the article is referring to and what's going on? -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
I'm testing it out for Phoronix. The copr works correctly, it installs fine. Running snapper works fine, once you figure out what the correct instructions should be (snapcraft.io's instructions are slightly wrong). Applications appear to run correctly and integrate fine in the Workstation environment.. minus LibreOffice. File sizes are massive compared to traditional packages. The Document Foundation's rpm package for Linux x64 is 229 MBs. A LibreOffice 5.2 Beta snap that I found clocked in at 1.1 GB. On Jun 14, 2016 14:26, "James Hogarth" wrote: > So I was rather surprised by this Softpaedia article today: > > > http://news.softpedia.com/news/snap-packages-become-the-universal-binary-format-for-all-gnu-linux-distributions-505241.shtml > > It claims that Canonical state that they have been working with Fedora > developers to make this the universal packaging format. > > The snapcraft.io site instructions say to use a COPR by a Canonical > employee who is not a Fedora packager. > > Does anyone in marketing or development now what the article is referring > to and what's going on? > > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > > -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
libconfuse soname bump
I'm updating libconfuse to 3.0, which is a soname change. The only dependency I can find is libftdi, which I'm doing as well. -j -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote: > Does anyone in marketing or development now what the article is > referring > to and what's going on? Hi, There's an article on Ars as well. The "working with Fedora developers" claim is probably a misunderstanding on Softpedia's part; it's not true, and I doubt Canonical would have said that. What's going on is that Canonical beat us to market in development... and now their marketing folks have beat us in marketing, too. We of course have zero plans to adopt Snappy in Fedora, and in fact multiple Fedora developers are working on a competing solution, Flatpak [1] (formerly xdg-app), which is also being adopted by GNOME and Endless. Until today, Snappy was viewed as Ubuntu-specific, which is why there was so little interest in it. We have not considered, and need to discuss, whether to allow that snapcore package into Fedora proper; there's a strong argument to be made that we should accept all free software, but doing that could undercut our Flatpak effort. If popular upstreams start distributing snaps, then we'll probably have to support it, though. Challenge for the marketing folks: can we get these tech journalism sites writing about Flatpak instead? About GNOME Software's new support for displaying and installing Flatpaks in F24? Otherwise, I see upstreams adopting Snappy and not Flatpak. Background info: In the Workstation working group, we're currently planning to allow replacing RPM packages for graphical apps with Flatpaks. We're also planning to remove Fedora packages for selected apps that are offered as Flatpaks by upstream. For instance, if (hypothetical) Inkscape were to offer a Flatpak download on their web site, the Inkscape developers could request that we remove the Inkscape Fedora package and display their Flatpak in GNOME Software instead; the goal here is to reduce friction between upstream and downstream that people complain about so often, while ensuring it's still very easy to find and install software that runs reliably on Fedora. I guess we could do the same with snaps, if they become sufficiently popular, but it'd be quite unfortunate to support two competing desktop containerization solutions. Michael [1] http://flatpak.org/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On Tue, Jun 14, 2016 at 3:32 PM, Michael Catanzaro wrote: > > We're also planning to remove Fedora packages for selected > apps that are offered as Flatpaks by upstream. For instance, if > (hypothetical) Inkscape were to offer a Flatpak download on their web > site, the Inkscape developers could request that we remove the Inkscape > Fedora package and display their Flatpak in GNOME Software instead; the > goal here is to reduce friction between upstream and downstream that > people complain about so often, while ensuring it's still very easy to > find and install software that runs reliably on Fedora. > > Michael > This is a slight tangent, but by "remove Fedora packages", do you mean actually remove them from the distribution entirely or simply not show the packaged version in e.g. GNOME Software in favor of the upstream Flatpak? The latter makes sense to me, the former seems potentially controversial. Ben Rosser -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On Tue, Jun 14, 2016 at 3:32 PM, Michael Catanzaro wrote: > On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote: >> Does anyone in marketing or development now what the article is >> referring >> to and what's going on? > > Hi, > > There's an article on Ars as well. The "working with Fedora developers" > claim is probably a misunderstanding on Softpedia's part; it's not > true, and I doubt Canonical would have said that. What's going on is > that Canonical beat us to market in development... and now their > marketing folks have beat us in marketing, too. We of course have zero > plans to adopt Snappy in Fedora, and in fact multiple Fedora developers > are working on a competing solution, Flatpak [1] (formerly xdg-app), > which is also being adopted by GNOME and Endless. Until today, Snappy > was viewed as Ubuntu-specific, which is why there was so little > interest in it. "...interest in it within Fedora." is probably what you meant? > We have not considered, and need to discuss, whether to allow that > snapcore package into Fedora proper; there's a strong argument to be > made that we should accept all free software, but doing that could > undercut our Flatpak effort. If popular upstreams start distributing > snaps, then we'll probably have to support it, though. I'm sorry, but undercutting a competing effort isn't a disqualifier for packaging within Fedora. That would be like saying KDE undercuts GNOME or emacs undercuts vi, etc. Software should compete on it's technical merits and generally be available within the Fedora packaging repositories as long as its license and packaging is acceptable. > Challenge for the marketing folks: can we get these tech journalism > sites writing about Flatpak instead? About GNOME Software's new support > for displaying and installing Flatpaks in F24? Otherwise, I see > upstreams adopting Snappy and not Flatpak. That's certainly something worth doing. > Background info: In the Workstation working group, we're currently > planning to allow replacing RPM packages for graphical apps with > Flatpaks. We're also planning to remove Fedora packages for selected > apps that are offered as Flatpaks by upstream. For instance, if > (hypothetical) Inkscape were to offer a Flatpak download on their web > site, the Inkscape developers could request that we remove the Inkscape > Fedora package and display their Flatpak in GNOME Software instead; the > goal here is to reduce friction between upstream and downstream that > people complain about so often, while ensuring it's still very easy to > find and install software that runs reliably on Fedora. I guess we How do you plan on addressing the problem reporting issue? In your example, the Inkscape package will still exist in RPM form for other Editions. That means there are potentially two versions of Inkscape, one from upstream and one packaged in Fedora. How do you ensure problem reports are routed to the correct issue tracker? Even ignoring a potential overlap with upstream Flatpak vs. RPM, the problem reporting issue exists. If GNOME Software is offering up upstream flatpaks directly, I'm concerned it is going to lead to confusion for users when they have issues. josh -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Test-Announce] Fedora 24 Candidate RC-1.2 Available Now!
According to the schedule [1], Fedora 24 Candidate RC-1.2 is now available for testing. Please help us complete all the validation testing! For more information on release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/24 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_24_RC_1.2_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_24_RC_1.2_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_24_RC_1.2_Base https://fedoraproject.org/wiki/Test_Results:Fedora_24_RC_1.2_Server https://fedoraproject.org/wiki/Test_Results:Fedora_24_RC_1.2_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_24_RC_1.2_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_24_RC_1.2_Security_Lab All RC priority test cases for each of these test pages [2] must pass in order to meet the RC Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-24/f-24-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_24_RC_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/ ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/test-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On 14/06/16 20:32, Michael Catanzaro wrote: We have not considered, and need to discuss, whether to allow that snapcore package into Fedora proper; there's a strong argument to be made that we should accept all free software, but doing that could undercut our Flatpak effort. If popular upstreams start distributing snaps, then we'll probably have to support it, though. As others have already said, since when have we been in the business of deciding that certain things can't be packaged because they compete with other things? Background info: In the Workstation working group, we're currently planning to allow replacing RPM packages for graphical apps with Flatpaks. We're also planning to remove Fedora packages for selected apps that are offered as Flatpaks by upstream. For instance, if (hypothetical) Inkscape were to offer a Flatpak download on their web site, the Inkscape developers could request that we remove the Inkscape Fedora package and display their Flatpak in GNOME Software instead; The Inkscape developers? or the Inkscape packager(s) in Fedora? I mean I really hope you're not saying that upstream developers will be able to start demanding that a third party packager's work is removed from Fedora! Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On Tue, 2016-06-14 at 15:40 -0400, Ben Rosser wrote: > This is a slight tangent, but by "remove Fedora packages", do you > mean > actually remove them from the distribution entirely or simply not > show the > packaged version in e.g. GNOME Software in favor of the upstream > Flatpak? > The latter makes sense to me, the former seems potentially > controversial. I was thinking remove the Fedora package. What's the point in maintaining a secret Fedora package for a graphical app, when we're going to be presenting a different version of that app to users? And as Josh says, this would also create confusion regarding where to report bugs, and also confusion when users have two different sets of bugs depending on whether you use a Fedora package or the upstream Flatpak. But maybe we will need to keep the Fedora packages to support spins, e.g. we probably don't want to start removing packages before KDE grows support for Flatpaks in its graphical installer. There's no plan to systematically go around removing Fedora packages in favor of Flatpaks; rather, we plan to do this on a case-by-case basis at the request of upstreams that have developed Flatpaks and want those Flatpaks to be available in Fedora. Package maintainers would be allowed to dispute the change, again on a case-by-case basis, but I don't expect that to happen often. We're also planning to allow third- party RPMs to replace Fedora-provided RPMs following the same procedure. Full details at [1], just keep in mind this is a WIP document in the preproposal stage; i.e. we were not planning to propose it on this list yet. [1] https://fedoraproject.org/wiki/Workstation/Third_party_software_proposal -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
When DNF will be able to install flatpack pkgs then we can stop supporting distro packages for that. -Igor Gnatenko On Jun 14, 2016 9:33 PM, "Michael Catanzaro" wrote: > On Tue, 2016-06-14 at 19:26 +0100, James Hogarth wrote: > > Does anyone in marketing or development now what the article is > > referring > > to and what's going on? > > Hi, > > There's an article on Ars as well. The "working with Fedora developers" > claim is probably a misunderstanding on Softpedia's part; it's not > true, and I doubt Canonical would have said that. What's going on is > that Canonical beat us to market in development... and now their > marketing folks have beat us in marketing, too. We of course have zero > plans to adopt Snappy in Fedora, and in fact multiple Fedora developers > are working on a competing solution, Flatpak [1] (formerly xdg-app), > which is also being adopted by GNOME and Endless. Until today, Snappy > was viewed as Ubuntu-specific, which is why there was so little > interest in it. > > We have not considered, and need to discuss, whether to allow that > snapcore package into Fedora proper; there's a strong argument to be > made that we should accept all free software, but doing that could > undercut our Flatpak effort. If popular upstreams start distributing > snaps, then we'll probably have to support it, though. > > Challenge for the marketing folks: can we get these tech journalism > sites writing about Flatpak instead? About GNOME Software's new support > for displaying and installing Flatpaks in F24? Otherwise, I see > upstreams adopting Snappy and not Flatpak. > > Background info: In the Workstation working group, we're currently > planning to allow replacing RPM packages for graphical apps with > Flatpaks. We're also planning to remove Fedora packages for selected > apps that are offered as Flatpaks by upstream. For instance, if > (hypothetical) Inkscape were to offer a Flatpak download on their web > site, the Inkscape developers could request that we remove the Inkscape > Fedora package and display their Flatpak in GNOME Software instead; the > goal here is to reduce friction between upstream and downstream that > people complain about so often, while ensuring it's still very easy to > find and install software that runs reliably on Fedora. I guess we > could do the same with snaps, if they become sufficiently popular, but > it'd be quite unfortunate to support two competing desktop > containerization solutions. > > Michael > > [1] http://flatpak.org/ > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On Tue, Jun 14, 2016 at 4:02 PM, Michael Catanzaro wrote: > On Tue, 2016-06-14 at 15:40 -0400, Ben Rosser wrote: > > This is a slight tangent, but by "remove Fedora packages", do you > > mean > > actually remove them from the distribution entirely or simply not > > show the > > packaged version in e.g. GNOME Software in favor of the upstream > > Flatpak? > > The latter makes sense to me, the former seems potentially > > controversial. > > I was thinking remove the Fedora package. What's the point in > maintaining a secret Fedora package for a graphical app, when we're > going to be presenting a different version of that app to users? Well, if a packager wants to maintain it, why not? As someone who's a bit skeptical about containers as the future of software distribution, I'd like to continue getting "traditionally packaged" applications from Fedora where possible. I became a Fedora packager as a large part because I wanted to expand the pool of such software that was available in Fedora, by making it available to other users. It seems like that's not a thing we're going to care about as much going forward, which I guess is... fine, but I kind of have mixed feelings about the whole thing. I suspect I am in a minority here, though. > And as > Josh says, this would also create confusion regarding where to report > bugs, and also confusion when users have two different sets of bugs > depending on whether you use a Fedora package or the upstream Flatpak. > That is a valid concern, and not something I'd have an immediate solution for. > There's no plan to systematically go around removing Fedora packages in > favor of Flatpaks; rather, we plan to do this on a case-by-case basis > at the request of upstreams that have developed Flatpaks and want those > Flatpaks to be available in Fedora. Package maintainers would be > allowed to dispute the change, again on a case-by-case basis, but I > don't expect that to happen often. We're also planning to allow third- > party RPMs to replace Fedora-provided RPMs following the same > procedure. > > Full details at [1], just keep in mind this is a WIP document in the > preproposal stage; i.e. we were not planning to propose it on this list > yet. > > [1] > https://fedoraproject.org/wiki/Workstation/Third_party_software_proposal > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > Sure, I understand that the recent press coverage of Ubuntu's solution in this space (Snap) has brought some of this stuff forward preemptively. My gut reaction, though, to *replacing* Fedora packages with upstream-provided containers, though, is, "...thanks, I'll pass". My gut reaction may be entirely irrelevant in the larger scheme of things, but maybe it would be a good idea to at least start discussing this even if a formal proposal is a ways off yet? Though this is a tangent, as I said originally, so maybe this thread is a bad place for such a discussion. Ben Rosser -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On 14/06/16 21:02, Michael Catanzaro wrote: I was thinking remove the Fedora package. What's the point in maintaining a secret Fedora package for a graphical app, when we're going to be presenting a different version of that app to users? And as Josh says, this would also create confusion regarding where to report bugs, and also confusion when users have two different sets of bugs depending on whether you use a Fedora package or the upstream Flatpak. But maybe we will need to keep the Fedora packages to support spins, e.g. we probably don't want to start removing packages before KDE grows support for Flatpaks in its graphical installer. And what about people that just use dnf! Not everybody that uses Fedora as a workstation actually uses "Fedora Workstation" you know. In fact I wouldn't mind betting a majority of people on this list use Fedora on their deskop without buying into the "Fedora Workstation" stuff and using a graphical package manager. There's no plan to systematically go around removing Fedora packages in favor of Flatpaks; rather, we plan to do this on a case-by-case basis at the request of upstreams that have developed Flatpaks and want those Flatpaks to be available in Fedora. Package maintainers would be allowed to dispute the change, again on a case-by-case basis, but I don't expect that to happen often. We're also planning to allow third- party RPMs to replace Fedora-provided RPMs following the same procedure. I suspect this view originates in a very Gnomeish view of the world where upstream and the Fedora packagers are very close but I wonder how well it matches with situations where upstream and distros have a more antagonistic relationship... Full details at [1], just keep in mind this is a WIP document in the preproposal stage; i.e. we were not planning to propose it on this list yet. I'm not surprised given it seems to be quite half baked... Clearly it's entirely aimed at Workstation users yet if allowed it would impact the distribution as a whole on a large scale with no apparent plan as to how to resolve that contradiction. If graphical applications all disappear from the core repositories into upstream managed flatpak things that are only visible through Gnome Software then how are non-Workstation users supposed to access them? Third party rpm repositories don't seem that well thought out either what with vague "they should try and follow our guidelines" but presumably no way of policing that given that I assume all this will bypass the package review process? Equally if each package is supposed to have it's own repository I wonder if any thought has been given to how well dnf scales to hundreds or thousands of repositories? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Any direction please
thanks buddy ! :-) Worthy agent of Light Jules Irenge MSc Student University of Liverpool 2016-06-14 10:08 GMT+01:00 Martin Ueding : > It seems that you want to learn something about R, right? Then I'd > suggest you get in touch with the R developers as they have more > experience with it. Here the people have mostly knowledge about Fedora. > It seems that the distribution you run R on seems rather unimportant. > > So perhaps you want to try your luck there: > https://www.r-project.org/mail.html > > :-) > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora 24 RC 1.2 compose check report
Missing expected images: Cloud_base raw-xz i386 Atomic raw-xz x86_64 Failed openQA tests: 1/82 (x86_64), 1/17 (i386), 1/2 (arm) ID: 22621 Test: arm Minimal-raw_xz-raw.xz base_services_start_arm URL: https://openqa.fedoraproject.org/tests/22621 ID: 22698 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/22698 ID: 22701 Test: x86_64 Workstation-live-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/22701 Passed openQA tests: 81/82 (x86_64), 16/17 (i386), 1/2 (arm) -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora 24 RC 1.2 compose check report
On Tue, 2016-06-14 at 21:16 +, Fedora compose checker wrote: > Missing expected images: > > Cloud_base raw-xz i386 > Atomic raw-xz x86_64 > > Failed openQA tests: 1/82 (x86_64), 1/17 (i386), 1/2 (arm) > > ID: 22621 Test: arm Minimal-raw_xz-raw.xz base_services_start_arm > URL: https://openqa.fedoraproject.org/tests/22621 > ID: 22698 Test: i386 universal upgrade_desktop_32bit > URL: https://openqa.fedoraproject.org/tests/22698 These two are known ones, but... > ID: 22701 Test: x86_64 Workstation-live-iso desktop_terminal > URL: https://openqa.fedoraproject.org/tests/22701 ..this one is pretty weird! No idea how the VM somehow got its 'p' key stuck down. Clearly, though, terminal in GNOME is working fine. :P -- 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 https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Self Introduction: msamir
Hi everyone, my name is msamir have several years of experience in open-source and rpm based distributions. I am interesting in building RPMs for network applications as I have some knowledge in this area and want contribute in Fedora Project. Already read doc - how to create an RPM package, packaging guidelines and package naming guidelines it’s comprehensive, THANKS guys for this great effort. As newbie my first step seeking mentor and package, after checking orphaned packages I come to freeradius-client , the package is important/small/clean and active. I am looking forward to work with Fedora community. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On Tue, 2016-06-14 at 20:53 +0100, Tom Hughes wrote: > I mean I really hope you're not saying that upstream developers will > be > able to start demanding that a third party packager's work is > removed > from Fedora! Hm... it's not supposed to be an antagonistic process. We were expecting it to be more of an "oh, upstream made a Flatpak, that's better than an RPM, so let's switch to that now." Certainly we're not going to come along and try to delete packages over the maintainers' objections. In general, I expect package maintainers would be deciding whether or not to make the switch, but yeah: if the upstream developers request that we switch to their Flatpak, I would hope that package maintainers would be willing to accommodate upstream. In the unlikely event that upstream gets into conflict with the Fedora packager over whether to replace the package with a Flatpak (or upstream-provided RPM), the current plan was for that to be handled on a case-by-case basis by FESCo. Hopefully such situations would be quite rare. Michael -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On Tue, 2016-06-14 at 16:45 -0400, Ben Rosser wrote: > Well, if a packager wants to maintain it, why not? > > As someone who's a bit skeptical about containers as the future of > software > distribution, I'd like to continue getting "traditionally packaged" > applications from Fedora where possible. I became a Fedora packager > as a > large part because I wanted to expand the pool of such software that > was > available in Fedora, by making it available to other users. It seems > like > that's not a thing we're going to care about as much going forward, > which I > guess is... fine, but I kind of have mixed feelings about the whole > thing. > > I suspect I am in a minority here, though. No, we'll still need RPM packages for lots and lots and lots of applications. They're not going away. In the specific case where upstream decides to ship a Flatpak and wants to distribute that Flatpak in Fedora, then it seems advantageous to make that available in Fedora rather than our RPMs, so you get updates from upstream, exactly the way upstream intends, on upstream's schedule, that run the same on every distro, without conflicting with Fedora packages. There's a huge technical advantage to that. But most upstreams are not going to adopt this technology; it's just an option to make distributing your application easier. Packagers are still needed to package stuff that's not yet available on Fedora, same as always. As for whether we should start discussing this... seems it's happening. :) Michael -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
Hi, You're right, we hadn't yet planned for how to handle spins (at least I'm unaware of any such plans). Don't worry, nobody's going to start removing packages if that means making apps inaccessible to folks not using Workstation. Some compatibility story is clearly needed beforehand. Igor suggested that dnf could transparently switch to installing a Flatpak, for instance. Also, keep in mind that Flatpaks are not the only new type of software we intend to support in Fedora. I know other folks are looking into supporting Docker containers; I believe that's a Server WG initiative? This is why all our packages just moved under the rpms namespace in Fedora git. On Tue, 2016-06-14 at 21:46 +0100, Tom Hughes wrote: > I suspect this view originates in a very Gnomeish view of the world > where upstream and the Fedora packagers are very close but I wonder > how > well it matches with situations where upstream and distros have a > more > antagonistic relationship... It's designed for third party application developers; packages work great for big coherent projects like GNOME and KDE that all distros package, but they're terrible for an upstream developer trying to distribute one piece of software to users on 20 different distros. By making [specific, approved] upstream Flatpaks accessible in GNOME Software, no longer does upstream have to deal with Fedora packagers saying "you can't bundle this and that" or "your package doesn't build with GCC 74" or "this violates or packaging guidelines," nor worry about downstream patches causing different behavior in different distros. Instead, Fedora just gets out of the way. The thinking is that this will make upstreams like us more... especially since it allows them to control the pace of updates. Michael -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On Tue, Jun 14, 2016 at 9:04 PM, Michael Catanzaro wrote: > On Tue, 2016-06-14 at 16:45 -0400, Ben Rosser wrote: >> Well, if a packager wants to maintain it, why not? >> >> As someone who's a bit skeptical about containers as the future of >> software >> distribution, I'd like to continue getting "traditionally packaged" >> applications from Fedora where possible. I became a Fedora packager >> as a >> large part because I wanted to expand the pool of such software that >> was >> available in Fedora, by making it available to other users. It seems >> like >> that's not a thing we're going to care about as much going forward, >> which I >> guess is... fine, but I kind of have mixed feelings about the whole >> thing. >> >> I suspect I am in a minority here, though. > > No, we'll still need RPM packages for lots and lots and lots of > applications. They're not going away. > > In the specific case where upstream decides to ship a Flatpak and wants > to distribute that Flatpak in Fedora, then it seems advantageous to > make that available in Fedora rather than our RPMs, so you get updates > from upstream, exactly the way upstream intends, on upstream's > schedule, that run the same on every distro, without conflicting with > Fedora packages. There's a huge technical advantage to that. But most > upstreams are not going to adopt this technology; it's just an option > to make distributing your application easier. Packagers are still > needed to package stuff that's not yet available on Fedora, same as > always. That's a weird position to take. The main selling point of Flatpaks is that they operate fully confined in the user's session space, separate from the rest of the system. I find it extremely hard to believe that we can't make these things coexist safely. In fact, there may even be advantages to having a Flatpak and a system version installed in parallel (especially for those who'd like to do certain things in a confined environment and other things in the regular one). If you're saying that the GNOME people can't handle this use case, then that's a huge problem. I expect this to be the most common one by far. On top of that, what you're suggesting implies that the work we all do as Fedora packagers is without value. We work very hard to provide a neatly integrated system that provides maximum functionality in a secure manner. To a certain extent, I also fundamentally disagree with the approach of modularity via the means of Docker containers and whatnot. I don't even like Flatpaks and Snaps and whatever other thing you want to come up with. At the end of the day, none of these things are solving the problem you are attempting to solve, and may introduce their own issues. Both Windows and macOS have a lot of security issues stemming from the lack of easy introspection of the state of the system due to the nature of how software delivery is done for these platforms. Docker, Flatpak, and Snaps all introduce this problem to the Linux platform, and make it far easier for Linux systems to become permanently vulnerable. The container/security thing is nothing specific or special to Flatpak and others, in fact it's more theater than anything else anyway, as it only works when conditions are "just right" (i.e., Wayland, supercharged containerization with SELinux, etc.). And frankly, if you're trying to solve delivering software in a cross-distro fashion, you're doing it wrong. Take for example how RPMs "work": packages are generated with a set of generic dependencies based on the symbols of libraries and programs. There is literally no reason why I couldn't make a package on CentOS 7 and expect it to work on virtually every Linux distribution release from around that time. To the best of my knowledge, the only significant breakage is with OpenSSL, where Fedora refused to set the same soversion that Debian, Mageia, Ubuntu, and other distros chose (1.0.0). This symbol break has led to it becoming impossible to ship something built on Fedora to work on a wide variety of distributions. Much of the way RPM is designed is to *promote* cross-distro (and to some extent, cross-OS) packages. The fact that we don't is more of an artifact of the past than anything else. It continues to amaze me that we've given up on promoting our core technology in such a manner. In many, many, many ways, it is technically superior (in terms of flexibility and fitness for purpose) to the other alternatives out there, but everyone seems to have given up. It's depressing... -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On Tue, Jun 14, 2016 at 6:36 PM, Neal Gompa wrote: > > On Tue, Jun 14, 2016 at 9:04 PM, Michael Catanzaro > wrote: > > On Tue, 2016-06-14 at 16:45 -0400, Ben Rosser wrote: > >> Well, if a packager wants to maintain it, why not? > >> > >> As someone who's a bit skeptical about containers as the future of > >> software > >> distribution, I'd like to continue getting "traditionally packaged" > >> applications from Fedora where possible. I became a Fedora packager > >> as a > >> large part because I wanted to expand the pool of such software that > >> was > >> available in Fedora, by making it available to other users. It seems > >> like > >> that's not a thing we're going to care about as much going forward, > >> which I > >> guess is... fine, but I kind of have mixed feelings about the whole > >> thing. > >> > >> I suspect I am in a minority here, though. > > > > No, we'll still need RPM packages for lots and lots and lots of > > applications. They're not going away. > > > > In the specific case where upstream decides to ship a Flatpak and wants > > to distribute that Flatpak in Fedora, then it seems advantageous to > > make that available in Fedora rather than our RPMs, so you get updates > > from upstream, exactly the way upstream intends, on upstream's > > schedule, that run the same on every distro, without conflicting with > > Fedora packages. There's a huge technical advantage to that. But most > > upstreams are not going to adopt this technology; it's just an option > > to make distributing your application easier. Packagers are still > > needed to package stuff that's not yet available on Fedora, same as > > always. > > That's a weird position to take. The main selling point of Flatpaks is > that they operate fully confined in the user's session space, separate > from the rest of the system. I find it extremely hard to believe that > we can't make these things coexist safely. In fact, there may even be > advantages to having a Flatpak and a system version installed in > parallel (especially for those who'd like to do certain things in a > confined environment and other things in the regular one). > > If you're saying that the GNOME people can't handle this use case, > then that's a huge problem. I expect this to be the most common one by > far. > > On top of that, what you're suggesting implies that the work we all do > as Fedora packagers is without value. We work very hard to provide a > neatly integrated system that provides maximum functionality in a > secure manner. > > To a certain extent, I also fundamentally disagree with the approach > of modularity via the means of Docker containers and whatnot. I don't > even like Flatpaks and Snaps and whatever other thing you want to come > up with. At the end of the day, none of these things are solving the > problem you are attempting to solve, and may introduce their own > issues. > > Both Windows and macOS have a lot of security issues stemming from the > lack of easy introspection of the state of the system due to the > nature of how software delivery is done for these platforms. Docker, > Flatpak, and Snaps all introduce this problem to the Linux platform, > and make it far easier for Linux systems to become permanently > vulnerable. > > The container/security thing is nothing specific or special to Flatpak > and others, in fact it's more theater than anything else anyway, as it > only works when conditions are "just right" (i.e., Wayland, > supercharged containerization with SELinux, etc.). I *strongly* disagree here. The xdg-app folks seem to be doing a pretty good job with their sandbox. The kernel attack surface is reduced considerably, as is the attack surface against the user via ptrace and filesystem access. If Wayland is available (which is should be!) then so is the attack surface against X. --Andy -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On 06/15/2016 04:11 AM, Andrew Lutomirski wrote: I *strongly* disagree here. The xdg-app folks seem to be doing a pretty good job with their sandbox. The kernel attack surface is reduced considerably, as is the attack surface against the user via ptrace and filesystem access. If Wayland is available (which is should be!) then so is the attack surface against X. What about the direct access to DRI device nodes? Why isn't this a problem that reduces the effectiveness of the sandbox considerably? Thanks, Florian -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On Tue, Jun 14, 2016 at 9:07 PM, Florian Weimer wrote: > On 06/15/2016 04:11 AM, Andrew Lutomirski wrote: > >> I *strongly* disagree here. The xdg-app folks seem to be doing a >> pretty good job with their sandbox. The kernel attack surface is >> reduced considerably, as is the attack surface against the user via >> ptrace and filesystem access. If Wayland is available (which is >> should be!) then so is the attack surface against X. > > > What about the direct access to DRI device nodes? Why isn't this a problem > that reduces the effectiveness of the sandbox considerably? It's certainly a meaningful attack surface. That being said, if it works well, it should be about as dangerous as Chromium's render sandbox, and the latter seems to work fairly well in practice. I'm assuming that xdg-app grants access to render nodes, not to the legacy node. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On Tue, Jun 14, 2016 at 04:45:25PM -0400, Ben Rosser wrote: > > I was thinking remove the Fedora package. What's the point in > > maintaining a secret Fedora package for a graphical app, when we're > > going to be presenting a different version of that app to users? > > > Well, if a packager wants to maintain it, why not? > > As someone who's a bit skeptical about containers as the future of software > distribution, I'd like to continue getting "traditionally packaged" > applications from Fedora where possible. I became a Fedora packager as a > large part because I wanted to expand the pool of such software that was > available in Fedora, by making it available to other users. It seems like > that's not a thing we're going to care about as much going forward, which I > guess is... fine, but I kind of have mixed feelings about the whole thing. > > I suspect I am in a minority here, though. I hope you aren't, I share your sentiments exactly. -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On 06/15/2016 03:04 AM, Michael Catanzaro wrote: In the specific case where upstream decides to ship a Flatpak and wants to distribute that Flatpak in Fedora, then it seems advantageous to make that available in Fedora rather than our RPMs, so you get updates from upstream, exactly the way upstream intends, on upstream's schedule, that run the same on every distro, without conflicting with Fedora packages. But those would just be third-party packages, like we have them today. We won't know what's in them, and we won't be able to update them, diagnose and fix bugs, or integrate them with the rest of the system because we have zero control over them. And if Fedora doesn't rebuild from source, we won't know if it is possible to do so with the bits upstream provides. Florian -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On 06/15/2016 06:27 AM, Andrew Lutomirski wrote: On Tue, Jun 14, 2016 at 9:07 PM, Florian Weimer wrote: On 06/15/2016 04:11 AM, Andrew Lutomirski wrote: I *strongly* disagree here. The xdg-app folks seem to be doing a pretty good job with their sandbox. The kernel attack surface is reduced considerably, as is the attack surface against the user via ptrace and filesystem access. If Wayland is available (which is should be!) then so is the attack surface against X. What about the direct access to DRI device nodes? Why isn't this a problem that reduces the effectiveness of the sandbox considerably? It's certainly a meaningful attack surface. That being said, if it works well, it should be about as dangerous as Chromium's render sandbox, and the latter seems to work fairly well in practice. I'm assuming that xdg-app grants access to render nodes, not to the legacy node. I'm not sure what kind of sandboxing there is. I was just able to open ~/.ssh/id_rsa from a Flatpak application, and change ~/.bash_profile (both outside the sandbox, obviously). I couldn't find any relevant device nodes in the file system namespace. Florian -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora development of Snap packages
On Jun 14, 2016 11:24 PM, "Florian Weimer" wrote: > > On 06/15/2016 06:27 AM, Andrew Lutomirski wrote: >> >> On Tue, Jun 14, 2016 at 9:07 PM, Florian Weimer wrote: >>> >>> On 06/15/2016 04:11 AM, Andrew Lutomirski wrote: >>> I *strongly* disagree here. The xdg-app folks seem to be doing a pretty good job with their sandbox. The kernel attack surface is reduced considerably, as is the attack surface against the user via ptrace and filesystem access. If Wayland is available (which is should be!) then so is the attack surface against X. >>> >>> >>> >>> What about the direct access to DRI device nodes? Why isn't this a problem >>> that reduces the effectiveness of the sandbox considerably? >> >> >> It's certainly a meaningful attack surface. That being said, if it >> works well, it should be about as dangerous as Chromium's render >> sandbox, and the latter seems to work fairly well in practice. I'm >> assuming that xdg-app grants access to render nodes, not to the legacy >> node. > > > I'm not sure what kind of sandboxing there is. I was just able to open ~/.ssh/id_rsa from a Flatpak application, and change ~/.bash_profile (both outside the sandbox, obviously). > > I couldn't find any relevant device nodes in the file system namespace. Hmm. Maybe the current Flatpak doesn't have the xdg-app sandbox enabled. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
