Fedora 21 updates broke support for 4K displays :(
I have used Fedora 21 with 4k display for almost a year, but few weeks ago some update broke support for 4k display resolution. I'm guessing that intel driver is at fault. Have any of have also noticed this issue with 4k displays on Intel hardware or also on some other hardware? Obligatory link to bugzilla - https://bugzilla.redhat.com/show_bug.cgi?id=1238101 ps, I have Lenovo T440s with Haswell graphics. Cheers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 21 updates broke support for 4K displays :(
This album shows how badly this affects productivity when using Fedora as your main workstation: https://goo.gl/photos/d2EAXWTZQRVMsSSPA -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Summary/Minutes from today's FESCo Meeting (2015-07-01)
=== #fedora-meeting: FESCO (2015-07-01) === Meeting started by thozza at 18:01:35 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-07-01/fesco.2015-07-01-18.01.log.html . Meeting summary --- * init process (thozza, 18:01:36) * #1450 F23 System Wide Change: Python 3 as the Default Implementation (thozza, 18:05:02) * AGREED: let's make python3 the only python interpreter on default installs (+5, 0, -1) (thozza, 18:27:02) * Supplementary proposal to treat python2-only work as a bug in the implementation had insufficient votes (+2, 0, -3) (sgallagh, 18:30:40) * #1445 F23 Self Contained Changes (thozza, 18:31:00) * AGREED: All self-contained changes are approved (except netizen spin and io.js which are discussed separately) (+5, 0, -1) (thozza, 18:38:38) * AGREED: Netizen is not approved as spin. We approve the option to have netizen as optional suite in anaconda. Please work with Workstation WG. (+7, 0, -0) (thozza, 18:48:50) * AGREED: io.js change: Let the owner consider replacing node.js completely and revisit next week. (+7, 0, -0) (thozza, 19:00:01) * #1451 F23 System Wide Change: SELinux policy store migration (thozza, 19:00:21) * AGREED: F23 System Wide Change: SELinux policy store migration is approved (+5, 0, -0) (thozza, 19:05:55) * #1452 F23 System Wide Change: Two Week Atomic (thozza, 19:06:12) * AGREED: F23 System Wide Change: Two Week Atomic is approved (+6, 0, -0) (thozza, 19:10:30) * #1453 F23 System Wide Change: Glibc locale subpackaging (thozza, 19:10:43) * AGREED: F23 System Wide Change: Glibc locale subpackaging is approved. Please be careful with upgrade path. (+6, 0, -0) (thozza, 19:16:17) * #1454 F23 System Wide Change: Unicode 8.0 support (thozza, 19:16:36) * AGREED: F23 System Wide Change: Unicode 8.0 support is approved (+6, 0, -0) (thozza, 19:18:43) * #1455 F23 System Wide Change: Standardized Passphrase Policy (thozza, 19:18:58) * postponed until there is some concrete proposal (thozza, 19:19:17) * Next week's chair (thozza, 19:19:24) * paragan to chair next week (thozza, 19:22:13) * Open Floor (thozza, 19:22:26) Meeting ended at 19:30:09 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * thozza (171) * sgallagh (69) * ajax (54) * number80 (51) * jwb (50) * rishi` (31) * zodbot (20) * paragan (19) * rkuska (18) * cleong (15) * mstuchli (11) * mhroncok (7) * mgrepl (5) * plautrba (4) * jkurik (4) * mfabian (2) * maxamillion (2) * pravins (2) * mitr (1) * jkurik_mtg (1) * hguemar (0) * rishi (0) * nirik (0) * dgilmore (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot On 30.06.2015 12:02, Tomas Hozza wrote: Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-07-01 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1450 F23 System Wide Change: Python 3 as the Default Implementation .fesco 1450 https://fedorahosted.org/fesco/ticket/1450 #topic #1445 F23 Self Contained Changes .fesco 1445 https://fedorahosted.org/fesco/ticket/1445 = New business = #topic #1451 F23 System Wide Change: SELinux policy store migration .fesco 1451 https://fedorahosted.org/fesco/ticket/1451 #topic #1452 F23 System Wide Change: Two Week Atomic .fesco 1452 https://fedorahosted.org/fesco/ticket/1452 #topic #1453 F23 System Wide Change: Glibc locale subpackaging .fesco 1453 https://fedorahosted.org/fesco/ticket/1453 #topic #1454 F23 System Wide Change: Unicode 8.0 support .fesco 1454 https://fedorahosted.org/fesco/ticket/1454 #topic #1455 F23 System Wide Change: Standardized Passphrase Policy .fesco 1455 https://fedorahosted.org/fesco/ticket/1455 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
psabata uploaded Inline-C-0.76.tar.gz for perl-Inline-C
c0fbfdd058075c9271a1384c822c9a87 Inline-C-0.76.tar.gz http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Inline-C/Inline-C-0.76.tar.gz/md5/c0fbfdd058075c9271a1384c822c9a87/Inline-C-0.76.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1238625] kwrite is missing in Component list at https://bugzilla.redhat.com for 'Product: Fedora'
https://bugzilla.redhat.com/show_bug.cgi?id=1238625 Emmanuel Seyman emman...@seyman.fr changed: What|Removed |Added CC||jmcdo...@redhat.com, ||qg...@redhat.com Component|bugzilla|Creating/Changing Bugs Version|23 |4.4 Assignee|ita...@ispbrasil.com.br |hss-ied-b...@redhat.com Product|Fedora |Bugzilla QA Contact|extras...@fedoraproject.org |tools-b...@redhat.com --- Comment #1 from Emmanuel Seyman emman...@seyman.fr --- The kwrite package is generated from the kate src.rpm which is present in the component list. Moving to the 'Bugzilla' product which is a more appropriate place for this bug. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Mass bug filing proposal - switching to Python3
Dne 1.7.2015 v 15:33 Robert Kuska napsal(a):
Hello everyone,
I would like to start with Mass bug filing process and as stated
at wiki, the first step is to gain consensus for what I want to make.
Note please that this mass bug filing is conditioned with acceptance of
'Python3 as default' change which will be discussed at todays (01-Jul)
meeting. This mass bug filing aims for python applications.
What is python application?
Application foo is not meant to be used within others python libraries via
`import foo`
and both python3 and python2 versions of foo provides same functionality and
therefore
only one version is needed. This also includes scripts. DevAssistant is an
*application*
- We invoke DA and we don't care if it is python2 and python3 based, both
will fulfill
our task.
Will this be filled for every Python application in Fedora repositories
or just for the subset of application shipped on live cd? Do you have
already some list of such applications?
Vít
Bug description proposal follows:
With the recent change in packaging and upcoming system wide
change 'Python3 as default' Fedora is switching from using Python2
interpreter as default to Python3. This means that all applications
accessible through default Fedora repositories running or using Python
should run on/use Python3.
FAQ:
Q: How do I know if my application is using Python?
A: If this bug is filled against your application it is using Python
yet mistakes happen so if your application does not use Python (and you
double checked on that) please close this bug with a comment stating that.
Q: How to switch to Python3?
A: First, make sure that upstream supports Python3. Next switch
all macros to its python3 equivalents[0] and change all shebangs
using python or python2 to use python3, also replace all the dependencies
python2 dependencies. If stuck contact the reporter.
Q: What if upstream doesn't support Python3?
A: Don't switch to python3, open a bug in upstream asking to support Python3,
help upstream with porting to Python3 (optional) and leave the fedora bug
opened
for tracking. Bug should be closed once the Python3 support is added.
[0]https://fedoraproject.org/wiki/Packaging:Python#Macros
Bug description ends.
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mass bug filing proposal - switching to Python3
Dne 1.7.2015 v 15:33 Robert Kuska napsal(a): I would like to start with Mass bug filing process and as stated at wiki, the first step is to gain consensus for what I want to make. I maintain several python applications, but not all python libraries are available for python3 yet. Just few weeks ago I filed BZ please provide python3 subpackage for several libraries as the python3 subpackage neither exist yet nor it was reported yet. Can you rather file BZs for all python libraries which does not provide python3 library yet? And start filing application BZs only where all (or at least most) libraries will support python3. For example absence of python3 support in ansible modules and python-openstackclient is real blocker for me. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1238493] perl-Inline-C-0.76 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1238493 --- Comment #3 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- psabata's perl-Inline-C-0.76-1.fc23 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=666445 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1238625] kwrite is missing in Component list at https://bugzilla.redhat.com for 'Product: Fedora'
https://bugzilla.redhat.com/show_bug.cgi?id=1238625 sandeep shedmake sshed...@redhat.com changed: What|Removed |Added See Also||https://bugzilla.redhat.com ||/show_bug.cgi?id=1238611 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Test-Vars
perl-Test-Vars has broken dependencies in the rawhide tree: On x86_64: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Task-Catalyst
perl-Task-Catalyst has broken dependencies in the rawhide tree: On x86_64: perl-Task-Catalyst-4.02-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Task-Catalyst-4.02-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Task-Catalyst-4.02-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Devel-BeginLift
perl-Devel-BeginLift has broken dependencies in the rawhide tree: On x86_64: perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Devel-BeginLift-0.001003-9.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-BeginLift-0.001003-9.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-POE-API-Peek
perl-POE-API-Peek has broken dependencies in the rawhide tree: On x86_64: 1:perl-POE-API-Peek-2.20-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: 1:perl-POE-API-Peek-2.20-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: 1:perl-POE-API-Peek-2.20-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1238494] perl-Inline-Filters-0.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1238494 --- Comment #3 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- psabata's perl-Inline-Filters-0.17-1.fc23 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=666454 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
psabata pushed to perl-Inline-C (f22). 0.75 bump, documentation fixes
From b9ac1099356becd7996366c6f3800ae9ca7dbf6c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= con...@redhat.com
Date: Wed, 18 Mar 2015 17:54:52 +0100
Subject: 0.75 bump, documentation fixes
diff --git a/.gitignore b/.gitignore
index 4340b70..704b4a3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@
/Inline-C-0.67.tar.gz
/Inline-C-0.73.tar.gz
/Inline-C-0.74.tar.gz
+/Inline-C-0.75.tar.gz
diff --git a/perl-Inline-C.spec b/perl-Inline-C.spec
index 87b8d21..3080910 100644
--- a/perl-Inline-C.spec
+++ b/perl-Inline-C.spec
@@ -1,5 +1,5 @@
Name: perl-Inline-C
-Version:0.74
+Version:0.75
Release:1%{?dist}
Summary:Write Perl subroutines in C
License:GPL+ or Artistic
@@ -80,6 +80,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Mar 18 2015 Petr Šabata con...@redhat.com - 0.75-1
+- 0.75 bump, documentation fixes
+
* Wed Feb 18 2015 Petr Šabata con...@redhat.com - 0.74-1
- 0.74 bump, Win32 fixes only
diff --git a/sources b/sources
index 1a0288a..e68b8b4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1609466bad491f10dad85eb43dc2ca0c Inline-C-0.74.tar.gz
+4e9c295c1514da492306719a194f5711 Inline-C-0.75.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Inline-C.git/commit/?h=f22id=b9ac1099356becd7996366c6f3800ae9ca7dbf6c
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
psabata pushed to perl-Inline-C (f22). 0.76 bump
From 1ba207c7ee2a7a1baa74df8f7c6512ced695e187 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= con...@redhat.com
Date: Thu, 2 Jul 2015 11:25:59 +0200
Subject: 0.76 bump
diff --git a/.gitignore b/.gitignore
index 704b4a3..3be1fed 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
/Inline-C-0.73.tar.gz
/Inline-C-0.74.tar.gz
/Inline-C-0.75.tar.gz
+/Inline-C-0.76.tar.gz
diff --git a/perl-Inline-C.spec b/perl-Inline-C.spec
index 78821a5..87b47f1 100644
--- a/perl-Inline-C.spec
+++ b/perl-Inline-C.spec
@@ -1,6 +1,6 @@
Name: perl-Inline-C
-Version:0.75
-Release:3%{?dist}
+Version:0.76
+Release:1%{?dist}
Summary:Write Perl subroutines in C
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,6 +8,7 @@ URL:http://search.cpan.org/dist/Inline-C/
Source0:
http://search.cpan.org/CPAN/authors/id/I/IN/INGY/Inline-C-%{version}.tar.gz
BuildArch: noarch
# Build
+BuildRequires: make
BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker) = 7.00
BuildRequires: perl(File::ShareDir::Install)
@@ -20,12 +21,12 @@ BuildRequires: perl(constant)
BuildRequires: perl(Cwd)
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Fcntl)
-BuildRequires: perl(File::Spec)
+BuildRequires: perl(File::Spec) = 0.8
BuildRequires: perl(FindBin)
BuildRequires: perl(if)
BuildRequires: perl(Inline) = 0.58
# Inline::Filters and Inline::Struct are optional and introduce circular deps
-BuildRequires: perl(Parse::RecDescent)
+BuildRequires: perl(Parse::RecDescent) = 1.967009
BuildRequires: perl(Pegex::Base)
BuildRequires: perl(Pegex::Parser)
BuildRequires: perl(Time::HiRes)
@@ -40,19 +41,22 @@ BuildRequires: perl(File::Path)
BuildRequires: perl(IO::All)
BuildRequires: perl(IPC::Cmd)
BuildRequires: perl(lib)
-BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Warn)
-BuildRequires: perl(version)
+BuildRequires: perl(Test::More) = 0.88
+BuildRequires: perl(Test::Warn) = 0.23
+BuildRequires: perl(version) = 0.77
BuildRequires: perl(YAML::XS)
Requires: perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo
$version))
Requires: perl(Fcntl)
Requires: perl(FindBin)
+Requires: perl(File::Spec) = 0.8
Requires: perl(Inline) = 0.58
-Requires: perl(Parse::RecDescent)
+Requires: perl(Parse::RecDescent) = 1.967009
Requires: perl(Time::HiRes)
# Split from Inline in 0.58
Conflicts: perl-Inline 0.58
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(File::Spec\\)$
+
%description
Inline::C is a module that allows you to write Perl subroutines in C. Since
version 0.30 the Inline module supports multiple programming languages and
@@ -80,6 +84,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jul 02 2015 Petr Šabata con...@redhat.com - 0.76-1
+- 0.76 bump
+
* Thu Jun 18 2015 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.75-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
diff --git a/sources b/sources
index e68b8b4..c88d531 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4e9c295c1514da492306719a194f5711 Inline-C-0.75.tar.gz
+c0fbfdd058075c9271a1384c822c9a87 Inline-C-0.76.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Inline-C.git/commit/?h=f22id=1ba207c7ee2a7a1baa74df8f7c6512ced695e187
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
psabata pushed to perl-Inline-C (f22). - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
From 137e479097165ffa39f44827ce1225f975f81b2c Mon Sep 17 00:00:00 2001
From: Dennis Gilmore den...@ausil.us
Date: Thu, 18 Jun 2015 03:54:55 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
diff --git a/perl-Inline-C.spec b/perl-Inline-C.spec
index 4d1b29c..78821a5 100644
--- a/perl-Inline-C.spec
+++ b/perl-Inline-C.spec
@@ -1,6 +1,6 @@
Name: perl-Inline-C
Version:0.75
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Write Perl subroutines in C
License:GPL+ or Artistic
Group: Development/Libraries
@@ -80,6 +80,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jun 18 2015 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.75-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
+
* Sat Jun 06 2015 Jitka Plesnikova jples...@redhat.com - 0.75-2
- Perl 5.22 rebuild
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Inline-C.git/commit/?h=f22id=137e479097165ffa39f44827ce1225f975f81b2c
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
psabata pushed to perl-Inline-C (f22). Perl 5.22 rebuild
From e9ccc582d73239dfd14d518dd9a6a4c6531265d0 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova jples...@redhat.com
Date: Sat, 6 Jun 2015 08:45:07 +0200
Subject: Perl 5.22 rebuild
diff --git a/perl-Inline-C.spec b/perl-Inline-C.spec
index 3080910..4d1b29c 100644
--- a/perl-Inline-C.spec
+++ b/perl-Inline-C.spec
@@ -1,6 +1,6 @@
Name: perl-Inline-C
Version:0.75
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Write Perl subroutines in C
License:GPL+ or Artistic
Group: Development/Libraries
@@ -80,6 +80,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sat Jun 06 2015 Jitka Plesnikova jples...@redhat.com - 0.75-2
+- Perl 5.22 rebuild
+
* Wed Mar 18 2015 Petr Šabata con...@redhat.com - 0.75-1
- 0.75 bump, documentation fixes
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Inline-C.git/commit/?h=f22id=e9ccc582d73239dfd14d518dd9a6a4c6531265d0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
psabata pushed to perl-Inline-Filters (f22). 0.17 bump (..more)
From 8c591588c4ebd7fa6f8007acfcced706875f2577 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= con...@redhat.com
Date: Thu, 2 Jul 2015 13:36:23 +0200
Subject: 0.17 bump
- Modernize SPEC
diff --git a/.gitignore b/.gitignore
index 779c3ce..5adc1e6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Inline-Filters-0.14.tar.gz
/Inline-Filters-0.16.tar.gz
+/Inline-Filters-0.17.tar.gz
diff --git a/perl-Inline-Filters.spec b/perl-Inline-Filters.spec
index 0247831..a8b4bb1 100644
--- a/perl-Inline-Filters.spec
+++ b/perl-Inline-Filters.spec
@@ -1,24 +1,30 @@
Name: perl-Inline-Filters
-Version:0.16
-Release:4%{?dist}
+Version:0.17
+Release:1%{?dist}
Summary:Common source code filters for Inline modules
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Inline-Filters/
Source0:
http://www.cpan.org/authors/id/R/RU/RURBAN/Inline-Filters-%{version}.tar.gz
BuildArch: noarch
+# Build
+BuildRequires: make
BuildRequires: perl
-BuildRequires: perl(Config)
BuildRequires: perl(ExtUtils::MakeMaker) = 6.76
-BuildRequires: perl(File::Copy)
+# Runtime
+BuildRequires: perl(Config)
BuildRequires: perl(File::Spec)
+BuildRequires: perl(strict)
+# Tests only
+BuildRequires: perl(File::Copy)
BuildRequires: perl(Inline)
BuildRequires: perl(Inline::C)
# Required indirectly, optional Inline dependency
BuildRequires: perl(Parse::RecDescent)
-BuildRequires: perl(strict)
BuildRequires: perl(Test::More)
BuildRequires: perl(warnings)
+# Optional tests only
+BuildRequires: perl(Test::Pod) = 1.00
Requires: perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo
$version))
Requires: perl(Parse::RecDescent)
@@ -41,11 +47,16 @@ make pure_install DESTDIR=%{buildroot}
make test
%files
-%doc Changes LICENSE README
+%license LICENSE
+%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Thu Jul 02 2015 Petr Šabata con...@redhat.com - 0.17-1
+- 0.17 bump
+- Modernize SPEC
+
* Thu Jun 18 2015 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.16-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
diff --git a/sources b/sources
index ed0752d..3aca058 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2abd464ff235040c0d7e966151908026 Inline-Filters-0.16.tar.gz
+9038d669366c15fe45a40c337e4a6bda Inline-Filters-0.17.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Inline-Filters.git/commit/?h=f22id=8c591588c4ebd7fa6f8007acfcced706875f2577
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
psabata pushed to perl-Inline-Filters (f22). Perl 5.22 rebuild
From e8e95ef157283c14540b48335bfaa69688caf18b Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova jples...@redhat.com
Date: Sat, 6 Jun 2015 09:05:05 +0200
Subject: Perl 5.22 rebuild
diff --git a/perl-Inline-Filters.spec b/perl-Inline-Filters.spec
index 7186d57..4d355a6 100644
--- a/perl-Inline-Filters.spec
+++ b/perl-Inline-Filters.spec
@@ -1,6 +1,6 @@
Name: perl-Inline-Filters
Version:0.16
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Common source code filters for Inline modules
License:GPL+ or Artistic
Group: Development/Libraries
@@ -46,6 +46,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sat Jun 06 2015 Jitka Plesnikova jples...@redhat.com - 0.16-3
+- Perl 5.22 rebuild
+
* Thu Aug 28 2014 Jitka Plesnikova jples...@redhat.com - 0.16-2
- Perl 5.20 rebuild
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Inline-Filters.git/commit/?h=f22id=e8e95ef157283c14540b48335bfaa69688caf18b
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
psabata pushed to perl-Inline-Filters (master). 0.17 bump (..more)
From 8c591588c4ebd7fa6f8007acfcced706875f2577 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= con...@redhat.com
Date: Thu, 2 Jul 2015 13:36:23 +0200
Subject: 0.17 bump
- Modernize SPEC
diff --git a/.gitignore b/.gitignore
index 779c3ce..5adc1e6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Inline-Filters-0.14.tar.gz
/Inline-Filters-0.16.tar.gz
+/Inline-Filters-0.17.tar.gz
diff --git a/perl-Inline-Filters.spec b/perl-Inline-Filters.spec
index 0247831..a8b4bb1 100644
--- a/perl-Inline-Filters.spec
+++ b/perl-Inline-Filters.spec
@@ -1,24 +1,30 @@
Name: perl-Inline-Filters
-Version:0.16
-Release:4%{?dist}
+Version:0.17
+Release:1%{?dist}
Summary:Common source code filters for Inline modules
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Inline-Filters/
Source0:
http://www.cpan.org/authors/id/R/RU/RURBAN/Inline-Filters-%{version}.tar.gz
BuildArch: noarch
+# Build
+BuildRequires: make
BuildRequires: perl
-BuildRequires: perl(Config)
BuildRequires: perl(ExtUtils::MakeMaker) = 6.76
-BuildRequires: perl(File::Copy)
+# Runtime
+BuildRequires: perl(Config)
BuildRequires: perl(File::Spec)
+BuildRequires: perl(strict)
+# Tests only
+BuildRequires: perl(File::Copy)
BuildRequires: perl(Inline)
BuildRequires: perl(Inline::C)
# Required indirectly, optional Inline dependency
BuildRequires: perl(Parse::RecDescent)
-BuildRequires: perl(strict)
BuildRequires: perl(Test::More)
BuildRequires: perl(warnings)
+# Optional tests only
+BuildRequires: perl(Test::Pod) = 1.00
Requires: perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo
$version))
Requires: perl(Parse::RecDescent)
@@ -41,11 +47,16 @@ make pure_install DESTDIR=%{buildroot}
make test
%files
-%doc Changes LICENSE README
+%license LICENSE
+%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Thu Jul 02 2015 Petr Šabata con...@redhat.com - 0.17-1
+- 0.17 bump
+- Modernize SPEC
+
* Thu Jun 18 2015 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.16-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
diff --git a/sources b/sources
index ed0752d..3aca058 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2abd464ff235040c0d7e966151908026 Inline-Filters-0.16.tar.gz
+9038d669366c15fe45a40c337e4a6bda Inline-Filters-0.17.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Inline-Filters.git/commit/?h=masterid=8c591588c4ebd7fa6f8007acfcced706875f2577
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
psabata uploaded Inline-Filters-0.17.tar.gz for perl-Inline-Filters
9038d669366c15fe45a40c337e4a6bda Inline-Filters-0.17.tar.gz http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Inline-Filters/Inline-Filters-0.17.tar.gz/md5/9038d669366c15fe45a40c337e4a6bda/Inline-Filters-0.17.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Mass bug filing proposal - switching to Python3
- Original Message -
From: Vít Ondruch vondr...@redhat.com
To: devel@lists.fedoraproject.org
Sent: Thursday, July 2, 2015 11:03:35 AM
Subject: Re: Mass bug filing proposal - switching to Python3
Dne 1.7.2015 v 15:33 Robert Kuska napsal(a):
Hello everyone,
I would like to start with Mass bug filing process and as stated
at wiki, the first step is to gain consensus for what I want to make.
Note please that this mass bug filing is conditioned with acceptance of
'Python3 as default' change which will be discussed at todays (01-Jul)
meeting. This mass bug filing aims for python applications.
What is python application?
Application foo is not meant to be used within others python libraries via
`import foo`
and both python3 and python2 versions of foo provides same functionality
and therefore
only one version is needed. This also includes scripts. DevAssistant is an
*application*
- We invoke DA and we don't care if it is python2 and python3 based, both
will fulfill
our task.
Will this be filled for every Python application in Fedora repositories
or just for the subset of application shipped on live cd? Do you have
already some list of such applications?
We aim for all Python applications. Currently we have only list of applications
shipped on live-cd, but of course we will also post the list of all
applications.
Is it needed to post the list along with the mass bug filing proposal?
To defend the need of filing against all applications:
At the most recent fesco meeting fesco members agreed to accept our Python3
as default change but under different name as they believe that calling Python3
the default interpreter in Fedora is misleading as the Fedora infra, packaging
tools
and many others applications which ain't covered by our change still need
Python2
to run. To address their concerns we've decided to pursue the usage of Python3
across
all Fedora packages (where possible).
Currently Python3 is the default interpreter in a sense of packaging only
but we would like to make it the default for Fedora as whole and this
mass bug filing is just a one of the milestones.
Vít
Bug description proposal follows:
With the recent change in packaging and upcoming system wide
change 'Python3 as default' Fedora is switching from using Python2
interpreter as default to Python3. This means that all applications
accessible through default Fedora repositories running or using Python
should run on/use Python3.
FAQ:
Q: How do I know if my application is using Python?
A: If this bug is filled against your application it is using Python
yet mistakes happen so if your application does not use Python (and you
double checked on that) please close this bug with a comment stating that.
Q: How to switch to Python3?
A: First, make sure that upstream supports Python3. Next switch
all macros to its python3 equivalents[0] and change all shebangs
using python or python2 to use python3, also replace all the dependencies
python2 dependencies. If stuck contact the reporter.
Q: What if upstream doesn't support Python3?
A: Don't switch to python3, open a bug in upstream asking to support
Python3,
help upstream with porting to Python3 (optional) and leave the fedora bug
opened
for tracking. Bug should be closed once the Python3 support is added.
[0]https://fedoraproject.org/wiki/Packaging:Python#Macros
Bug description ends.
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Robert Kuska
{rkuska}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1238493] perl-Inline-C-0.76 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1238493 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Inline-C-0.76-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/perl-Inline-C-0.76-1.fc22 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
psabata pushed to perl-Inline-Filters (f22). - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
From 42c7460f0c03b0aec296f85a955ee2b43e1cac6d Mon Sep 17 00:00:00 2001
From: Dennis Gilmore den...@ausil.us
Date: Thu, 18 Jun 2015 03:55:14 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
diff --git a/perl-Inline-Filters.spec b/perl-Inline-Filters.spec
index 4d355a6..0247831 100644
--- a/perl-Inline-Filters.spec
+++ b/perl-Inline-Filters.spec
@@ -1,6 +1,6 @@
Name: perl-Inline-Filters
Version:0.16
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Common source code filters for Inline modules
License:GPL+ or Artistic
Group: Development/Libraries
@@ -46,6 +46,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jun 18 2015 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.16-4
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
+
* Sat Jun 06 2015 Jitka Plesnikova jples...@redhat.com - 0.16-3
- Perl 5.22 rebuild
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Inline-Filters.git/commit/?h=f22id=42c7460f0c03b0aec296f85a955ee2b43e1cac6d
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [ANNOUNCE] kexec-tools 2.0.10
On Thu, Jul 2, 2015 at 4:06 AM, Dave Young dyo...@redhat.com wrote: On 07/01/15 at 09:08am, Peter Robinson wrote: On Wed, Jul 1, 2015 at 1:36 AM, Dave Young dyo...@redhat.com wrote: Pratyush, Thanks for the effort, let's cc Fedora devel list, see if we can get help from Fedora experts. Summary the problem: Latest kexec-tools koji build in rawhide results in a wrong kexec binary, kexec load fails with something like below: R_X86_64_29 Unhandled rela relocation: R_X86_64_29 This kinds of errors usually caused by gcc unnecesarrily add options like -fexception, -fPIC, -fstack-protetor-* for building kexec purgatory which runs in kernel mode. I filed a bug below: https://bugzilla.redhat.com/show_bug.cgi?id=1236456 Appreciate for any hints how to fix the problem. I commented on the BZ Peter, thank you. Resolved with your suggestion. Excellent, btw what's the status of aarch64 support landing upstream so we can enable it in Fedora? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Agenda for Env-and-Stacks WG meeting (2015-07-02)
A bit late announce, sorry for that, but I was offline for couple of days. WG meeting will be at 12:00 UTC (9:00 EST, 14:00 Brno, 8:00 Boston, 21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting-2 on Freenode. = Topics = * New meeting time? * Elections wrap-up * Changes in governance * Fedora user feedback * Open Floor -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1238625] New: kwrite is missing in Component list at https://bugzilla.redhat.com for 'Product: Fedora'
https://bugzilla.redhat.com/show_bug.cgi?id=1238625 Bug ID: 1238625 Summary: kwrite is missing in Component list at https://bugzilla.redhat.com for 'Product: Fedora' Product: Fedora Version: 23 Component: bugzilla Severity: high Assignee: ita...@ispbrasil.com.br Reporter: sshed...@redhat.com QA Contact: extras...@fedoraproject.org CC: bazanlui...@gmail.com, emman...@seyman.fr, ita...@ispbrasil.com.br, perl-devel@lists.fedoraproject.org Description of problem: 'kwrite' is missing in the 'Component' list at https://bugzilla.redhat.com for 'Product: Fedora' Version-Release number of selected component (if applicable): version 4.4.9032-3 How reproducible: Always Steps to Reproduce: 1. Login to https://bugzilla.redhat.com/ with your login credentials 2. Click New [https://bugzilla.redhat.com/enter_bug.cgi] 3. Select 'Product: Fedora' 4. Type 'kwrite' in 'Component:' text field Actual results: kwrite is not available Expected results: Kwrite should be available Additional info: I encountered a bug with kwrite-15.04.0-1.fc22 [https://bugzilla.redhat.com/show_bug.cgi?id=1238611]. Since 'kwrite' was not available in the 'Component' list, thereby filed this bugzilla report. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
psabata pushed to perl-Inline-C (master). 0.76 bump
From 1ba207c7ee2a7a1baa74df8f7c6512ced695e187 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= con...@redhat.com
Date: Thu, 2 Jul 2015 11:25:59 +0200
Subject: 0.76 bump
diff --git a/.gitignore b/.gitignore
index 704b4a3..3be1fed 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
/Inline-C-0.73.tar.gz
/Inline-C-0.74.tar.gz
/Inline-C-0.75.tar.gz
+/Inline-C-0.76.tar.gz
diff --git a/perl-Inline-C.spec b/perl-Inline-C.spec
index 78821a5..87b47f1 100644
--- a/perl-Inline-C.spec
+++ b/perl-Inline-C.spec
@@ -1,6 +1,6 @@
Name: perl-Inline-C
-Version:0.75
-Release:3%{?dist}
+Version:0.76
+Release:1%{?dist}
Summary:Write Perl subroutines in C
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,6 +8,7 @@ URL:http://search.cpan.org/dist/Inline-C/
Source0:
http://search.cpan.org/CPAN/authors/id/I/IN/INGY/Inline-C-%{version}.tar.gz
BuildArch: noarch
# Build
+BuildRequires: make
BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker) = 7.00
BuildRequires: perl(File::ShareDir::Install)
@@ -20,12 +21,12 @@ BuildRequires: perl(constant)
BuildRequires: perl(Cwd)
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Fcntl)
-BuildRequires: perl(File::Spec)
+BuildRequires: perl(File::Spec) = 0.8
BuildRequires: perl(FindBin)
BuildRequires: perl(if)
BuildRequires: perl(Inline) = 0.58
# Inline::Filters and Inline::Struct are optional and introduce circular deps
-BuildRequires: perl(Parse::RecDescent)
+BuildRequires: perl(Parse::RecDescent) = 1.967009
BuildRequires: perl(Pegex::Base)
BuildRequires: perl(Pegex::Parser)
BuildRequires: perl(Time::HiRes)
@@ -40,19 +41,22 @@ BuildRequires: perl(File::Path)
BuildRequires: perl(IO::All)
BuildRequires: perl(IPC::Cmd)
BuildRequires: perl(lib)
-BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Warn)
-BuildRequires: perl(version)
+BuildRequires: perl(Test::More) = 0.88
+BuildRequires: perl(Test::Warn) = 0.23
+BuildRequires: perl(version) = 0.77
BuildRequires: perl(YAML::XS)
Requires: perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo
$version))
Requires: perl(Fcntl)
Requires: perl(FindBin)
+Requires: perl(File::Spec) = 0.8
Requires: perl(Inline) = 0.58
-Requires: perl(Parse::RecDescent)
+Requires: perl(Parse::RecDescent) = 1.967009
Requires: perl(Time::HiRes)
# Split from Inline in 0.58
Conflicts: perl-Inline 0.58
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(File::Spec\\)$
+
%description
Inline::C is a module that allows you to write Perl subroutines in C. Since
version 0.30 the Inline module supports multiple programming languages and
@@ -80,6 +84,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jul 02 2015 Petr Šabata con...@redhat.com - 0.76-1
+- 0.76 bump
+
* Thu Jun 18 2015 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.75-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
diff --git a/sources b/sources
index e68b8b4..c88d531 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4e9c295c1514da492306719a194f5711 Inline-C-0.75.tar.gz
+c0fbfdd058075c9271a1384c822c9a87 Inline-C-0.76.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Inline-C.git/commit/?h=masterid=1ba207c7ee2a7a1baa74df8f7c6512ced695e187
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-B-Hooks-OP-Check-EntersubForCV
perl-B-Hooks-OP-Check-EntersubForCV has broken dependencies in the rawhide tree: On x86_64: perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires libperl.so.5.20 On armhfp: perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Carp-REPL
perl-Carp-REPL has broken dependencies in the rawhide tree: On x86_64: perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2) On i386: perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2) On armhfp: perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Data-Dump-Streamer
perl-Data-Dump-Streamer has broken dependencies in the rawhide tree: On x86_64: perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-CGI-Application-Structured-Tools
perl-CGI-Application-Structured-Tools has broken dependencies in the rawhide tree: On x86_64: perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: polymake
polymake has broken dependencies in the rawhide tree: On x86_64: polymake-2.13-22.git20141013.fc23.x86_64 requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.x86_64 requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.x86_64 requires libperl.so.5.20()(64bit) On i386: polymake-2.13-22.git20141013.fc23.i686 requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.i686 requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.i686 requires libperl.so.5.20 On armhfp: polymake-2.13-22.git20141013.fc23.armv7hl requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.armv7hl requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Data-Alias
perl-Data-Alias has broken dependencies in the rawhide tree: On x86_64: perl-Data-Alias-1.18-4.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Alias-1.18-4.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Data-Alias-1.18-4.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Alias-1.18-4.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Data-Alias-1.18-4.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Alias-1.18-4.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Devel-FindRef
perl-Devel-FindRef has broken dependencies in the rawhide tree: On x86_64: perl-Devel-FindRef-1.44-3.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-FindRef-1.44-3.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Devel-FindRef-1.44-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-FindRef-1.44-3.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Devel-FindRef-1.44-3.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-FindRef-1.44-3.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Method-Signatures
perl-Method-Signatures has broken dependencies in the rawhide tree: On x86_64: perl-Method-Signatures-20141021-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On i386: perl-Method-Signatures-20141021-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On armhfp: perl-Method-Signatures-20141021-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Gtk3
perl-Gtk3 has broken dependencies in the rawhide tree: On x86_64: perl-Gtk3-0.019-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On i386: perl-Gtk3-0.019-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On armhfp: perl-Gtk3-0.019-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-MongoDB
perl-MongoDB has broken dependencies in the rawhide tree: On x86_64: perl-MongoDB-0.702.2-5.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-MongoDB-0.702.2-5.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-MongoDB-0.702.2-5.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-MongoDB-0.702.2-5.fc22.i686 requires libperl.so.5.20 On armhfp: perl-MongoDB-0.702.2-5.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-MongoDB-0.702.2-5.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Test-AutoBuild
perl-Test-AutoBuild has broken dependencies in the rawhide tree: On x86_64: perl-Test-AutoBuild-1.2.4-15.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Test-AutoBuild-1.2.4-15.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Test-AutoBuild-1.2.4-15.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Task-Kensho-Testing
perl-Task-Kensho-Testing has broken dependencies in the rawhide tree: On x86_64: perl-Task-Kensho-Testing-0.38-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On i386: perl-Task-Kensho-Testing-0.38-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On armhfp: perl-Task-Kensho-Testing-0.38-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-CatalystX-REPL
perl-CatalystX-REPL has broken dependencies in the rawhide tree: On x86_64: perl-CatalystX-REPL-0.04-10.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-CatalystX-REPL-0.04-10.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-CatalystX-REPL-0.04-10.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Test-Apocalypse
perl-Test-Apocalypse has broken dependencies in the rawhide tree: On x86_64: perl-Test-Apocalypse-1.006-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On i386: perl-Test-Apocalypse-1.006-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On armhfp: perl-Test-Apocalypse-1.006-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Gtk3-WebKit
perl-Gtk3-WebKit has broken dependencies in the rawhide tree: On x86_64: perl-Gtk3-WebKit-0.06-3.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Gtk3-WebKit-0.06-3.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Gtk3-WebKit-0.06-3.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Devel-Cover
perl-Devel-Cover has broken dependencies in the rawhide tree: On x86_64: perl-Devel-Cover-1.18-1.fc23.x86_64 requires perl(:MODULE_COMPAT_5.20.2) perl-Devel-Cover-1.18-1.fc23.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Devel-Cover-1.18-1.fc23.i686 requires perl(:MODULE_COMPAT_5.20.2) perl-Devel-Cover-1.18-1.fc23.i686 requires libperl.so.5.20 On armhfp: perl-Devel-Cover-1.18-1.fc23.armv7hl requires perl(:MODULE_COMPAT_5.20.2) perl-Devel-Cover-1.18-1.fc23.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: FESCO Elections - June 2015 - Results
On Seg, 2015-06-29 at 13:47 +0100, Tom Hughes wrote: On 29/06/15 12:00, Josh Boyer wrote: On Mon, Jun 29, 2015 at 3:50 AM, Jan Kurik jku...@redhat.com wrote: Greetings, all! The elections for FESCo - June 2015 have concluded, and the results are shown below. FESCo is electing 4 seats this time. A total of 90 ballots were cast, meaning a candidate could accumulate up to 540 votes (90 * 6). 90 ballots? I believe that is one of the all time low records on voter turnout. Probably not surprising given the silly way the election was announced... It certainly disenfranchised me. The problem you see is that the announcement was sent out on 20th June, but you couldn't actually vote then, because voting didn't open until the 22nd. So you couldn't just go and vote when you got the announcement but instead you had to remember to do so a few days later. Needless to say I forgot all about it until I saw, somewhat to my surprise, the result email this morning. +1 , Tom Hughes describe exactly what happens to me. Conclusion, subject of announcement should change from: Voting starts on Monday bla bla bla to : Vote now ! :) Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction: Jie Kang
Hello, As suggested in the packaging guide [0], I'm here to introduce myself! I'm Jie, currently working as a software engineering intern on the Java team at RedHat. Most of my work is on Thermostat [1], a instrumentation tool for the Hotspot JVM and Icedtea-Web [2], a browser plugin for Java applets and an implementation of Java Webstart. I'm a Computer Science student at the University of Toronto (Canada) and am aiming to finish in 2016. For packaging work, I am hoping to maintain two packages [3, 4] in Fedora for use in Thermostat. In terms of past experience, I have tinkered with Thermostat's packaging for Fedora, working on getting a usable spec/rpm for source from the HEAD repository and I have also submitted a tiny patch to kxml [5], adding OSGi metadata to the package. Cheers! [0] http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Introduce_yourself [1] http://icedtea.classpath.org/thermostat/ [2] http://icedtea.classpath.org/wiki/IcedTea-Web [3] https://bugzilla.redhat.com/show_bug.cgi?id=1230867 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1230874 [5] https://bugzilla.redhat.com/show_bug.cgi?id=1232478 -- Jie Kang Java Team - Software Engineering Intern -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1238625] kwrite is missing in Component list at https://bugzilla.redhat.com for 'Product: Fedora'
https://bugzilla.redhat.com/show_bug.cgi?id=1238625 Rex Dieter rdie...@math.unl.edu changed: What|Removed |Added Status|NEW |CLOSED CC||rdie...@math.unl.edu Resolution|--- |NOTABUG Last Closed||2015-07-02 09:02:32 --- Comment #2 from Rex Dieter rdie...@math.unl.edu --- yep, notabug, triaging other bug against kate now. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: dnssec-trigger + GNOME + NetworkManager integration
On Thu, Jul 2, 2015 at 2:33 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.07.2015 um 02:30 schrieb Michael Catanzaro: On Wed, 2015-07-01 at 19:59 -0400, Paul Wouters wrote: Principles are good and well. But how many times did you actually USE that option you so reluctantly implemented? :) Actually, I honestly don't remember ever using it except testing it during development. I just don't visit broken sites. They are few and far between nowadays that's nonsense a self signed certificate is exactly as secure as a CA certificate you pay for after there are hundrets and thousands by default trusted CA's in the browsers with the only difference you have to accept it once No its not. Because everyone can issue them you can't really know whether it is from who it claims to be from ... even in case you can its in case an attacker gains access of it the issuer can't really revoke it anymore. Browsers do show those warnings for self signed certs for a reason and that reason is *not* to sell certificates. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Driver 'mmcblk' needs updating - please use bus_type methods
- Original Message - Il giorno mar, 30/06/2015 alle 06.13 -0400, Bastien Nocera ha scritto: It doesn't need updating, the error you're seeing is: DMA: Out of SW-IOMMU space for 65536 bytes at device :09:00.1 Which I reported upstream here: http://thread.gmane.org/gmane.linux.kernel.mmc/32629 but which didn't get any answers. You can test the work-around there though. Thanks Bastien, where I can find the work around for test it? In the mail I linked to. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mass bug filing proposal - switching to Python3
- Original Message - From: Miroslav Suchý msu...@redhat.com To: devel@lists.fedoraproject.org Sent: Thursday, July 2, 2015 11:30:22 AM Subject: Re: Mass bug filing proposal - switching to Python3 Dne 1.7.2015 v 15:33 Robert Kuska napsal(a): I would like to start with Mass bug filing process and as stated at wiki, the first step is to gain consensus for what I want to make. I maintain several python applications, but not all python libraries are available for python3 yet. Just few weeks ago I filed BZ please provide python3 subpackage for several libraries as the python3 subpackage neither exist yet nor it was reported yet. Can you rather file BZs for all python libraries which does not provide python3 library yet? And start filing application BZs only where all (or at least most) libraries will support python3. I believe Robert's point is that once a bug is filled on an application, it is the application's maintainer's obligation to file any additional bugs that may be needes (Please let me know, if I understand it incorrectly, Robert). That said, I tend to agree that filing against both all applications and modules may be preferable, since we want as many packages as possible to support Python 3. Matt For example absence of python3 support in ansible modules and python-openstackclient is real blocker for me. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Pre-nonresponsive maintainer request
On Wed, Jul 1, 2015 at 9:50 PM, Sérgio Basto ser...@serjux.com wrote: I agree , ask him that, please , he gave me commit permissions on packages gammu and wammu a while ago ... Just got a response from him overnight and he said he'd take a look at my bug. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
On Thu, Jul 02, 2015 at 04:04:37PM +0200, drago01 wrote: a self signed certificate is exactly as secure as a CA certificate you pay for after there are hundrets and thousands by default trusted CA's in the browsers with the only difference you have to accept it once No its not. Because everyone can issue them you can't really know whether it is from who it claims to be from ... even in case you can its in case an attacker gains access of it the issuer can't really revoke it anymore. Harald's point is that the trusted CAs are so numerous and so out of control that it's really hard to ascribe more trust to many of them than to a self-signed cert, yet there's no warning for these. You could theoretically inspect the cert manually and track down the issuer and so on, but I don't think very many people at all really do that. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1238494] perl-Inline-Filters-0.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1238494 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Inline-Filters-0.17-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/perl-Inline-Filters-0.17-1.fc22 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rubygem-apipie-rails license change
For rubygem-apipie-rails-0.3.4-1.fc23, the license was changed from MIT and ASL 2.0 and (MIT or GPLv2) to MIT and ASL 2.0 since the bundled jQuery was replaced by symlink to the system version of jQuery. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Minutes from Env-and-Stacks WG meeting (2015-07-02)
== #fedora-meeting-2: Env and Stacks (2015-07-02) == Meeting started by hhorak at 12:02:14 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-2/2015-07-02/env-and-stacks.2015-07-02-12.02.log.html . Meeting summary --- * init process (hhorak, 12:04:42) * New meeting time? (hhorak, 12:07:54) * jkaluza is fine with current time-slots, so we don't need to find new time-slots for meeting (hhorak, 12:10:23) * Elections wrap-up (hhorak, 12:11:01) * Changes in governance charter (hhorak, 12:15:56) * LINK: https://fedoraproject.org/wiki/Env_and_Stacks/Governance_Charter (hhorak, 12:16:10) * ACTION: all to reflect on the Governance Charter and propose changes on ML if there is anything worth changin (hhorak, 12:22:42) * Fedora users feedback (hhorak, 12:26:52) * LINK: http://piratepad.net/env-and-stacks-users-feedback (hhorak, 12:27:36) * LINK: https://fedorahosted.org/council/ticket/26 (hhorak, 12:32:47) * LINK: https://www.limesurvey.org/en/ (hhorak, 12:44:56) * limesurvey.org is the default open source option (hhorak, 12:45:13) * other not so open source are: https://www.keysurvey.com/ https://www.google.com/forms https://www.surveymonkey.com/ (hhorak, 12:46:59) * ACTION: hhorak to ask other wgs about what are their plans for feedback gathering (hhorak, 13:10:56) * ACTION: langdon to ask council about whether the recurring questions would make sense (hhorak, 13:13:11) * open floor (hhorak, 13:13:49) * LINK: https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-May/000786.html (hhorak, 13:22:00) * ACTION: all to think about update on our area's progress and goals for f23 and f24.. send it to ML until this Monday, 10 EST, if it should be mentioned on the council meeting.. (hhorak, 13:29:50) Meeting ended at 13:33:04 UTC. Action Items * all to reflect on the Governance Charter and propose changes on ML if there is anything worth changin * hhorak to ask other wgs about what are their plans for feedback gathering * langdon to ask council about whether the recurring questions would make sense * all to think about update on our area's progress and goals for f23 and f24.. send it to ML until this Monday, 10 EST, if it should be mentioned on the council meeting.. Action Items, by person --- * hhorak * hhorak to ask other wgs about what are their plans for feedback gathering * langdon * langdon to ask council about whether the recurring questions would make sense * **UNASSIGNED** * all to reflect on the Governance Charter and propose changes on ML if there is anything worth changin * all to think about update on our area's progress and goals for f23 and f24.. send it to ML until this Monday, 10 EST, if it should be mentioned on the council meeting.. People Present (lines said) --- * hhorak (70) * ncoghlan (39) * jkaluza (25) * langdon (15) * phracek (7) * zodbot (5) * ttomecek (1) * jzeleny_ (1) * handsome_pirate (1) * ttomecek1 (1) * bkabrda (0) * vpavlin (0) * juhp (0) * walters (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
Am 02.07.2015 um 16:04 schrieb drago01: On Thu, Jul 2, 2015 at 2:33 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.07.2015 um 02:30 schrieb Michael Catanzaro: On Wed, 2015-07-01 at 19:59 -0400, Paul Wouters wrote: Principles are good and well. But how many times did you actually USE that option you so reluctantly implemented? :) Actually, I honestly don't remember ever using it except testing it during development. I just don't visit broken sites. They are few and far between nowadays that's nonsense a self signed certificate is exactly as secure as a CA certificate you pay for after there are hundrets and thousands by default trusted CA's in the browsers with the only difference you have to accept it once No its not. Because everyone can issue them you can't really know whether it is from who it claims to be from ... even in case you can its in case an attacker gains access of it the issuer can't really revoke it anymore. Browsers do show those warnings for self signed certs for a reason and that reason is *not* to sell certificates *lol* and with a CA certificate you can? given that there are thousands of CA's and you need *only one* with a broken verfication process to get a certificate for whatever you want you can't and if you would read IT news you would know that the CA system is broken by design signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20150702 changes
Compose started at Thu Jul 2 05:15:03 UTC 2015 Broken deps for i386 -- [airsched] airsched-1.00.0-12.fc23.i686 requires libzmq.so.4 [apache-scout] apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws) apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:juddi-client) [aws] aws-tools-2015-2.fc23.i686 requires libaws_ssl.so [bluetile] bluetile-0.6-28.fc23.i686 requires ghc(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a) [bustle] bustle-0.4.8-3.fc23.i686 requires libHSsetlocale-1.0.0.1-ghc7.8.4.so bustle-0.4.8-3.fc23.i686 requires ghc(setlocale-1.0.0.1-5b5a3b6eb589586826a90a4c287ca0e0) bustle-0.4.8-3.fc23.i686 requires ghc(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a) [clearsilver] perl-clearsilver-0.10.5-29.fc22.i686 requires perl(:MODULE_COMPAT_5.20.1) perl-clearsilver-0.10.5-29.fc22.i686 requires libperl.so.5.20 [gammaray] gammaray-qt5-2.2.1-10.fc23.i686 requires qt5-qtbase(x86-32) = 0:5.4.2 [ghc-gtk] ghc-gtk-0.13.4-1.fc22.i686 requires ghc(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a) ghc-gtk-devel-0.13.4-1.fc22.i686 requires ghc-devel(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a) [ghc-hgettext] ghc-hgettext-0.1.30-8.fc23.i686 requires libHSsetlocale-1.0.0.1-ghc7.8.4.so ghc-hgettext-0.1.30-8.fc23.i686 requires ghc(setlocale-1.0.0.1-5b5a3b6eb589586826a90a4c287ca0e0) ghc-hgettext-devel-0.1.30-8.fc23.i686 requires libHSsetlocale-1.0.0.1-ghc7.8.4.so ghc-hgettext-devel-0.1.30-8.fc23.i686 requires ghc-devel(setlocale-1.0.0.1-5b5a3b6eb589586826a90a4c287ca0e0) ghc-hgettext-devel-0.1.30-8.fc23.i686 requires ghc(setlocale-1.0.0.1-5b5a3b6eb589586826a90a4c287ca0e0) [ghc-hjsmin] ghc-hjsmin-0.1.4.7-7.fc23.i686 requires ghc(language-javascript-0.5.13-0b8335d6a2507ee73f3b41c61a1ea2bf) ghc-hjsmin-devel-0.1.4.7-7.fc23.i686 requires ghc-devel(language-javascript-0.5.13-0b8335d6a2507ee73f3b41c61a1ea2bf) [golang-github-samalba-dockerclient] golang-github-samalba-dockerclient-devel-0-0.1.gitc37a52f.fc23.noarch requires golang(github.com/docker/docker/utils) golang-github-samalba-dockerclient-devel-0-0.1.gitc37a52f.fc23.noarch requires golang(github.com/docker/docker/pkg/timeutils) golang-github-samalba-dockerclient-devel-0-0.1.gitc37a52f.fc23.noarch requires golang(github.com/docker/docker/pkg/stdcopy) golang-github-samalba-dockerclient-devel-0-0.1.gitc37a52f.fc23.noarch requires golang(github.com/docker/docker/pkg/jsonlog) [hadoop] hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-servlet) hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-mapreduce-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-mapreduce-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-servlet) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-client) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-client) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) [hbase] hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core) [julia] julia-0.3.7-2.fc23.i686 requires libspqr.so.1 julia-0.3.7-2.fc23.i686 requires libLLVM-3.5.so julia-devel-0.3.7-2.fc23.i686 requires libLLVM-3.5.so [klavaro]
Heads up: soname bump of armadillo in rawhide
I will update a belated bump of armadillo (that happened in May) in rawhide. # dnf repoquery --disablerepo=* --enablerepo=rawhide --whatrequires 'libarmadillo.so.4()(64bit)' armadillo-devel-0:4.650.2-3.fc23.x86_64 gdal-0:1.11.2-10.fc23.x86_64 gdal-java-0:1.11.2-10.fc23.x86_64 gdal-libs-0:1.11.2-10.fc23.x86_64 gdal-perl-0:1.11.2-10.fc23.x86_64 mlpack-0:1.0.11-4.fc23.x86_64 mlpack-bin-0:1.0.11-4.fc23.x86_64 I will take care of rebuilding both gdal and mlpack. After some time I intend to proceed with the same updates to Fedora 22 and 21 (as it has happened in previous releases) taking care of the update details. Regards, -- José Abílio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
- Original Message - snip *lol* and with a CA certificate you can? A lot of us are sick of this type of attitude on fedora-devel, to the point where we don't actually care what you think anymore. Take this as an opportunity to read instead of jumping at people's throat with an attitude that wouldn't be tolerated in any other setting. /the silent majority -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Investigation of the F23 mass rebuild
On 2 July 2015 at 15:49, Adam Jackson a...@redhat.com wrote: Following up on the hardened cflags change in F23, I wanted to gather some statistics on the actual impact: what the most impacted packages and apps are, what the typical overhead is like, etc. The results are... unpleasant, [snip] Impressive data mining.. for those following along for educational purposes, care to share the scripts you used for this someplace? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2015-07-01)
On Thu, 2015-07-02 at 09:55 +0200, Tomas Hozza wrote: * AGREED: Netizen is not approved as spin. We approve the option to have netizen as optional suite in anaconda. Please work with Workstation WG. (+7, 0, -0) (thozza, 18:48:50) Hi, maybe there was some misunderstanding about the Workstation installer, but we don't allow configuration of package selection. Users are expected to use GNOME Software once the system is up and running. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2015-07-01)
On Thu, 2015-07-02 at 10:33 -0500, Michael Catanzaro wrote: On Thu, 2015-07-02 at 09:55 +0200, Tomas Hozza wrote: * AGREED: Netizen is not approved as spin. We approve the option to have netizen as optional suite in anaconda. Please work with Workstation WG. (+7, 0, -0) (thozza, 18:48:50) Hi, maybe there was some misunderstanding about the Workstation installer, but we don't allow configuration of package selection. Users are expected to use GNOME Software once the system is up and running. There were two combined statements there. The first was that we would consider making certain netizen-oriented options available at install -time. The second is that we would prefer to see tooling and configuration done inside the Workstation, KDE (and other?) environments rather than as a separate spin. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Investigation of the F23 mass rebuild
Following up on the hardened cflags change in F23, I wanted to gather
some statistics on the actual impact: what the most impacted packages
and apps are, what the typical overhead is like, etc. The results
are... unpleasant, but not so much because of the hardening change
itself. I started by grabbing the x86_64 packages of everything koji
believes is in F23, unpacking them all, and then removing every file
that wasn't a dynamic ELF object. From this set, some observations.
Of something like 14785 (binary) packages containing dynamic ELF
objects, 541 have not successfully built in F23, which you can tell
because their dist tag is wrong. This includes 443 from F22, 47 from
F21, 44 from F20 (!) and 7 from F19 (!!). Many of these seem to be from
gcc getting increasingly strict about what qualifies as legal C++. Most
of these are fairly low impact for most systems, but it is worrying
that these failures are sticking around for so long.
Of approximately 56000 packaged dynamic ELF objects, around 16000 are
still not linked with -z now. Of these, 7 are from F19 builds, 95 from
F20, 248 from F21, and 3987 from F22, and the remaining 12037 from F23.
Those 12037 binaries from successful f23 builds (not necessarily from
builds with the hardening change in place) come from 3038 binary
packages. 2041 of those packages provide exactly one non-now binary;
this is somewhat expected given our library packaging guidelines, but
it means it's probably going to be difficult to make big dents in the
problem.
There are 173 non-now binaries installed under /usr/share. 68 of those
are ircd-ratbox, and 56 are rubygem-gherkin. 7 are aircrack-ng, which
installs them into freaking /usr/share/doc! Come on, people.
There are 1378 non-now libraries directly under /usr/lib64 (presumably
just %{_libdir} really). Of these, probably most worrying (according to
my personal sense of outrage) are from: boost-*, bzip2-libs, cups-libs,
evolution-data-server, festival, fftw, giflib, gnutls, libdb and
libdb4, libgo, libicu, libpurple, libselinux, nspr, nss, openssl-libs,
postgresql-libs, rpm-build-libs and rpm-libs, sendmail-milter, tog
-pegasus-libs, unixODBC, xen-libs, xmlrpc-c, and zlib.
There are 5223 non-now binaries in /usr/bin or /usr/sbin. Most of these
are instances of binutils or gcc for various targets; I think it might be nice
to fix that, but not urgent for security. Outside that, of
packages not mentioned in the libs paragraph above, the most worrying
include: aircrack-ng, amanda, aoetools, bogofilter, ceph, clamav,
crypto-utils, docker, exim, keyutils, lsof, mimedefang, nacl, nfs
-utils, perl, spamassassin, wget, and wireshark.
There are 16615 executables in /usr/bin and /usr/sbin. Of these, 5166
are not PIEs.
---
At this point I gave up trying to get real metrics on the impact of
hardening, because it's clear it's not been done. Since the change was
done by changing the rpm build macros, I think we can conclude that the
build macros aren't being applied. Granted, packages can disable the
hardened build macros, but the packages I've called out above aren't
trying to disable them, or at least not doing so with %undefine.
Beyond that, the fact that we have such blatant packaging errors, and
that nearly 4% of our binary packages haven't rebuilt in F23, is quite
worrisome.
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
Am 02.07.2015 um 16:33 schrieb Bastien Nocera: - Original Message - snip *lol* and with a CA certificate you can? A lot of us are sick of this type of attitude on fedora-devel, to the point where we don't actually care what you think anymore. Take this as an opportunity to read instead of jumping at people's throat with an attitude that wouldn't be tolerated in any other setting. /the silent majority this type of attitude? everybody who reads IT news over the past years about CA's issued certificates even for Google knows that a CA signed certificate does not prove anything - the real problem is wehn this happens for Google somebody takes notice and the press writes about it if the same happens for your domain nobody will recognize it signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
Am 02.07.2015 um 16:16 schrieb Reindl Harald: Am 02.07.2015 um 16:04 schrieb drago01: On Thu, Jul 2, 2015 at 2:33 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.07.2015 um 02:30 schrieb Michael Catanzaro: On Wed, 2015-07-01 at 19:59 -0400, Paul Wouters wrote: Principles are good and well. But how many times did you actually USE that option you so reluctantly implemented? :) Actually, I honestly don't remember ever using it except testing it during development. I just don't visit broken sites. They are few and far between nowadays that's nonsense a self signed certificate is exactly as secure as a CA certificate you pay for after there are hundrets and thousands by default trusted CA's in the browsers with the only difference you have to accept it once No its not. Because everyone can issue them you can't really know whether it is from who it claims to be from ... even in case you can its in case an attacker gains access of it the issuer can't really revoke it anymore. Browsers do show those warnings for self signed certs for a reason and that reason is *not* to sell certificates *lol* and with a CA certificate you can? given that there are thousands of CA's and you need *only one* with a broken verfication process to get a certificate for whatever you want you can't and if you would read IT news you would know that the CA system is broken by design and for can't really revoke it anymore: please inform yourself and you know that you in reality can't revoke a cert because all the mechs are broken, not mandatory in the clients and if they would be mandatory the OCSP servers would be target number 1 for DOS attacks signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Investigation of the F23 mass rebuild
On Thu, Jul 02, 2015 at 10:49:37AM -0400, Adam Jackson wrote: Beyond that, the fact that we have such blatant packaging errors, and that nearly 4% of our binary packages haven't rebuilt in F23, is quite worrisome. I agree. What can and should we do about it? -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnssec-trigger + GNOME + NetworkManager integration
In any case, this is drifting significantly off-topic. Anyone interested in continuing it further, please use other venues. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Pre-nonresponsive maintainer request
On Wed, 2015-07-01 at 21:33 -0500, Richard Shaw wrote: I haven't gone through all the requirements but it seems pretty clear that brasero is unmaintained. FWIW, it's unmaintained upstream as well. If anyone is looking for a GNOME package to take care of -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[389-devel] Please review: [389 Project] #48214: ldapsearch on nsslapd-maxbersize returns 0 instead of current value
https://fedorahosted.org/389/ticket/48214 https://fedorahosted.org/389/attachment/ticket/48214/0001-Ticket-48214-ldapsearch-on-nsslapd-maxbersize-return.patch https://fedorahosted.org/389/attachment/ticket/48214/0002-Ticket-48214-CI-test-added-test-cases-for-ticket-482.patch git patch file (master) -- CI test -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[Bug 1238898] New: perl-PPIx-Regexp-0.041 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1238898 Bug ID: 1238898 Summary: perl-PPIx-Regexp-0.041 is available Product: Fedora Version: rawhide Component: perl-PPIx-Regexp Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.041 Current version/release in rawhide: 0.040-3.fc23 URL: http://search.cpan.org/dist/PPIx-Regexp/ 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. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1238898] perl-PPIx-Regexp-0.041 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1238898 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Created attachment 1045696 -- https://bugzilla.redhat.com/attachment.cgi?id=1045696action=edit [patch] Update to 0.041 (#1238898) -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1238898] perl-PPIx-Regexp-0.041 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1238898 --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Scratch build succeeded http://koji.fedoraproject.org/koji/taskinfo?taskID=10275996 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
New app: testdays
Hey folks, just wanted to post a quick heads-up that I wrote a little app which is to Test Day pages as relval is to release validation pages. It's called 'testdays', and you can read about it at https://www.happyassassin.net/testdays , and download it from the wikitcms/relval repository. Right now all it does is statistics, though I might look at page creation and result reporting at some point later if I get time. Mike may find it useful for Heroes of Fedora posts (it can give you the top testers for a given set of Test Day pages, e.g. all the Test Day pages for a given release), and it may also be useful to those running Test Days for doing a post-event report. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Do appdata files installed by a package do anything?
On Fri, Jul 3, 2015 at 10:35 AM, Richard Shaw hobbes1...@gmail.com wrote: Subject pretty much says it all... I have an appdata file from upstream that I think has a bad screenshot URL, how do I test this? You can either ask upstream to fix that, or disable that screenshot for a while(make sure there are still other shots) Yours sincerely, Christopher Meng http://cicku.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[EPEL-devel] [Fedocal] Reminder meeting : EPSCo weekly meeting
Dear all, You are kindly invited to the meeting: EPSCo weekly meeting on 2015-07-03 from 17:00:00 to 18:00:00 UTC At e...@irc.freenode.net The meeting will be about: Source: https://apps.fedoraproject.org/calendar/meeting/2542/ ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Do appdata files installed by a package do anything?
On Fri, Jul 3, 2015 at 1:29 PM, Florian Weimer fwei...@redhat.com wrote: Which “that”? The file (with a different URL) or the bad URL itself (to make it not bad)? 'That' should be 'that 404 problem'. or disable that screenshot for a while(make sure there are still other shots) Any file change would be invisible until the appstream-data package contents is regenerated, right? I suspect that's what causes testing challenges. I'm not sure about the policy of modifying the appdata file, should a package carry file deriving from downstream with correct contents however or just keep the error. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Do appdata files installed by a package do anything?
Subject pretty much says it all... I have an appdata file from upstream that I think has a bad screenshot URL, how do I test this? I tried changing the file installed by the package but of course it didn't do much. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Do appdata files installed by a package do anything?
On 07/03/2015 06:45 AM, Christopher Meng wrote: On Fri, Jul 3, 2015 at 10:35 AM, Richard Shaw hobbes1...@gmail.com wrote: Subject pretty much says it all... I have an appdata file from upstream that I think has a bad screenshot URL, how do I test this? You can either ask upstream to fix that, Which “that”? The file (with a different URL) or the bad URL itself (to make it not bad)? or disable that screenshot for a while(make sure there are still other shots) Any file change would be invisible until the appstream-data package contents is regenerated, right? I suspect that's what causes testing challenges. -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
libax25 update coming to rawhide (at least)
I just took over maintainership of libax25 and ax25-tools and I am working on an update. The update is only from rc2 to rc4 but abi-compliance checker shows it as an incompatible update: https://dl.dropboxusercontent.com/u/34775202/compat_reports/libax25/0.0.12.rc2_to_0.0.12.rc4/compat_report.html Can someone with better C/C++ knowledge let me know if it definitely looks like an ABI breaking update? Here are the packages I found that are affected (from my f21 install): $ repoquery --whatrequires --resolve $(rpm -qp --provides rpmbuild/libax25/RPMS/x86_64/libax25-0.0.12-0.10.rc4.fc21.x86_64.rpm) | sort | uniq aprsd-0:2.2.5-15.6.fc21.9.x86_64 aprsdigi-0:3.5.1-4.fc21.x86_64 ax25-apps-0:0.0.6-19.fc21.x86_64 ax25-tools-0:0.0.10-0.12.rc2.fc21.x86_64 ax25-tools-0:0.0.10-0.9.rc2.fc21.x86_64 ax25-tools-x-0:0.0.10-0.12.rc2.fc21.x86_64 ax25-tools-x-0:0.0.10-0.9.rc2.fc21.x86_64 fbb-0:7.0.8-0.3.beta.fc21.x86_64 fbb-gui-0:7.0.8-0.3.beta.fc21.x86_64 libax25-devel-0:0.0.12-0.8.rc2.fc21.i686 libax25-devel-0:0.0.12-0.8.rc2.fc21.x86_64 node-0:0.3.2-16.fc21.x86_64 uronode-0:2.3.1-4.fc21.x86_64 xastir-1:2.0.4-8.fc21.x86_64 Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1235709] variant test fails on big endian arches
https://bugzilla.redhat.com/show_bug.cgi?id=1235709 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- Package perl-Glib-1.310-2.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Glib-1.310-2.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-11014/perl-Glib-1.310-2.fc22 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Orphaning apache-poi
HI I have intention to orphaning apache-poi [1] , because, it, for build, use resources with unknow license [2]. I tried to contact several time the developer/s [3] of these files but without succes. regards gil [1] https://admin.fedoraproject.org/pkgdb/package/apache-poi/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1146670#c13 [3] http://www.etsi.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Investigation of the F23 mass rebuild
On Thu, 2015-07-02 at 11:09 -0400, Matthew Miller wrote: On Thu, Jul 02, 2015 at 10:49:37AM -0400, Adam Jackson wrote: Beyond that, the fact that we have such blatant packaging errors, and that nearly 4% of our binary packages haven't rebuilt in F23, is quite worrisome. I agree. What can and should we do about it? Good question. I'm not entirely sure, but I have opinions. The binaries-in-/usr/share/doc thing is the sort of clearly obviously wrong thing that, ideally, would get your build rejected. I would have hoped AutoQA or similar would be sufficiently potent for this by now. The longstanding FTBFS thing is harder. In principle we do actually retire things that haven't built for multiple releases; in practice, things apparently get missed. pathfinder logiweb and python-rpi-gpio, for example, were all on the chopping block for F21: https://lists.fedoraproject.org/pipermail/devel/2014-June/199524.html Though all mysteriously disappeared from the final warning: https://lists.fedoraproject.org/pipermail/devel/2014-July/200694.html I don't see anything in any related thread to indicate they were repaired, so, who knows. They're all still present in F23, all not successfully rebuilt since F19. Apparently for F22 we only retired packages with broken dependencies, and didn't consider long-term FTBFS: https://lists.fedoraproject.org/pipermail/devel/2015-April/210208.html I'm not sure that was intentional. We should be consistent. People were notified of the F23 mass rebuild failures, in a sense: https://lists.fedoraproject.org/pipermail/devel/2015-June/211496.html If I'd seen that, I might have clicked through. If I'd seen the list in the email itself - like in the retirement notices above - I'd have been more likely to read the results. Common to all of this is a certain reactive posture. There's not a dashboard view of sick packages. Which could be useful along a number of axes, really. How far behind is a package relative to its upstream's releases? For a given sick package, how many packages depend on it? How idle has pkg git been relative to the incoming bug rate for a package? The data exists, but we're not looking at it. Obviously not all metrics are going to be comparable across packages, maybe for the kernel we want more of a moving average than a raw counter. It's also worth remembering that the more developers we have, the fewer are generalists. Clearly we don't have someone routinely inspecting packages to ensure CFLAGS is set properly, for example. More to the point, when we do have systemic issues, we don't have people able or willing to dive into arbitrary packages and fix them, and we certainly don't have anyone _tasked_ with that. When we do make systemwide changes like this, we don't have known points of contact for the resulting bugs, or we don't communicate them well. The gnutls spec, for example, claims to support building with the hardened flags in the changelog, but also says this just before % configure: # this overrides the -znow from hardened builds. CFLAGS=$RPM_OPT_FLAGS -Wl,-z,lazy export CFLAGS I mean, yes, it's honest, that does in fact override -z now. It also _completely defeats the purpose_ of the hardened flags. A proper fix could have been to apply that workaround only to the guile modules that (apparently) need it. But who would the maintainer have asked for advice about that? In some sense the answer is fesco, who approved the change and know who is involved with it, but well, I'm on fesco, and this never came up there. (The hardening change did, the gnutls thing did not.) - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Investigation of the F23 mass rebuild
On Thu, 2015-07-02 at 16:24 +0100, Jonathan Underwood wrote:
On 2 July 2015 at 15:49, Adam Jackson a...@redhat.com wrote:
Following up on the hardened cflags change in F23, I wanted to gather
some statistics on the actual impact: what the most impacted packages
and apps are, what the typical overhead is like, etc. The results
are... unpleasant,
[snip]
Impressive data mining.. for those following along for educational
purposes, care to share the scripts you used for this someplace?
I didn't really write down the shell pipelines I used as scripts up
front. But it was something along the lines of:
# grab stuff from rawhide
% koji -q list-tagged-pkgs f23 | awk '{ print $1 }' | \
xargs -n1 -P4 koji download-build --arch x86_64
# unpack
% echo *.rpm | xargs -n1 -P4 rpmdev-extract
# grind away everything that isn't an elf file
% cat elf-p
#!/bin/sh
file -b $1 | grep -q ELF
^D
% chmod u+x elf-p
% find . -type f \( -exec elf-p {} \; -o -delete \)
# nuke everything that's not a dynamic ELF object
% find . -name \*.o -delete
# Check if a binary was not linked with -z now
% find . -type f | while read i ; do
eu-readelf -d $i | grep -q BIND_NOW || echo $i
done
# Find the ten packages with the most non-now objects
% !! | cut -f1 -d/ | sort | uniq -c | sort -nk1 | tail -10
etc. I'm getting the details wrong there regarding paths containing
spaces, but it turns out there are any elf files in such paths. Also
this is probably a lot faster if you trim each package as you unpack it
rather than force it all out to disk.
What I _am_ going to need to really write is some tools to inspect
entire loaded object trees for relocation cost and useless linkage, at
which point shell is clearly the wrong language to be using.
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1238804] New: /usr/bin/perl is not linked with -z now
https://bugzilla.redhat.com/show_bug.cgi?id=1238804 Bug ID: 1238804 Summary: /usr/bin/perl is not linked with -z now Product: Fedora Version: rawhide Component: perl Assignee: jples...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, iarn...@gmail.com, jples...@redhat.com, ka...@ucw.cz, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com, rc040...@freenet.de, tcall...@redhat.com /usr/bin/perl is not linked with -z now. The -z now is defined by -specs=/usr/lib/rpm/redhat/redhat-hardened-ld: gcc -o libperl.so -shared -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/usr/local/lib -Wl,-soname -Wl,libperl.so.5.22 op.o perl.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o perldtrace.o DynaLoader.o -lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc Processing extracted/DCombiningClass.txt Processing extracted/DNumType.txt gcc -o perl -fstack-protector-strong -L/usr/local/lib -Wl,--enable-new-dtags perlmain.o libperl.so `cat ext.libs` -lpthread -lresolv -lnsl -ldl -lm -lcrypt -lutil -lc The reason is we configure perl as: /bin/sh Configure -des -Doptimize=$RPM_OPT_FLAGS \ -Dccdlflags=-Wl,--enable-new-dtags \ -Dlddlflags=-shared $RPM_OPT_FLAGS $RPM_LD_FLAGS \ The $RPM_LD_FLAGS should go into ccdlflags too. ccdlflags is for linking programs dynamycally, lddlflags if for linking libraries dynamically. Configure supports ldflags, but I worry this is has to be actively used by Makefile.PLs, so it is not much helpful. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1237123] perl-Encode-2.75 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1237123 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- Package perl-Encode-2.75-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Encode-2.75-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-10995/perl-Encode-2.75-1.fc21 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Summary/Minutes from today's FESCo Meeting (2015-07-01)
On Thu, 2015-07-02 at 09:56 -0600, Chris Murphy wrote: On Thu, Jul 2, 2015 at 9:45 AM, Stephen Gallagher sgall...@redhat.com wrote: On Thu, 2015-07-02 at 10:33 -0500, Michael Catanzaro wrote: On Thu, 2015-07-02 at 09:55 +0200, Tomas Hozza wrote: * AGREED: Netizen is not approved as spin. We approve the option to have netizen as optional suite in anaconda. Please work with Workstation WG. (+7, 0, -0) (thozza, 18:48:50) Hi, maybe there was some misunderstanding about the Workstation installer, but we don't allow configuration of package selection. Users are expected to use GNOME Software once the system is up and running. There were two combined statements there. The first was that we would consider making certain netizen-oriented options available at install -time. The second is that we would prefer to see tooling and configuration done inside the Workstation, KDE (and other?) environments rather than as a separate spin. The Workstation live installer doesn't have any installation options. The UI isn't even present in the installer. It's a single payload, all or nothing. It would have to be done as a group in GNOME Software. The Workstation network installer has installation options. Sorry, I failed to clarify sufficiently. The installer statement was Fedora-general, the latter statement was Workstation-specific. So yes, it would be an option for the network installer or other similar full -installer mechanisms. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Investigation of the F23 mass rebuild
On 2 July 2015 at 16:55, Adam Jackson a...@redhat.com wrote: On Thu, 2015-07-02 at 16:24 +0100, Jonathan Underwood wrote: On 2 July 2015 at 15:49, Adam Jackson a...@redhat.com wrote: Following up on the hardened cflags change in F23, I wanted to gather some statistics on the actual impact: what the most impacted packages and apps are, what the typical overhead is like, etc. The results are... unpleasant, [snip] Impressive data mining.. for those following along for educational purposes, care to share the scripts you used for this someplace? I didn't really write down the shell pipelines I used as scripts up front. But it was something along the lines of: [snip] Thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2015-07-01)
On Thu, Jul 2, 2015 at 9:45 AM, Stephen Gallagher sgall...@redhat.com wrote: On Thu, 2015-07-02 at 10:33 -0500, Michael Catanzaro wrote: On Thu, 2015-07-02 at 09:55 +0200, Tomas Hozza wrote: * AGREED: Netizen is not approved as spin. We approve the option to have netizen as optional suite in anaconda. Please work with Workstation WG. (+7, 0, -0) (thozza, 18:48:50) Hi, maybe there was some misunderstanding about the Workstation installer, but we don't allow configuration of package selection. Users are expected to use GNOME Software once the system is up and running. There were two combined statements there. The first was that we would consider making certain netizen-oriented options available at install -time. The second is that we would prefer to see tooling and configuration done inside the Workstation, KDE (and other?) environments rather than as a separate spin. The Workstation live installer doesn't have any installation options. The UI isn't even present in the installer. It's a single payload, all or nothing. It would have to be done as a group in GNOME Software. The Workstation network installer has installation options. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1238804] /usr/bin/perl is not linked with -z now
https://bugzilla.redhat.com/show_bug.cgi?id=1238804 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|jples...@redhat.com |ppi...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Investigation of the F23 mass rebuild
On Thu, Jul 02, 2015 at 01:47:11PM -0400, Adam Jackson wrote: I agree. What can and should we do about it? Good question. I'm not entirely sure, but I have opinions. That's a good start... we can build from there in to plans. The binaries-in-/usr/share/doc thing is the sort of clearly obviously wrong thing that, ideally, would get your build rejected. I would have hoped AutoQA or similar would be sufficiently potent for this by now. I think that it probably is powerful enough, but to my knowledge we haven't actually _enabled_ any sort of gating like this. [...] Common to all of this is a certain reactive posture. There's not a dashboard view of sick packages. Which could be useful along a number of axes, really. How far behind is a package relative to its upstream's releases? For a given sick package, how many packages depend on it? How idle has pkg git been relative to the incoming bug rate for a package? The data exists, but we're not looking at it. Obviously not all metrics are going to be comparable across packages, maybe for the kernel we want more of a moving average than a raw counter. That seems useful. Package Janitors' Dashboard or something. Hand-in-hand with reactive posture is our high wall, chaos-filled inside model for enforcing the packaging guidelines. Package review often consists of nitpicking with a fine-toothed comb, because except for very egregious situations, that's the only time package quality is ever looked at. This causes two undesirable situations: First, there's no way to let a good enough package in and have it progress to excellent — it must be excellent at the start, because we generally don't trust the package quality to do much but go down. That's not to say that many packagers *don't* improve the quality of the packages over time — I know I try to for the few I maintain whenever I notice something, and I know many others do too. But there's no regular mechanism for it, let alone accountability. Second, once something is in, it can actively get worse. I can get a package through package review 100% clean, and then the next day go and edit it to do all sorts of horrible things, and odds are really good that no one will call me on it. This generally isn't due to malice, but the rules are complicated and the guidelines long — it's easy for all but the most committed packagers to mess up simply by not being aware of the right way to handle a situation. It's also worth remembering that the more developers we have, the fewer are generalists. Clearly we don't have someone routinely inspecting packages to ensure CFLAGS is set properly, for example. More to the point, when we do have systemic issues, we don't have people able or willing to dive into arbitrary packages and fix them, and we certainly don't have anyone _tasked_ with that. Another example, not even considering fixing things that are broken: sometimes there are big improvements we can make based on upstream changes that just don't happen. Something that came up on the users' list a few months ago is systemd's service restart behavior. Our guidelines say: If you package a long-running service, please consider enabling systemd's automatic restart feature for it, to improve reliability by making sure the system automatically attempts recovering a failing daemon. and I'm pretty sure this would be the best setting for most daemons we ship. But, short of someone deciding to filing a change and signing up a proven packager or mass-filing bugs, there's no one who has the general responsibility of improving all the packages. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 21 updates broke support for 4K displays :(
Are there any Intel Haswell users with Chromium running having similar issues? On 2 July 2015 at 09:35, valent.turko...@gmail.com valent.turko...@gmail.com wrote: This album shows how badly this affects productivity when using Fedora as your main workstation: https://goo.gl/photos/d2EAXWTZQRVMsSSPA -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Investigation of the F23 mass rebuild
On Thu, Jul 02, 2015 at 10:49:37AM -0400, Adam Jackson wrote: Following up on the hardened cflags change in F23, I wanted to gather some statistics on the actual impact: what the most impacted packages and apps are, what the typical overhead is like, etc. The results are... unpleasant, but not so much because of the hardening change itself. I started by grabbing the x86_64 packages of everything koji believes is in F23, unpacking them all, and then removing every file that wasn't a dynamic ELF object. From this set, some observations. Thank you for this great analysis. Do you still have the executable files and can run checksec on them and publish the output somewhere? There are 173 non-now binaries installed under /usr/share. 68 of those are ircd-ratbox, and 56 are rubygem-gherkin. 7 are aircrack-ng, which installs them into freaking /usr/share/doc! Come on, people. The error in aircrack-ng resulted from accidently pacakaging binary files from a new test suite into the doc. Initially it contained mainly capture files to try some of the tools. Since the binaries are not normally used or required I guess this does not cause any real trouble. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Investigation of the F23 mass rebuild
On Thu, 2015-07-02 at 14:59 -0400, Matthew Miller wrote: First, there's no way to let a good enough package in and have it progress to excellent — it must be excellent at the start, because we generally don't trust the package quality to do much but go down. This is actually something I'd like to see addressed procedurally, with something more like the kernel's staging model. Bugzilla is a poor process tool, I'd much prefer to see a package staging tree that can feed (only) scratch builds to koji or copr, and have the git modules promoted to pkg git when they're review-clean. But, short of someone deciding to filing a change and signing up a proven packager or mass-filing bugs, there's no one who has the general responsibility of improving all the packages. Right. And I'm happy to NMU things that annoy me (and have started, for some of the issues I found in the first post), but it's not really my job, and it's not something we collectively encourage of each other. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Investigation of the F23 mass rebuild
On Thu, Jul 02, 2015 at 01:47:11PM -0400, Adam Jackson wrote: The longstanding FTBFS thing is harder. In principle we do actually retire things that haven't built for multiple releases; in practice, things apparently get missed. pathfinder logiweb and python-rpi-gpio, for example, were all on the chopping block for F21: https://lists.fedoraproject.org/pipermail/devel/2014-June/199524.html Though all mysteriously disappeared from the final warning: https://lists.fedoraproject.org/pipermail/devel/2014-July/200694.html IIRC they disappeared because I used the from cutoff date for F21 initially, i.e. only packages with a F18 disttag were removed back then. Apparently for F22 we only retired packages with broken dependencies, and didn't consider long-term FTBFS: https://lists.fedoraproject.org/pipermail/devel/2015-April/210208.html I'm not sure that was intentional. We should be consistent. This might have been skipped since there was no mass-rebuild for F22 or some bug in the reporting script. Common to all of this is a certain reactive posture. There's not a dashboard view of sick packages. Which could be useful along a number I would like to have this as well. There was a package status report ages ago when I joined Fedora done by someone who left the project. I still have the scripts if someone wants to work on them, but I never got to resurrect them. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to build one TeXLive subpackage for EPEL-7?
On 04/08/2015 02:12 AM, M. Edward (Ed) Borasky wrote: One reason I'm building my OSJourno Docker images on Fedora and not the more popular and theoretically more stable CentOS is that EPEL doesn't have a few LaTeX packages I need. Sometime when I run out of more pressing things to fix, I'm going to try texlive-texliveonfly to see if it can find and install missing LaTeX packages. Seriously, texlive is huge - if you install *everything* IIRC you have something like 4 GB just for texlive! So there's every reason to want to install a minimal texlive and install packages on an as-needed basis. And I'm curious why there are texlive packages in Fedora that aren't in EPEL - I assume it's a human or machine resource constraint. It's not that they aren't in EPEL, per se. It's that they aren't in RHEL7, as texlive is in RHEL7, and it is not as complete as the one in Fedora, for whatever reason. Bug have be filed and hopefully some things will be added in RHEL7.2 (specifically metapost): https://bugzilla.redhat.com/show_bug.cgi?id=1064453 https://bugzilla.redhat.com/show_bug.cgi?id=1198299 I'm sure that there are others, like: https://bugzilla.redhat.com/show_bug.cgi?id=1200172 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to build one TeXLive subpackage for EPEL-7?
On 04/08/2015 12:46 PM, Jonathan Underwood wrote:
I look at tl2pm and think it would be fairly easy to patch that to
spit out 4000 and something spec files rather than one 16 MB one. The
unresolved issues are whether doing that would invalidate the previous
license audit (it shouldn't really), and whether FESCO would grant a
package review exception for those packages.
This may be worth pursuing. Or rewriting it in python :)
While we're at it I think we need to revisit the version numbers. Currently
we have things like:
%global tl_version 2014
%global tl_rel 11
%global tl_release %{tl_rel}.%{source_date}%{?dist}
%global tl_noarch_release %{tl_rel}%{?dist}
%package aastex
Provides: tex-aastex = %{tl_version}
Version: svn15878.5.2
Release: %{tl_noarch_release}.1
Provides: tex(aastex.cls) = %{tl_version}
Provides: tex(aastex.sty) = %{tl_version}
This doesn't appear to comply with
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages
which I believe would imply:
Version: 5.2
Release: #.svn15878
The Provides version seems fairly arbitrary, but perhaps there is a reason for
it.
I've just spent the better part of two days packaging up a couple missing EL7
texlive packages for internal use, would be nice to get this fixed at the
distro level.
Also, it is completely maddening that upstream does not appear to provide
anything but the most current tarball for packages, e.g.:
Source0100:
ftp://ftp.ctex.org/mirrors/CTAN/systems/texlive/tlnet/archive/aastex.tar.xz
unless anyone is aware of anything else? Perhaps we should be building from
source:
https://www.tug.org/svn/texlive/trunk/Master/texmf-dist/source/latex/aastex/
or ctan?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
