[Bug 1181656] Please package perl-Apache-Session-Browseable into EPEL 5/6/7
https://bugzilla.redhat.com/show_bug.cgi?id=1181656 --- Comment #1 from Paul Howarth p...@city-fan.org --- I'm inclined not to package this for EPEL-5 because the sqlite/DBD::SQLite is so old it throws out loads of warnings when used: $ ./Build test t/Apache-Session-Browseable-DBI.ok t/Apache-Session-Browseable-Fileok t/Apache-Session-Browseable-LDAPok t/Apache-Session-Browseable-Redis...skipped all skipped: Optional modules (Redis) not installed t/Apache-Session-Browseable-SQLite..closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. ok t/Apache-Session-Browseable-Store-DBI...ok t/Apache-Session-Browseable-Store-MySQL.ok t/Apache-Session-Browseable-common..ok t/test-browseable-functions-using-SQLiteclosing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at /builddir/build/BUILD/Apache-Session-Browseable-1.0.2/blib/lib/Apache/Session/Browseable/Store/SQLite.pm line 95. closing dbh with active statement handles at
[perl-DateTime-TimeZone] Fix a basic regular expression when bootstrapping
commit 30a058855246c7d28d164015ab2feebfe84e28e0
Author: Petr Písař ppi...@redhat.com
Date: Fri Jan 16 10:48:19 2015 +0100
Fix a basic regular expression when bootstrapping
Old filters call sed -e. Thus it's a basic regualar expression. '?' is
not a metacharacter in basic expressions.
perl-DateTime-TimeZone.spec |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/perl-DateTime-TimeZone.spec b/perl-DateTime-TimeZone.spec
index 09fb897..5ceb54f 100644
--- a/perl-DateTime-TimeZone.spec
+++ b/perl-DateTime-TimeZone.spec
@@ -61,7 +61,7 @@ Requires: perl(DateTime::TimeZone::Tzfile)
%{?filter_setup:
%filter_from_requires /^perl(Win32/d
%if 0%{?perl_bootstrap}
-%filter_from_requires /^perl(DateTime\(::Duration\)?)/d
+%filter_from_requires /^perl(DateTime\(::Duration\)\{0,1\})/d
%endif
%?perl_default_filter}
--
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 1180918] yum install perl-IO-Socket-SSL.noarch demands openssl-libs 1.0.1j-1, but we are at already at 1.0.1k-1
https://bugzilla.redhat.com/show_bug.cgi?id=1180918 --- Comment #5 from Paul Howarth p...@city-fan.org --- openssl 1.0.1k was pushed to the F-21 stable updates repository earlier this week so this should no longer be an issue. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=cWOUeUV9uqa=cc_unsubscribe -- 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 1181656] Please package perl-Apache-Session-Browseable into EPEL 5/6/7
https://bugzilla.redhat.com/show_bug.cgi?id=1181656 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|NEW |ASSIGNED Depends On||1182960 --- Comment #2 from Paul Howarth p...@city-fan.org --- The DBD::SQLite issue was fixed in version 1.19_01; EL-5 has version 1.14 and EL-6 has version 1.27. It's only needed for the test suite though, so EL-5 will actually be OK. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1182960 [Bug 1182960] Review Request: perl-Apache-Session-Browseable - Add index and search methods to Apache::Session -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=jJJGVOBnK1a=cc_unsubscribe -- 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
[perl-Compress-Bzip2] Decrase bzip2-devel version constrain
commit a65d48edc09d019722553b72a7c9ed0587f1767d
Author: Petr Písař ppi...@redhat.com
Date: Fri Jan 16 12:23:46 2015 +0100
Decrase bzip2-devel version constrain
The unbundled bzip2 version is 1.0.6. I verified headers and tests
that 1.0.5 is compatible with 1.0.6. Therefore I lowered the version
constrain.
It's possible even older versions would work.
perl-Compress-Bzip2.spec |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/perl-Compress-Bzip2.spec b/perl-Compress-Bzip2.spec
index b2fd3c8..43f2d29 100644
--- a/perl-Compress-Bzip2.spec
+++ b/perl-Compress-Bzip2.spec
@@ -6,7 +6,7 @@ Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Compress-Bzip2/
Source0:
http://www.cpan.org/authors/id/R/RU/RURBAN/Compress-Bzip2-%{version}.tar.gz
-BuildRequires: bzip2-devel = 1.0.6
+BuildRequires: bzip2-devel = 1.0.5
BuildRequires: perl
BuildRequires: perl(Config)
BuildRequires: perl(File::Copy)
--
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
File YAML-LibYAML-0.57.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-YAML-LibYAML: 6ac5aa764d55395175d7c6f60e606ce0 YAML-LibYAML-0.57.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
[perl-YAML-LibYAML] Update to 0.57
commit c6d19a89b877f2eb7326130f127752d6e5099ef7
Author: Paul Howarth p...@city-fan.org
Date: Fri Jan 16 14:32:11 2015 +
Update to 0.57
- New upstream release 0.57
- Update copyright year
- Use Swim cpan-tail block functions in doc
- Format string fixes (PR#21, CPAN RT#46507, CVE-2012-1152)
- This release by NAWGLAN → update source URL
- Drop patch for format string fixes, upstreamed at long last
YAML-LibYAML-0.51-format-error.patch | 38 --
perl-YAML-LibYAML.spec | 22 +++
sources |2 +-
3 files changed, 14 insertions(+), 48 deletions(-)
---
diff --git a/perl-YAML-LibYAML.spec b/perl-YAML-LibYAML.spec
index 896060c..4d6d6c7 100644
--- a/perl-YAML-LibYAML.spec
+++ b/perl-YAML-LibYAML.spec
@@ -1,18 +1,15 @@
Name: perl-YAML-LibYAML
-Version:0.55
+Version:0.57
Release:1%{?dist}
Summary:Perl YAML Serialization using XS and libyaml
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/YAML-LibYAML/
-Source0:
http://search.cpan.org/CPAN/authors/id/I/IN/INGY/YAML-LibYAML-%{version}.tar.gz
-Patch0: YAML-LibYAML-0.51-format-error.patch
+Source0:
http://search.cpan.org/CPAN/authors/id/N/NA/NAWGLAN/YAML-LibYAML-%{version}.tar.gz
# Install
BuildRequires: perl
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
-BuildRequires: perl(File::Find)
-BuildRequires: perl(File::Path)
+BuildRequires: perl(ExtUtils::MakeMaker)
# Module
BuildRequires: perl = 3:5.8.3
@@ -29,6 +26,8 @@ BuildRequires: libyaml, libyaml-devel
BuildRequires: perl(Carp)
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Devel::Peek)
+BuildRequires: perl(File::Find)
+BuildRequires: perl(File::Path)
BuildRequires: perl(Filter::Util::Call)
BuildRequires: perl(lib)
BuildRequires: perl(Scalar::Util)
@@ -52,9 +51,6 @@ bound to Python and was later bound to Ruby.
%prep
%setup -q -n YAML-LibYAML-%{version}
-# Fix format string vulnerabilities (CVE-2012-1152, CPAN RT#46507)
-%patch0
-
%build
perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags}
make %{?_smp_mflags}
@@ -78,6 +74,14 @@ make test
%{_mandir}/man3/YAML::XS::LibYAML.3*
%changelog
+* Fri Jan 16 2015 Paul Howarth p...@city-fan.org - 0.57-1
+- Update to 0.57
+ - Update copyright year
+ - Use Swim cpan-tail block functions in doc
+ - Format string fixes (PR#21, CPAN RT#46507, CVE-2012-1152)
+- This release by NAWGLAN → update source URL
+- Drop patch for format string fixes, upstreamed at long last
+
* Wed Dec 24 2014 Paul Howarth p...@city-fan.org - 0.55-1
- Update to 0.55
- Get YAML::XS using latest libyaml
diff --git a/sources b/sources
index 06c26f1..71a3322 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d48db921392b0ea6cf49fc0edebd0a3f YAML-LibYAML-0.55.tar.gz
+6ac5aa764d55395175d7c6f60e606ce0 YAML-LibYAML-0.57.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
[perl-YAML-LibYAML] Created tag perl-YAML-LibYAML-0.57-1.fc22
The lightweight tag 'perl-YAML-LibYAML-0.57-1.fc22' was created pointing to: c6d19a8... Update to 0.57 -- 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 1183106] New: perl-JSON-XS compiled against wrong version of perl
https://bugzilla.redhat.com/show_bug.cgi?id=1183106 Bug ID: 1183106 Summary: perl-JSON-XS compiled against wrong version of perl Product: Fedora Version: 20 Component: perl-JSON-XS Severity: medium Assignee: emman...@seyman.fr Reporter: igles...@uci.edu QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Description of problem: perl-JSON-XS in Fedora 20 appears to have been compiled against perl 5.16 rather than perl 5.18 which is distributed with Fedora 20 Version-Release number of selected component (if applicable): perl-JSON-XS-2.34-3.fc20.x86_64 How reproducible: Steps to Reproduce: 1. Build a short perl program with one line: use JSON::XS; 2. run the program with perl 3. Actual results: perl t.pl Perl API version v5.16.0 of JSON::XS does not match v5.18.0 at /usr/share/perl5/XSLoader.pm line 92. Compilation failed in require at t.pl line 3. BEGIN failed--compilation aborted at t.pl line 3. Expected results: no errors Additional info: This system was upgraded from F19 to F20. F19 had perl 5.16, F20 has perl 5.18. I tried removing and reinstalling perl-JSON-XS but that did not fix the problem. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=EWoLu6x4Kpa=cc_unsubscribe -- 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 1183106] perl-JSON-XS compiled against wrong version of perl
https://bugzilla.redhat.com/show_bug.cgi?id=1183106 Paul Howarth p...@city-fan.org changed: What|Removed |Added CC||p...@city-fan.org --- Comment #1 from Paul Howarth p...@city-fan.org --- You've probably got a locally-built version of JSON::XS on your system that's being picked up. On your system, what's the output of: $ strace -fq -e trace=open -- perl -e 'use JSON::XS' -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ohHyjhPTwCa=cc_unsubscribe -- 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 1183106] perl-JSON-XS compiled against wrong version of perl
https://bugzilla.redhat.com/show_bug.cgi?id=1183106 Mike Iglesias igles...@uci.edu changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |NOTABUG Last Closed||2015-01-16 17:17:46 --- Comment #2 from Mike Iglesias igles...@uci.edu --- Yep, you're right. I was looking in /usr/local/share/perl5 for a local one and didn't look in /usr/local/lib64/perl5. Sorry about that... -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=kGth6nThJ4a=cc_unsubscribe -- 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: F22 System Wide Change: GCC5
On Fri, Jan 16, 2015 at 04:12:03AM +, Peter Robinson wrote: On Fri, Jan 16, 2015 at 4:00 AM, Richard W.M. Jones rjo...@redhat.com wrote: Jakub: I will test gcc 5 on my Rawhide aarch64 machine, if you can point me to either a build of it or an SRPM. So far I see no gcc 5 builds in either Koji or the linked wiki page. aarch64 scratch build that Jakub did yesterday is here http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2847399 Thanks Peter -- will give this a spin on Monday. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- 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: Bodhi policy for pushing updates to stable
On 01/15/2015 05:15 PM, Luke Macken wrote: On Thu, Jan 15, 2015 at 10:19:19AM +0100, Tomas Hozza wrote: Hi all. When upgrading F20 to F21 using FedUp, some users had a problem with some packages not being upgraded (e.g. [1]). The problem was caused by broken update path F20 - F21. For example in wget's case I pushed updates for the same NVR in F20 and F21 with auto-karma. However the wget update for F20 got the stable karma and was pushed to stable before the update for F21. I think bodhi should enforce the update path is not broken and hold the update for F20 until the update for F21 is in stable. I know I can do it manually and disable auto-karma and push updates to stable as they should be. However I think such task should be automated. Would it be possible to enforce such a thing for updates in bodhi? The broken upgrade path for the F20 wget update was detected by Taskotron[0], and then bodhi immediately disabled autokarma[1]. However, the stable karma threshold was reached about 5 minutes before it was detected, so it went out anyway. Bodhi2 already has Taskotron-based gating baked into the push process[2], but this specific issue can also be fixed in the current bodhi1 codebase. Upon Taskotron failure, if the update has already reached the stable karma threshold, bodhi should revoke the stable request. I opened an upstream ticket to track this issue[3] luke [0]: https://admin.fedoraproject.org/updates/FEDORA-2014-17194/wget-1.16.1-2.fc20 [1]: https://fedorahosted.org/fesco/ticket/1242 https://github.com/fedora-infra/bodhi/pull/41 [2]: https://github.com/fedora-infra/bodhi/pull/109 [3]: https://github.com/fedora-infra/bodhi/issues/116 Thank you for creating the ticket. Regards, -- 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
Re: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
- Original Message - Honza Horak wrote: * Fedora Rings (hhorak, 12:03:21) [snip] * IDEA: definition of ring 1 is a minimal set of packages that give you a functional system, with some sort of approval (hhorak, 13:31:21) * IDEA: ring 1 should be self-hosted -- because you want to build very solid important packages using very solid important packages (hhorak, 13:31:21) In other words, Fedora Core all over again? Been there, done that… Kevin Kofler Not all of us were there. So what's the problem with that? -- Regards, Slavek Kabrda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-DateTime-TimeZone] Fix dependency filtering
commit 3e5a5586476ff5888e1636498a2dedadb23ee937
Author: Petr Písař ppi...@redhat.com
Date: Fri Jan 16 09:32:01 2015 +0100
Fix dependency filtering
perl-DateTime-TimeZone.spec | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
---
diff --git a/perl-DateTime-TimeZone.spec b/perl-DateTime-TimeZone.spec
index 138290b..09fb897 100644
--- a/perl-DateTime-TimeZone.spec
+++ b/perl-DateTime-TimeZone.spec
@@ -1,6 +1,6 @@
Name: perl-DateTime-TimeZone
Version:1.83
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Time zone object base class and factory
License:GPL+ or Artistic
Group: Development/Libraries
@@ -65,12 +65,11 @@ Requires: perl(DateTime::TimeZone::Tzfile)
%endif
%?perl_default_filter}
-%global __requires_exclude
%{__requires_exclude}|perl\\(Params::Validate\\)$|perl\\(Class::Singleton\\)$
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\((Params::Validate|Class::Singleton)\\)$
%if 0%{?perl_bootstrap}
# avoid circular dependencies - DateTime strictly requires DateTime::TimeZone
-%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}perl\\(DateTime\\)
-%global __requires_exclude %{__requires_exclude}|perl\\(DateTime::Duration\\)
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(DateTime(::Duration)?\\)
%endif
%description
@@ -100,6 +99,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Jan 16 2015 Petr Pisar ppi...@redhat.com - 1.83-2
+- Fix dependency filtering
+
* Wed Jan 07 2015 Petr Šabata con...@redhat.com - 1.83-1
- 1.83 bump, tests enhanced for 5.21
- Dropping F16-era conflicts
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Remove gcc, gcc-c++ and make from minimal build root
On 15.1.2015 23:13, Nicolas Chauvet wrote: 2015-01-15 20:18 GMT+01:00 Orion Poplawski or...@cora.nwra.com: On 01/15/2015 04:20 AM, Ralf Corsepius wrote: On 01/14/2015 03:10 AM, Orion Poplawski wrote: On 01/12/2015 06:08 AM, Vít Ondruch wrote: Dear Fedora developers, I'd like to collect some feedback about the $SUBJECT, i.e. making minimal build root really minimal, explicitly specifying build dependencies, etc. Would it be technically feasible to have a different buildroot for arch and noarch packages? What would this be useful for? The thought would be that (almost all) noarch packages don't need gcc, so the noarch buildroot could exclude gcc without impacting existing packages. I was going to say the same about noarch/arched packages and gcc assumption, also that I don't see any simplification in hardcoding the default compiler everywhere, specially as It probably depends on the build target . I remember other distros were using cross-compiler in buildroot and that was working pretty fine if the default compiler wasn't needlessly assumed. Another case about the default buildroot is compiler version, one could rely on a newer gcc (such as with a gcc5 package) and rebuild any packages with this new buildroot environment without tweaking any sources packages. (I have no releng experience so I can be completely mistaken, please forgive me :-)) Another advantage could be mass-rebuild simplification. Maybe we could save machine and man-time by not rebuilding noarch packages because of gcc rebase or something like that. Maybe this can be somehow generalized: If we had a database with mapping: SRPM - all packages in build root (implicit and explicit BuildRequires) we could somehow limit mass rebuilds to packages affected by latest changes. -- Petr^2 Spacek -- 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: Remove gcc, gcc-c++ and make from minimal build root
W dniu 16.01.2015 o 09:35, Petr Spacek pisze: Another advantage could be mass-rebuild simplification. Maybe we could save machine and man-time by not rebuilding noarch packages because of gcc rebase or something like that. GCC change may affect binaries which will generate other output which will change noarch packages. -- 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: Self Introduction: Jakub Jelen
On 01/15/2015 04:24 PM, Jakub Jelen wrote: I look forward to future cooperation with you and thanks you all for doing Fedora. Welcome Jakub ! -- Jiri -- 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: against dnssec: Is DNSSEC a Government-Controlled PKI?
On 16.1.2015 05:19, Richard W.M. Jones wrote: On Thu, Jan 15, 2015 at 07:45:00PM -0500, Neal Becker wrote: I personally know nothing of the subject, but found this article, I wonder if there's any truth here? If so, maybe the push for dnssec on f22 isn't as wonderful as supposed: http://sockpuppet.org/blog/2015/01/15/against-dnssec/ Considerable amount of commentary on this article here: https://news.ycombinator.com/item?id=8894902 Wow, it seems that DNSSEC topic joined The Flamewar Club and will have its place next to Windows x *nix flamewars :-) Tomas Hozza and me will be giving a talk/workshop about DNSSEC in practice at DevConf 2015 in Brno. Join us and get your hands dirty instead of writing hateful posts on the Internet! You will have a plenty of time for judging after the first introduction and hands-on experience :-) See http://sched.co/2Bet Here I'm going to limit myself to clarifying the section DNSSEC is a Government-Controlled PKI from the article. Disclaimer: I'm intentionally omitting *many* details here to make it concise. Go ahead and read RFC 4034 and 4035 if you want to understand all the gory details. First of all, to some degree DNSSEC is a Government-Controlled PKI but you need to understand few important details before you can draw informed comparison with classic X.509 PKI. - We can assume that US gov can force organization responsible for signing the root zone (Verising) to sign fake version of the root zone, of course. - In practice it would be hugely problematic to do such attack *on large scale* because the root zone is served from a large number of servers *and organizations* worldwide so it is very unlikely that a fake version of the root zone would go unnoticed. - If we limit the the attack to one target (organization/person) it would not be so easy either. An attacker would have to feed the target with fake data all the time because DNSSEC validation would fail if the client was confronted with fake genuine data at the same time. (Again, go and understand DS/DNSKEY hierarchy described in RFC 4034 and do not forget to consider which zones contain data 'useful' to an attacker.) To sum it up - DNSSEC gives you Hierarchical trust model: “my.example.net.” can be spoofed *only* by its parents: - example.net. - net. - DNS root “.” Now you are in position to compare DNSSEC+DANE with X.509 PKI: There were 1,482 CA Certificates trustable by Windows or Firefox in 2010 and any of them could spoof TLS cert. (This list of CAs include surprises like a state-controlled CA which never issued public facing certificate etc.) More importantly, this spoofed cert is easily usable for very targeted attacks (e.g. to a single TLS connection) and is extremely hard to detect by unsuspecting client. See https://www.eff.org/observatory for details about a TLS survey done by EFF. I hope to see you at our DNSSEC workshop! http://sched.co/2Bet -- Petr Spacek @ Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Define future of Fedora (was: Re: FESCo and Env and Stacks WG upcoming elections nominations are open)
There are not many guys interested in the Environment Stacks WG on the nomination page [2] so far, which is really shame. Don't loose your chance to help moving Fedora forward! The main goal of this working group is to research and develop new or improved methods of developing, testing, packaging and deploying software for the Fedora community. For more concrete picture of our focus, see the tasklist [3]. We might have struggled with not much real stuff done so far, but we really need more people interested in discussions and also getting hands dirty by hacking some proof-of-concept solutions, patches for existing systems/tools and generally enjoying a lot of fun. Challenging tasks often have quite unclear specification, so some level of own imagination and creativity is more than welcome, but being a member of the working group is great opportunity to have *big impact on the future look of Fedora*. Please, consider and add your nomination before 23:59:59 UTC on January 19, 2015! [1] https://fedoraproject.org/wiki/Env_and_Stacks [2] https://fedoraproject.org/wiki/Env_and_Stacks/Nominations [3] https://fedoraproject.org/wiki/Env_and_Stacks/Tasklist Honza On 01/13/2015 10:37 AM, Jaroslav Reznik wrote: Hello everyone! The nomination period for FESCo and Environments and Stacks Working Group Elections is now open. We will be selecting five seats on FESCo [1] and four seats on Env and Stacks Working Group [2]. If you are interested in these roles, please add yourself to the lists of nominees at [1] and [2] before 23:59:59 UTC on January 19, 2015! If you wish to nominate someone else, please consult with that person ahead of time. If you know someone who would be a good candidate, now is a great time to make sure they're thinking about it. And missing links I promised :). [1] http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations [2] http://fedoraproject.org/wiki/Env_and_Stacks/Nominations Main elections page is at http://fedoraproject.org/wiki/Elections Jaroslav ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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: GUI applications writing garbage to stdout/stderr
Kevin Kofler wrote: I'm with you, debugging spam needs to go away, GUI applications have no business writing anything at all to the console, ever. Except when they have really serious errors. I once had an X problem that prevented Openoffice from working. It showed no window, output nothing, and terminated immediately with an exit code of zero. In other words it behaved just like the command true. That's going a bit too far. (I wrote a bug report and was told that Openoffice was fixed to write an error message and return an error code.) -- Björn Persson pgpWCRicn1XpQ.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Taskotron misses dropped subpackages
Taskotron doesn't notice if subpackages have been dropped and cause unresolvable dependencies because they are not obsoleted anywhere. Examples: jogl2-javadoc, miglayout-examples, glusterfs-regression-tests rubygem-json-doc, rubygem-rake-doc, and more Yum is broken in the same way. And by design. When installing a discontinued subpackage, it happily installs any old packages it still finds in the repos to satisfy dependencies, but it cannot upgrade the installation afterwards because of unsatisfied deps. [...] Also a reminder for packagers: Adhere to Fedora's Packaging Guidelines when removing subpackages! Add proper Obsoletes tags to your package. http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Renaming.2Freplacing_existing_packages -- 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: Remove gcc, gcc-c++ and make from minimal build root
On Fri, Jan 16, 2015 at 10:08 AM, Marcin Juszkiewicz mjuszkiew...@redhat.com wrote: GCC change may affect binaries which will generate other output which will change noarch packages. It shouldn't change a program's behavior, unless the program itself is relying on undefined behavior. Either way I would call that a bug. The only output change that I could understand is something like a `vim --version` (though it doesn't actually show gcc's version, but close enough). -- 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: Define future of Fedora
Let me emphasize especially need for somebody who will be able to look closely at and contribute to release engineering tools. I think it's clear that no bigger change how the fedora looks will happen without touching the tools we use currently in Fedora -- be it koji, dist-git, copr. Having somebody who would not be afraid to touch these things and work closely with Fedora release engineering, that's something what can make the things moving. Now, who is able to accept that challenge? Honza On 01/16/2015 10:49 AM, Honza Horak wrote: There are not many guys interested in the Environment Stacks WG on the nomination page [2] so far, which is really shame. Don't loose your chance to help moving Fedora forward! The main goal of this working group is to research and develop new or improved methods of developing, testing, packaging and deploying software for the Fedora community. For more concrete picture of our focus, see the tasklist [3]. We might have struggled with not much real stuff done so far, but we really need more people interested in discussions and also getting hands dirty by hacking some proof-of-concept solutions, patches for existing systems/tools and generally enjoying a lot of fun. Challenging tasks often have quite unclear specification, so some level of own imagination and creativity is more than welcome, but being a member of the working group is great opportunity to have *big impact on the future look of Fedora*. Please, consider and add your nomination before 23:59:59 UTC on January 19, 2015! [1] https://fedoraproject.org/wiki/Env_and_Stacks [2] https://fedoraproject.org/wiki/Env_and_Stacks/Nominations [3] https://fedoraproject.org/wiki/Env_and_Stacks/Tasklist Honza On 01/13/2015 10:37 AM, Jaroslav Reznik wrote: Hello everyone! The nomination period for FESCo and Environments and Stacks Working Group Elections is now open. We will be selecting five seats on FESCo [1] and four seats on Env and Stacks Working Group [2]. If you are interested in these roles, please add yourself to the lists of nominees at [1] and [2] before 23:59:59 UTC on January 19, 2015! If you wish to nominate someone else, please consult with that person ahead of time. If you know someone who would be a good candidate, now is a great time to make sure they're thinking about it. And missing links I promised :). [1] http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations [2] http://fedoraproject.org/wiki/Env_and_Stacks/Nominations Main elections page is at http://fedoraproject.org/wiki/Elections Jaroslav ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Base Design WG agenda meeting 16 January 2015 15:00 UTC on #fedora-meeting
Agenda: - Status buildrequires cleanup work (davids nils!) - Docker update - Status rpm mechanisms for multiple config subpackages factory reset files - F22 items - DevConf - Open Floor Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- 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: Remove gcc, gcc-c++ and make from minimal build root
On Fri, Jan 16, 2015 at 11:19:13AM +0100, Dridi Boukelmoune wrote: On Fri, Jan 16, 2015 at 10:08 AM, Marcin Juszkiewicz mjuszkiew...@redhat.com wrote: GCC change may affect binaries which will generate other output which will change noarch packages. It shouldn't change a program's behavior, unless the program itself is relying on undefined behavior. Either way I would call that a bug. Agreed. In principle, any package could affect the build of any other package (e.g. bash version could realistically influence build results), but we ignore this. As you say, something like this would happen only if there was some (significant) bug. Those bugs are dealt with individually when detected. The same is true for the compiler version influencing the behaviour of compiled programs. This might happen, but very rarely. Generally updating the compiler should only result in changes in behaviour only when the program was buggy to begin with and relied on undefined behaviour, bad memory access, or similar. On Fri, Jan 16, 2015 at 09:35:50AM +0100, Petr Spacek wrote: Another advantage could be mass-rebuild simplification. Maybe we could save machine and man-time by not rebuilding noarch packages because of gcc rebase or something like that. +1 Only rebuilding packages based on explicit BR would be a nice optimization for mass rebuilds. Maybe this can be somehow generalized: If we had a database with mapping: SRPM - all packages in build root (implicit and explicit BuildRequires) we could somehow limit mass rebuilds to packages affected by latest changes. Zbyszek -- 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: Self Introduction: Jakub Jelen
On Fri, Jan 16, 2015 at 2:22 AM, Jiri Popelka jpope...@redhat.com wrote: On 01/15/2015 04:24 PM, Jakub Jelen wrote: I look forward to future cooperation with you and thanks you all for doing Fedora. Welcome Jakub ! Yes, welcome! - Ken -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Thu, 2015-01-08 at 13:42 +0100, Jaroslav Reznik wrote: = Proposed System Wide Change: Set sshd(8) PermitRootLogin=no = https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no The discussion got rather long, but I didn't see one particular aspect discussed: Remote users would not be allowed to login using 'root' account with a password. They would have to login using an SSH key or first connect using a non-root account and then upgrade their privileges via sudo(8) or su -. Doesn't this make the systems actually _less_ secure? I sometimes do risky things with my regular account. I often process untrusted input I download from internet, often using tools that have serious security issues discovered (it doesn't have to be just flash or firefox, remember the binutils [1] or less [2] issues?). I'm sure many of us are similarly careless with their non-privileged accounts. [1] http://openwall.com/lists/oss-security/2014/10/23/5 [2] http://seclists.org/fulldisclosure/2014/Nov/74 There's a chance of a successful exploitation that would result in obtaining my privileges. Sure, gaining access to my account is bad enough, but if I run su or sudo, they have root! I'm never sure if I'm talking to the actual tool. Something could have tampered with my shell and now is snooping for my password. The attacker could have ptrace()d my shell and switched execve(/bin/su) for execve(/tmp/uz_nejsu). Or they could just have changed the $PATH in my .profile. I wouldn't notice! For this reason, I avoid privilege escalation when I need to conduct privileged operations, but open a separate session. The sshd daemon running with root privileges is more trustworthy to me than my user session. -1 for this change from me. Disallowing root logins and requiring me to use my regular account puts other users of the system in risk. Thank you, Lubo -- 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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On 01/16/2015 03:39 PM, Lubomir Rintel wrote: On Thu, 2015-01-08 at 13:42 +0100, Jaroslav Reznik wrote: = Proposed System Wide Change: Set sshd(8) PermitRootLogin=no = https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no The discussion got rather long, but I didn't see one particular aspect discussed: Remote users would not be allowed to login using 'root' account with a password. They would have to login using an SSH key or first connect using a non-root account and then upgrade their privileges via sudo(8) or su -. Doesn't this make the systems actually _less_ secure? I sometimes do risky things with my regular account. I often process untrusted input I download from internet, often using tools that have serious security issues discovered (it doesn't have to be just flash or firefox, remember the binutils [1] or less [2] issues?). I'm sure many of us are similarly careless with their non-privileged accounts. [1] http://openwall.com/lists/oss-security/2014/10/23/5 [2] http://seclists.org/fulldisclosure/2014/Nov/74 There's a chance of a successful exploitation that would result in obtaining my privileges. Sure, gaining access to my account is bad enough, but if I run su or sudo, they have root! I'm never sure if I'm talking to the actual tool. Something could have tampered with my shell and now is snooping for my password. The attacker could have ptrace()d my shell and switched execve(/bin/su) for execve(/tmp/uz_nejsu). Or they could just have changed the $PATH in my .profile. I wouldn't notice! For this reason, I avoid privilege escalation when I need to conduct privileged operations, but open a separate session. The sshd daemon running with root privileges is more trustworthy to me than my user session. -1 for this change from me. -1 from me, too :) Disallowing root logins and requiring me to use my regular account puts other users of the system in risk. Thank you, Lubo -- 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: GUI applications writing garbage to stdout/stderr
Am 16.01.2015 um 10:50 schrieb Björn Persson: Kevin Kofler wrote: I'm with you, debugging spam needs to go away, GUI applications have no business writing anything at all to the console, ever. Except when they have really serious errors. I once had an X problem that prevented Openoffice from working. It showed no window, output nothing, and terminated immediately with an exit code of zero. In other words it behaved just like the command true. That's going a bit too far. (I wrote a bug report and was told that Openoffice was fixed to write an error message and return an error code.) that's why a graphical application with the ability to gibe out debug infos if started in a terminal has to have a -v or whatever parameter but just shut up in a normal call 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: [Base] Base Design WG agenda meeting 16 January 2015 15:00 UTC on #fedora-meeting
On 01/16/2015 01:39 PM, Phil Knirsch wrote: Agenda: - Status buildrequires cleanup work (davids nils!) - Docker update - Status rpm mechanisms for multiple config subpackages factory reset files - F22 items - DevConf - Open Floor Thanks regards, Phil Logs: Meeting ended Fri Jan 16 15:59:36 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2015-01-16/fedora_base_design_working_group.2015-01-16-15.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2015-01-16/fedora_base_design_working_group.2015-01-16-15.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2015-01-16/fedora_base_design_working_group.2015-01-16-15.00.log.html zodbot Please remember to CC: meetingminu...@lists.fedoraproject.org on your summary/minutes email. -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- 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: GUI applications writing garbage to stdout/stderr
On 01/15/2015 03:23 PM, Kevin Kofler wrote: Jaroslav Reznik wrote: So it's kWarning, not kDebug and it can't be ignored by using kdebugdialog settings. There are two options - fix the underlying issue or change kWarning to kDebug - it just depends on how important it is and it seem as Harald already pointed out - nobody really cares. I found one another example of mimetypes kWarning being changed just to kDebug. But I'm not skilled in mimetypes at all :). Maybe we should just silence everything less than qFatal by default? Kevin Kofler Sounds good to me - my users (old unix folks who always use the command line) are always complaining about this. Where do we tweak that? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.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: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
On 16 January 2015 at 01:31, Bohuslav Kabrda bkab...@redhat.com wrote: - Original Message - Honza Horak wrote: * Fedora Rings (hhorak, 12:03:21) [snip] * IDEA: definition of ring 1 is a minimal set of packages that give you a functional system, with some sort of approval (hhorak, 13:31:21) * IDEA: ring 1 should be self-hosted -- because you want to build very solid important packages using very solid important packages (hhorak, 13:31:21) In other words, Fedora Core all over again? Been there, done that… Kevin Kofler Not all of us were there. So what's the problem with that? Fedora Core was seen by many developers as You either work in the small team of Red Hatters and get stuff done or You are a volunteer or someone at Red Hat who isn't part of the cool group and don't get stuff done. If you were an Outsider and worked on a package that all of a sudden was core you found your version no longer was the one being worked on. Inside of the Core team it was a giant pressure cooker of We have to get this out the f'ing door now and don't have time to talk. So it took 3 releases (5 if you count RHL 8 and RHL 9) for Extras to be actually accepted as being something that could be done, and it took 3-4 more releases before Core could be unwound and outside developers to be considered essential developers. Because this proposal is tone deaf to that history it can come across as insulting in various ways. -- Stephen J Smoogen. -- 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: Remove gcc, gcc-c++ and make from minimal build root
On 01/14/2015 04:00 PM, Dennis Gilmore wrote: On 01/13/2015 06:01 PM, Dennis Gilmore wrote: that all being said. koji doesn't use any caching and will not use the lvm plugin. we make every buildroot from scratch using a fully clean environment to help with ensuring reproducability. You can cache and still preserve reproducability. What I'm planning for Copr is to do (every week/month) for chroot in fedora-20-x86_64 fedora-21_86_64 ... ; do mock --init $chroot done take snapshot of that. I plan to do that on VM level. And when new task come, I will just restore from that snapshot. And mock will start with already populated cache. So I will have better caching and yet reproducability. you really can't. you would need to make a new cache any time one of the packages in the minimal buildroot changes. That is why mock run 'yum update' on minimal buildroot before proceeding further. So if one package in buildroot changes, you will just download and install just that one package and all other comes from cache. -- Miroslav Suchy, RHCE, RHCDS 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
Re: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
- Original Message - On 16 January 2015 at 01:31, Bohuslav Kabrda bkab...@redhat.com wrote: - Original Message - Honza Horak wrote: * Fedora Rings (hhorak, 12:03:21) [snip] * IDEA: definition of ring 1 is a minimal set of packages that give you a functional system, with some sort of approval (hhorak, 13:31:21) * IDEA: ring 1 should be self-hosted -- because you want to build very solid important packages using very solid important packages (hhorak, 13:31:21) In other words, Fedora Core all over again? Been there, done that… Kevin Kofler Not all of us were there. So what's the problem with that? Fedora Core was seen by many developers as You either work in the small team of Red Hatters and get stuff done or You are a volunteer or someone at Red Hat who isn't part of the cool group and don't get stuff done. If you were an Outsider and worked on a package that all of a sudden was core you found your version no longer was the one being worked on. Inside of the Core team it was a giant pressure cooker of We have to get this out the f'ing door now and don't have time to talk. So it took 3 releases (5 if you count RHL 8 and RHL 9) for Extras to be actually accepted as being something that could be done, and it took 3-4 more releases before Core could be unwound and outside developers to be considered essential developers. Because this proposal is tone deaf to that history it can come across as insulting in various ways. -- Stephen J Smoogen. Ok, I think that there may be some misunderstanding happening here. The proposal as we discussed it was, that (as our WG sees it): * ring 0, ring 1 and ring 2 are the content built in Fedora's Koji == official Fedora repos * ring 0 is JeOS as defined by Matthew in the .Next proposal * ring 1 contains the packages that are critical in the sense that they are used to compose LiveCDs of our products/cloud images * ring 2 contains anything that anyone wants to build as an extension to rings 0 and 1 (and it's still in Koji as it is right now, e.g. bazillion of python/ruby/perl extension packages, applications that aren't on LiveCDs etc) We meant to categorize packages that are currently in Fedora (and we also wanted to extend the ring proposal to go beyond that with rings 3 and 4 - Copr/Playground and other stuff, but this was actually not discussed into detail yet). Please note, that this proposal is absolutely not about imposing some restrictions on who can/should maintain what. It's really just a categorization of packages based on our WG's perception of importance to Fedora. The only practical change that we suggested is that packages in rings 0 and 1 should get some more QE/integration tests to better guarantee stability. These packages are defined implicitly by their presence on LiveCDs/cloud image, there's no intention of creating a cool group. I hope this explains the matter. If this still feels wrong, I'd like to continue this discussion, as it's not our intention to make someone feel excluded or unimportant. Slavek -- 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: Define future of Fedora (was: Re: FESCo and Env and Stacks WG upcoming elections nominations are open)
On 16 January 2015 at 02:49, Honza Horak hho...@redhat.com wrote: There are not many guys interested in the Environment Stacks WG on the nomination page [2] so far, which is really shame. Don't loose your chance to help moving Fedora forward! The main goal of this working group is to research and develop new or improved methods of developing, testing, packaging and deploying software for the Fedora community. For more concrete picture of our focus, see the tasklist [3]. We might have struggled with not much real stuff done so far, but we really need more people interested in discussions and also getting hands dirty by hacking some proof-of-concept solutions, patches for existing systems/tools and generally enjoying a lot of fun. Challenging tasks often have quite unclear specification, so some level of own imagination and creativity is more than welcome, but being a member of the working group is great opportunity to have *big impact on the future look of Fedora*. OK I think one of the problems is that this doesn't look like it is a doing group but a talking group. By a talking group I mean that the first page comes across as We are going to have a lot of meetings to bike shed about what we would like to see happen. We actually don't do any of that.. we just point the direction for others to go. or worse yet The 5 year plan for growth and production will be produced by the committee in charge of 5 year plans. For many of the people I know, that is what FPC and FESCO are already doing [even if it isn't.] It is also not something they want to be part of.. (more meetings versus more doings.) Since I very much doubt that any of these characteristics I listed above are actually what the group is trying to do... I think the committee needs to better explain what it is going to do, how it is going to do it, etc. -- Stephen J Smoogen. -- 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: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
On 01/16/2015 05:08 PM, Stephen John Smoogen wrote: On 16 January 2015 at 01:31, Bohuslav Kabrda bkab...@redhat.com mailto:bkab...@redhat.com wrote: - Original Message - Honza Horak wrote: * Fedora Rings (hhorak, 12:03:21) [snip] * IDEA: definition of ring 1 is a minimal set of packages that give you a functional system, with some sort of approval (hhorak, 13:31:21) * IDEA: ring 1 should be self-hosted -- because you want to build very solid important packages using very solid important packages (hhorak, 13:31:21) In other words, Fedora Core all over again? Been there, done that… Kevin Kofler Not all of us were there. So what's the problem with that? Fedora Core was seen by many developers as You either work in the small team of Red Hatters and get stuff done or You are a volunteer or someone at Red Hat who isn't part of the cool group and don't get stuff done. If you were an Outsider and worked on a package that all of a sudden was core you found your version no longer was the one being worked on. That's a very polite description of the situation, then. In fact, it was a 2-class hierarchical society with 2 classes of humans. I do not want to see this dark age of fedora's history repeat. Ralf -- 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: Define future of Fedora
On Fri, Jan 16, 2015, at 07:31 AM, Honza Horak wrote: Let me emphasize especially need for somebody who will be able to look closely at and contribute to release engineering tools. I think it's clear that no bigger change how the fedora looks will happen without touching the tools we use currently in Fedora -- be it koji, dist-git, copr. Having somebody who would not be afraid to touch these things and work closely with Fedora release engineering, that's something what can make the things moving. Now, who is able to accept that challenge? With such an eloquent call, I couldn't resist adding my name to the list! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaning lua-sec, lua-dbi and prosody
Hi, I've orphaned lua-sec, lua-dbi and prosody packages. Feel free to take ownership of those ones. Regards, -- Johan -- 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: Remove gcc, gcc-c++ and make from minimal build root
On Fri, 16 Jan 2015 14:53:36 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: Agreed. In principle, any package could affect the build of any other package (e.g. bash version could realistically influence build results), but we ignore this. As you say, something like this would happen only if there was some (significant) bug. Those bugs are dealt with individually when detected. The same is true for the compiler version influencing the behaviour of compiled programs. This might happen, but very rarely. Generally updating the compiler should only result in changes in behaviour only when the program was buggy to begin with and relied on undefined behaviour, bad memory access, or similar. Just to clarify here: mass rebuilds are done in a side tag. They inherit the normal rawhide buildroot, and do not update it. So, everything in the mass rebuild is built with (mostly) the same buildroot. Things aren't added as they are rebuilt. Only at the end when the side tag is merged back in is the rawhide buildroot updated with all the new mass rebuilt builds. So, if packageA is mass rebuilt and that new build breaks building packageB, we won't know of it until after the mass rebuild, both are tagged in and the packageB maintainer tries to rebuild packageB for some other reason. ;) I suppose someone with a lot of time on their hands and a good grasp of graph theory could come up with a way to rebuild everything in an order that would ensure that everything newly rebuilt was used to build the next list. It would be much like bootstrapping a new arch. Also, I suspect it would take a great deal more time than 40 hours. ;) kevin pgp8rBnRNAzf2.pgp 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: F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades
On Tue, Jan 13, 2015, at 04:41 PM, Colin Walters wrote: If it's installing a regular file, then it won't work - the package (daemon) needs to create it on start. I filed a bug about this: https://bugzilla.redhat.com/show_bug.cgi?id=1182785 Though I wonder if this should be a Change in itself, or a packaging guideline update? I think it does need to go through the FPC. I don’t see a benefit in splitting the Change into two if there is a strict dependency; would it make sense to have the /var change without the rest of the RpmOstree features, or vice versa? To be clear, this transition doesn't have to happen all at once, only for the packages that one would want to consume via rpm-ostree. (Which ideally at some point is all, but I'm focusing on the core personally) (FWIW the schedule for going through the FPC and hitting the completion/testable deadline on Feb 24 feels a little tight, though probably still doable. Do you know how many packages would be affected?) Mirek -- 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: 20150116 changes
Compose started at Fri Jan 16 15:03:08 UTC 2015 Broken deps for i386 -- [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [aeskulap] aeskulap-0.2.2-0.19beta1.fc22.i686 requires libofstd.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires liboflog.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg8.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg16.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg12.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmnet.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmjpeg.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimgle.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimage.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmdata.so.3.6 [boswars] boswars-2.7-5.fc22.i686 requires libtolua++-5.1.so [bro] broccoli-2.3-1.fc22.i686 requires bro-2.3 python-broccoli-2.3-1.fc22.i686 requires bro-2.3 [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [fawkes] fawkes-lua-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-katana-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-pantilt-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-roomba-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-skiller-0.5.0-19.fc22.i686 requires libtolua++-5.1.so [freeipa] freeipa-server-trust-ad-4.1.2-1.fc22.i686 requires libpdb.so.0(PDB_0) freeipa-server-trust-ad-4.1.2-1.fc22.i686 requires libpdb.so.0 [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 [gnumed] gnumed-1.4.8-2.fc21.noarch requires python-imaging-sane [gnuplot] gnuplot-doc-5.0.0-3.fc22.i686 requires libz.so.1()(64bit) gnuplot-doc-5.0.0-3.fc22.i686 requires libpangocairo-1.0.so.0()(64bit) gnuplot-doc-5.0.0-3.fc22.i686 requires libpango-1.0.so.0()(64bit) gnuplot-doc-5.0.0-3.fc22.i686 requires libm.so.6(GLIBC_2.2.5)(64bit) gnuplot-doc-5.0.0-3.fc22.i686 requires libm.so.6()(64bit) gnuplot-doc-5.0.0-3.fc22.i686 requires libgobject-2.0.so.0()(64bit) gnuplot-doc-5.0.0-3.fc22.i686 requires libglib-2.0.so.0()(64bit) gnuplot-doc-5.0.0-3.fc22.i686 requires libdl.so.2()(64bit) gnuplot-doc-5.0.0-3.fc22.i686 requires libcerf.so.1()(64bit) gnuplot-doc-5.0.0-3.fc22.i686 requires libcairo.so.2()(64bit) gnuplot-doc-5.0.0-3.fc22.i686 requires libc.so.6(GLIBC_2.2.5)(64bit) [golang-github-skynetservices-skydns] golang-github-skynetservices-skydns-devel-0-0.1.git245a121.fc22.noarch requires golang(kubernetes/pkg/util) golang-github-skynetservices-skydns-devel-0-0.1.git245a121.fc22.noarch requires golang(kubernetes/pkg/proxy/config) golang-github-skynetservices-skydns-devel-0-0.1.git245a121.fc22.noarch requires golang(kubernetes/pkg/client) golang-github-skynetservices-skydns-devel-0-0.1.git245a121.fc22.noarch requires golang(kubernetes/pkg/api) [guacamole-server] libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-utils.so.1.2 libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-core.so.1.2 libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-codec.so.1.2 libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-cache.so.1.2 [libhocr] libhocr-gtk-0.10.17-18.fc22.i686 requires python-imaging-sane [nifti2dicom] nifti2dicom-0.4.9-1.fc22.i686 requires libitksys-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libitkopenjpeg-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libitkdouble-conversion-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libitkNetlibSlatec-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libhdf5_hl.so.8 nifti2dicom-0.4.9-1.fc22.i686 requires libhdf5_cpp.so.8 nifti2dicom-0.4.9-1.fc22.i686 requires libhdf5.so.8 nifti2dicom-0.4.9-1.fc22.i686 requires libITKznz-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKniftiio-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKgiftiio-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKWatersheds-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVtkGlue-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVideoIO-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires libITKVideoCore-4.6.so.1 nifti2dicom-0.4.9-1.fc22.i686 requires
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
On Fri, 2015-01-16 at 15:39 +0100, Lubomir Rintel wrote: There's a chance of a successful exploitation that would result in obtaining my privileges. Sure, gaining access to my account is bad enough, but if I run su or sudo, they have root! Along these lines, someone pointed out a rather nasty attack vector via sudo the other day: http://blog.grdryn.me/blog/fedora/prank-alias-sudo-in-bash.html so...you'd better remember to call it with \ every time...:) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Remove gcc, gcc-c++ and make from minimal build root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 16 Jan 2015 17:18:17 +0100 Miroslav Suchý msu...@redhat.com wrote: On 01/14/2015 04:00 PM, Dennis Gilmore wrote: On 01/13/2015 06:01 PM, Dennis Gilmore wrote: that all being said. koji doesn't use any caching and will not use the lvm plugin. we make every buildroot from scratch using a fully clean environment to help with ensuring reproducability. You can cache and still preserve reproducability. What I'm planning for Copr is to do (every week/month) for chroot in fedora-20-x86_64 fedora-21_86_64 ... ; do mock --init $chroot done take snapshot of that. I plan to do that on VM level. And when new task come, I will just restore from that snapshot. And mock will start with already populated cache. So I will have better caching and yet reproducability. you really can't. you would need to make a new cache any time one of the packages in the minimal buildroot changes. That is why mock run 'yum update' on minimal buildroot before proceeding further. So if one package in buildroot changes, you will just download and install just that one package and all other comes from cache. That invalidates being able to reproduce the build root exactly. as you would need to know and reproduce the package update. This is something that has undergone a lot of thought and consideration and there is very very good reasons things are the way they are. as i showed elsewhere in this thread most repos are used only once or twice at most on any given host. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUuceOAAoJEH7ltONmPFDRrq8QAIX07Q9MiY0RhXPveO+U48Kx rPoU9N2Sbyje1pAphkDeTSlRqIJn/cFnHCorVPkbi2GEUbLZ/0bZSVixVr/7aIn0 BymonZJiuc5skQkA0WVOUZyK5O801dOrztzvMUEmTLGG6j5SSjFg3W4yO1Vnn1l3 P6vPnczjGDOn42mDjdKGUVnEifsryFlNIRkQQycaVCmGPh0vkJGX3cYzu6ALUS4F ejSozB40LG6CMoLHDH4vi8MwLAz6/39siGxD/hkFOpziWSqAcvm6lSTlPREbSpTA E7gY+FGaT+7jQDSpJViUcfrIAinFlIIab0VUkdI+zd0v7vK+NJBluwfGHBl1817m IdA6Nz1jXG/5gQqTb8LdefCDuMyFpG1DWuiIF63vSmr83uMZOBSRWTtdS8jcRl39 qylx+CzKL4OAzBOlnSi437bitbyKOSLw2h0qDHiL29LvAsngKegLiXDiTvkGnkXX zNWUTkaHg+BCg/qzl9Zz3dgEtXOfTHXHKWoRl8L2/i101W4ucgx5ZHQFMydo9jiN e/e0E/FKqAAq0BbbK7+ltnKrpUeTxuQ74apjLbEAl6XMk9vYKORWxpUkHeGiasPM EvhOPf5LEi+veCvRPuqzU0jVauJxJeaLY2w0vGkdqfoj1w6fqO6JR63BIv/tXC5A MaD5XcAcF7a17uQDaQ1s =4vDY -END PGP 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: Remove gcc, gcc-c++ and make from minimal build root
that all being said. koji doesn't use any caching and will not use the lvm plugin. we make every buildroot from scratch using a fully clean environment to help with ensuring reproducability. You can cache and still preserve reproducability. What I'm planning for Copr is to do (every week/month) for chroot in fedora-20-x86_64 fedora-21_86_64 ... ; do mock --init $chroot done take snapshot of that. I plan to do that on VM level. And when new task come, I will just restore from that snapshot. And mock will start with already populated cache. So I will have better caching and yet reproducability. you really can't. you would need to make a new cache any time one of the packages in the minimal buildroot changes. That is why mock run 'yum update' on minimal buildroot before proceeding further. So if one package in buildroot changes, you will just download and install just that one package and all other comes from cache. That invalidates being able to reproduce the build root exactly. as you would need to know and reproduce the package update. This is something that has undergone a lot of thought and consideration and there is very very good reasons things are the way they are. as i showed elsewhere in this thread most repos are used only once or twice at most on any given host. The only way you could cache a base build root effectively is if you track the packages and NVRs and when one of them bump you regenerate the buildroot, likely pausing all builds until a new one is there. there's likely not that much churn in the packages contained in the root buildroot (you'd want to make sure you had everything for building .src.rpms too) and in some cases you could likely get days on the same image without having to rebuild it, other days you might have to do it a few times a time. Whether the effort to implement out weights the effort remains to be seen. I think, given the low IOPs on the builds with an underlying COP image it might well give a reasonable reduction in building especially during mass rebuilds where the builders are very active and as it's in a side tag the new build root packages don't end up in the build root until tagged. Using fedmsg it's likely not hard either to monitor a package subset for changes and regen the image. 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
Re: [EPEL-devel] Proposal for Python 3 packaging in EPEL 7
- Original Message - Excerpts from Stephen John Smoogen's message of 2015-01-09 10:25 +10:00: On 8 January 2015 at 17:01, Dan Callaghan dcall...@redhat.com wrote: Personally I am not looking forward to maintaining more branches and/or (sub-)packages for every python3X-*. I need to understand what you mean here? Even in EPIC and SCL's there would have to be some overlap and multiple branches over time due to the fact that python, ruby, java, etc all have multiple subpackages which would need to be built for multiple releases. They may not be for a long lenght of time, but the work is not going away. Right, even for Fedora there are multiple branches of course, what I meant was multiple *divergent* branches. For all my packages I prefer to keep a single spec for all branches with conditionals when necessary. Most of my packages are fairly stable and not releasing new incompatible versions too often, so most of the time I can just do one update and then all branches are a git fast-forward. The only time I have divergent branches is when a stable release needs a bug fix but rawhide has already moved to a newer incompatible version. That's fairly rare for my packages. So that approach works fine right now because we just have python-foo and python3-foo subpackages and they can just keep rolling through as new releases are branched and old releases die off. What I was picturing for EPEL Python 3 was that I would have to rename the subpackage to python34-foo. Then every time Python 3 is bumped I would have to rename all the subpackages to python35-foo, and then I would have divergent branches for as long as both 3.4 and 3.5 still exist. That's the situation I was complaining about. A much better approach is what Bohuslav has come up with, a single spec that builds both python3X and python3X+1 subpackages. And we can script the mass version bumping as well. So that addresses my worries. (The example spec makes me a bit sad with how complex and repetitive it is, but I guess there is nothing really we can do about that...) I was experimenting with dynamic subpackage generation, but you need Lua for that. And while it can be done, it's actually much uglier than the way I proposed. I guess the only nice way would be to add support for dynamic subpackage generation to RPM directly. That is actually something I've wanted to propose for some time now, but didn't really get to it... Also, it's questionable that it'd get to RHEL 7 rpm, so I think we're stuck with this. -- Dan Callaghan dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. -- Regards, Slavek Kabrda ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[EPEL-devel] Prosody XMPP CentOS EPEL latest package
I have been regular user of CENTOS 6.5 7. I need to know how can get the latest package of Prosody XMPP for CentOS. Currently I can get only prosody-0.8.2-7.el6.x86_64.rpm however I need to get Prosody 0.9.7. Please advice direct me to correct forum / Person. Distribution: CentOS 6 Repository: EPEL x86_64 Package name: prosody Package version: 0.8.2 Package architecture: x86_64 Package type: rpm Installed size: 709,99 KB Download size: 184,24 KB Binary package: prosody-0.8.2-7.el6.x86_64.rpm Source package: prosody-0.8.2-7.el6.src.rpm Rgds, ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[EPEL-devel] 2015-01-16 EPEL committee meeting
http://meetbot.fedoraproject.org/epel/2015-01-16/epel.2015-01-16-17.05.log.html 17:05:03 smooge #startmeeting epel 17:05:03 zodbot Meeting started Fri Jan 16 17:05:03 2015 UTC. The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:05:03 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:05:08 smooge #meetingname epel 17:05:08 zodbot The meeting name has been set to 'epel' 17:05:42 * bstinson is here 17:05:52 smooge #chairs smooge bstinson Evolution dgilmore nirik 17:05:54 * maxamillion is here 17:05:58 smooge #chair smooge bstinson Evolution dgilmore nirik 17:05:58 zodbot Current chairs: Evolution bstinson dgilmore nirik smooge 17:05:59 Evolution present. 17:06:05 smooge #topic Robot Roll Call 17:06:08 smooge here 17:06:11 maxamillion here 17:06:13 avij hi 17:06:35 smooge sorry guys... was dealing with a sick pup and missed the timer 17:06:37 nirik somewhat here 17:06:48 maxamillion smooge: sorry to hear that, hope everything is alright 17:06:55 dgilmore hola 17:07:16 Evolution smooge: back feeling better? 17:07:39 smooge yep. 17:08:45 smooge #topic Next Orphan Day 17:09:21 dgilmore smooge: reminds me 17:09:22 dgilmore https://fedorahosted.org/rel-eng/ticket/5963#comment:7 17:09:38 smooge So I see tyll_ has put out another set of orphaned packages. The issue that they weren't caught before was that he wasn't looking at packages that had been retired in rawhide 17:10:43 smooge so I think we can answer that with a yes.. and we will do it in X days? 17:11:01 smooge How does the 22nd of January sound for Orphan Day? 17:11:14 nirik sure, sounds fine. 17:11:16 dgilmore works for me 17:11:18 dgilmore yes 17:11:22 bstinson +1 17:11:29 Evolution yeah, that's safe enough prior to fosdem 17:11:39 Evolution +1 here 17:11:58 smooge +1 from me 17:12:32 smooge #agreed Next orphan removal day is 2015-01-22 +5 -0 17:13:18 smooge #topic Website Cleanup? [Is smooge every gonna start?] 17:14:32 smooge well hopefully soon 17:14:40 smooge sorry dog needed to go outside 17:15:09 smooge I have stuff started to be written, but haven't had enough time without interruptions to concentrate on it 17:15:16 smooge same story for everyone else I expect 17:15:38 smooge #topic FOSDOM EPEL/CentOS meeting 17:15:58 * nirik will not be there, but will be available via irc/email for questions, etc 17:16:02 smooge Evolution, do you know what the current plans on this are? I am expecting it will be BOF instead of a dinner 17:16:17 * maxamillion will not be there either but pending schedules will be available on irc/email 17:16:46 smooge and it looks like it will be mostly getting stories from users about what they want in EPEL 17:16:53 Evolution smooge: yeah. that's the current idea 17:17:03 Evolution 20 people at a dinner isn't meaningful 17:17:15 Evolution we're going to attempt to comandeer a bof area 17:18:34 * quaid leaps in for a few minutes 17:19:16 quaid smooge: yeah, getting user stories together basically aiui; we need to have a better idea from the CentOS perspective what people want, so we know what to work on, ask for, bargain for, build, etc. 17:19:22 smooge ok I expect it will be less than 20 people since possible free food/beer is gone :). BUt then again the Red Hat BOF at USENIX was 40-60 people when 10 listed they would come up 17:19:55 quaid the folks who've responded seem to have an investment beyond free-beer :) and this is Belgium, there might be beer anyway :) 17:20:38 smooge thanks 17:20:55 smooge do you guys have a date for it? 17:21:25 Evolution I don't recall seeing a date offhand on the list, but I think we were trying to keep the same schedule as the dinner. 17:21:32 * dgilmore did book fosdem 17:21:45 dgilmore I will definitely be there 17:22:44 quaid dgilmore: looking forward to seeing you, been a long time 17:22:55 smooge and quaid maybe sometime this year we (various committee members) can have a working meeting after some direction? 17:23:06 quaid Evolution: that's a good question, I presumed it moved back to Sat afternoon for the event venue? 17:23:16 smooge various committee members + CentOS committee members 17:23:19 Evolution something to post to the list then. 17:23:26 Evolution for clarity at least. 17:23:46 quaid smooge: yeah, I asked KB if he wanted us all to have a Hangout before FOSDEM, but when I got the fuller scope on user stories, I realized it would be better after we had something solid to share; one of us will look to arrange a meeting in Feb then 17:24:06 quaid Evolution: good point, I don't think it's been addressed, yeah. 17:24:27 smooge quaid, thanks 17:25:43 quaid smooge: also, if no one objects, I plan to video the meeting itself (non-social parts), we can either share privately or publicly, depending (and I can always turn off the camera for a private story, etc.) 17:25:53 smooge ok I don't have anything I would like to pose at the meeting beyond the generals What is it being used for? Where are these people and how do we
Re: [EPEL-devel] Prosody XMPP CentOS EPEL latest package
On 01/16/2015 09:44 AM, Ram M wrote: I have been regular user of CENTOS 6.5 7. I need to know how can get the latest package of Prosody XMPP for CentOS. Currently I can get only prosody-0.8.2-7.el6.x86_64.rpm however I need to get Prosody 0.9.7. Please advice direct me to correct forum / Person. Distribution: CentOS 6 Repository: EPEL x86_64 Package name: prosody Package version: 0.8.2 Package architecture: x86_64 Package type: rpm Installed size: 709,99 KB Download size: 184,24 KB Binary package: prosody-0.8.2-7.el6.x86_64.rpm Source package: prosody-0.8.2-7.el6.src.rpm Rgds, ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel It's probably not upgraded for policy reasons. However, I wanted the newer version too. You can update the spec file of this SRPM, if 0.9.4 is not recent enough for you. Otherwise, just rebuild it: http://www.geofrogger.net/review/prosody-0.9.4-4.fc20.src.rpm http://zabbix.org/wiki/Docs/howto/rebuild_rpms Volker ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] Prosody XMPP CentOS EPEL latest package
On 2015-01-16, 17:52 GMT, Volker Fröhlich wrote: It's probably not upgraded for policy reasons. However, I wanted the newer version too. You can update the spec file of this SRPM, if 0.9.4 is not recent enough for you. Otherwise, just rebuild it: Instead of maintaining your own RPM on your own server, don't you want to take over the official package in Fedora/EPEL? It seems to me that we have no almost no XMPP server for EPEL-6, which seems to be kind of bad. Matěj ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
