Re: [EPEL-devel] [Extra Packages for Enterprise Linux] #8: EPEL-latest link rpm
#8: EPEL-latest link rpm -+ Reporter: smooge | Owner: epel-wranglers Type: enhancement | Status: new Priority: minor | Milestone: Component: Policy problem |Version: Resolution: | Keywords: -+ Changes (by ktdreyer): * cc: ktdreyer@… (added) -- Ticket URL: https://fedorahosted.org/epel/ticket/8#comment:3 Extra Packages for Enterprise Linux https://fedoraproject.org/wiki/EPEL Extra Packages for Enterprise Linux ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3454/rubygem-httpclient-2.4.0-2.el7 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3432/drupal7-7.32-1.el7 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3328/zarafa-7.1.11-1.el7 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3530/phpMyAdmin-4.2.10.1-1.el7 2 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3672/hostapd-2.3-1.el7 2 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3621/php-Smarty-3.1.21-1.el7 2 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3642/Pound-2.7-0.4.d.el7.1 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3664/konversation-1.5-7.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing ansible-inventory-grapher-1.0.1-2.el7 ansible-lint-1.0.4-1.el7 conky-manager-2.3.1-1.el7 dbus-sharp-0.7.0-11.el7 dbus-sharp-glib-0.5.0-9.el7 e3-2.8-6.el7 epson-inkjet-printer-escpr-1.4.3-1.1lsb3.2.el7 fex-1.20100416.2814-7.el7 geany-themes-1.24-2.el7 globus-authz-3.10-1.el7 globus-authz-callout-error-3.5-1.el7 globus-callout-3.13-1.el7 globus-common-15.26-1.el7 globus-ftp-client-8.13-1.el7 globus-ftp-control-5.12-1.el7 globus-gass-cache-9.5-1.el7 globus-gass-cache-program-6.5-1.el7 globus-gass-copy-9.12-1.el7 globus-gass-server-ez-5.7-1.el7 globus-gass-transfer-8.8-1.el7 globus-gatekeeper-10.8-1.el7 globus-gfork-4.7-1.el7 globus-gram-client-13.10-1.el7 globus-gram-client-tools-11.7-1.el7 globus-gram-job-manager-14.22-2.el7 globus-gram-job-manager-callout-error-3.5-1.el7 globus-gram-job-manager-condor-2.5-1.el7 globus-gram-job-manager-lsf-2.6-1.el7 globus-gram-job-manager-scripts-6.7-1.el7 globus-gram-job-manager-slurm-2.4-2.el7 globus-gram-protocol-12.12-1.el7 globus-gridftp-server-7.12-1.el7 globus-gridmap-callout-error-2.4-1.el7 globus-gridmap-verify-myproxy-callout-2.7-1.el7 globus-gsi-callback-5.6-1.el7 globus-gsi-cert-utils-9.10-1.el7 globus-gsi-credential-7.7-1.el7 globus-gsi-openssl-error-3.5-1.el7 globus-gsi-proxy-core-7.7-1.el7 globus-gsi-proxy-ssl-5.7-1.el7 globus-gsi-sysconfig-6.8-1.el7 globus-gss-assist-10.12-1.el7 globus-gssapi-error-5.4-1.el7 globus-gssapi-gsi-11.13-1.el7 globus-io-10.12-1.el7 globus-openssl-module-4.6-1.el7 globus-proxy-utils-6.9-1.el7 globus-rsl-10.9-1.el7 globus-scheduler-event-generator-5.7-1.el7 globus-xio-4.15-1.el7 globus-xio-gridftp-driver-2.8-1.el7 globus-xio-gsi-driver-3.6-1.el7 gudev-sharp-0.1-14.el7 holland-1.0.10-3.el7 konversation-1.5-7.el7 libfaketime-0.9.6-1.el7 libffado-2.1.0-4.el7 nfs-ganesha-2.1.0-11.el7 nodejs-seq-0.3.5-2.el7 nodejs-silent-npm-registry-client-0.0.1-1.el7 nodejs-strscanner-0.0.8-2.el7 perl-qpid-0.30-1.el7 php-horde-Horde-Core-2.15.0-2.el7 php-horde-Horde-Dav-1.1.1-1.el7 php-horde-Horde-History-2.3.2-1.el7 php-horde-Horde-Secret-2.0.4-1.el7 php-horde-Horde-Test-2.4.5-1.el7 php-horde-horde-5.2.2-1.el7 php-horde-imp-6.2.3-1.el7 php-horde-ingo-3.2.2-1.el7 php-horde-kronolith-4.2.3-1.el7 php-horde-nag-4.2.2-1.el7 php-horde-turba-4.2.3-1.el7 php-horde-wicked-2.0.2-1.el7 php-react-promise-2.1.0-1.el7 python-libqutrub-1.0-3.el7 python-naftawayh-0.2-4.el7 python-qpid-0.30-1.el7 python-qpid_messaging-0.30-1.el7 qpid-cpp-0.30-3.el7 rubygem-qpid_messaging-0.30.0-1.el7 ssmtp-2.64-14.el7 taglib-sharp-2.0.3.7-11.el7 xfce4-netload-plugin-1.2.0-6.el7 xournal-0.4.8-3.el7 Details about builds: ansible-inventory-grapher-1.0.1-2.el7 (FEDORA-EPEL-2014-3678) Creates graphs representing ansible inventory Update Information: Initial package References: [ 1 ] Bug #1146929 - Review Request: ansible-inventory-grapher - Creates graphs representing ansible inventory https://bugzilla.redhat.com/show_bug.cgi?id=1146929 ansible-lint-1.0.4-1.el7 (FEDORA-EPEL-2014-3711) Best practices checker for Ansible Update Information: Initial package References: [ 1 ] Bug #1146928 - Review Request: ansible-lint - Best practices checker for Ansible https://bugzilla.redhat.com/show_bug.cgi?id=1146928
Re: [EPEL-devel] epel-release: consider adding %epel macro ?
Rex Dieter wrote:
I'd like to be able to conditionalize some package features depending on
if
epel repo is enabled or not. One way to accomplish that goal is if epel-
release defined some macro, say, something like %{epel}, similar to
%{feodra} or %{rhel}
(I don't care what the macro is named, as long as the bikeshed remains
blue)
My primary motivation is to simplify the task of doing something like:
https://copr.fedoraproject.org/coprs/rdieter/kde4/
where I currently end up patching various .spec files (mostly to enable
features due to having epel available), and I'd like to be able to
minimize having to do that.
As a followup, it would appear that COPR is starting to define macros:
copr_projectname
copr_username
(as well as redefining 'vendor')
So the urgency to do this in epel specifically is less, but I still think it
is a good idea.
-- Rex
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] epel-release: consider adding %epel macro ?
Rex Dieter wrote:
Rex Dieter wrote on Oct 16:
I'd like to be able to conditionalize some package features depending on
if
epel repo is enabled or not. One way to accomplish that goal is if epel-
release defined some macro, say, something like %{epel}, similar to
%{feodra} or %{rhel}
(I don't care what the macro is named, as long as the bikeshed remains
blue)
My primary motivation is to simplify the task of doing something like:
https://copr.fedoraproject.org/coprs/rdieter/kde4/
where I currently end up patching various .spec files (mostly to enable
features due to having epel available), and I'd like to be able to
minimize having to do that.
thoughts?
ping, any comment or objection?
I'll work on a patch for epel-release to implement a %{epel} macro, in
case anyone was waiting for implementation details.
Here's the epel-release patch as promised (epel7 branch), attached.
-- RexFrom 6208a680f648b1ac0e0eb3582d5d85a76cdb48bd Mon Sep 17 00:00:00 2001
From: Rex Dieter rdie...@math.unl.edu
Date: Fri, 31 Oct 2014 07:36:53 -0500
Subject: [PATCH] implement %epel macro
---
epel-release.spec |9 -
macros.epel |3 +++
2 files changed, 11 insertions(+), 1 deletions(-)
create mode 100644 macros.epel
diff --git a/epel-release.spec b/epel-release.spec
index 9427b01..c0c0965 100644
--- a/epel-release.spec
+++ b/epel-release.spec
@@ -1,6 +1,6 @@
Name: epel-release
Version:7
-Release:2
+Release:3
Summary:Extra Packages for Enterprise Linux repository configuration
Group: System Environment/Base
@@ -14,6 +14,7 @@ Source0:http://download.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-7
Source1:GPL
Source2:epel.repo
Source3:epel-testing.repo
+Source4:macros.epel
BuildArch: noarch
Requires: redhat-release = %{version}
@@ -41,6 +42,7 @@ install -Dpm 644 %{SOURCE0} \
install -dm 755 $RPM_BUILD_ROOT%{_sysconfdir}/yum.repos.d
install -pm 644 %{SOURCE2} %{SOURCE3} \
$RPM_BUILD_ROOT%{_sysconfdir}/yum.repos.d
+install -pm -D ${SOURCE3} $RPM_BUILD_ROOT/usr/lib/rpm/macros.d/macros.epel
%clean
rm -rf $RPM_BUILD_ROOT
@@ -50,9 +52,14 @@ rm -rf $RPM_BUILD_ROOT
%doc GPL
%config(noreplace) /etc/yum.repos.d/*
/etc/pki/rpm-gpg/*
+/usr/lib/rpm/macros.d/macros.epel
+
%changelog
+* Fri Oct 31 2014 Rex Dieter rdie...@fedoraproject.org 7-3
+- implement %%epel macro
+
* Tue Sep 02 2014 Kevin Fenzi ke...@scrye.com 7-2
- Make repo files config(noreplace). Fixes bug #1135576
diff --git a/macros.epel b/macros.epel
new file mode 100644
index 000..fb4413f
--- /dev/null
+++ b/macros.epel
@@ -0,0 +1,3 @@
+# epel macros
+
+%epel %{?rhel}%{!?:rhel:7}
--
1.7.1
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] epel-release: consider adding %epel macro ?
On Fri, Oct 31, 2014 at 5:42 AM, Rex Dieter rdie...@math.unl.edu wrote:
Rex Dieter wrote:
+%epel %{?rhel}%{!?:rhel:7}
typo alert ^^ (in the second part), but hopefully you get the idea.
Or, if you'd rather not depend on %rhel macro, and just hard-code to 7,
that
would be fine too.
The approach looks good to me.
The patch needs a little work though: besides the typo you mentioned, the
install line is copying the wrong SOURCE file.
I see %rhel is present on CentOS -- I can't speak to other rebuilds though.
It would be nice to verify that.
Bonus points for a second patch to remove all the extra trailing whitespace
happening in this spec :)
-Jeff
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] EPEL 7 cloud-initramfs-tools/dracut-modules-growroot
On 10/31/2014 4:44 AM, Juerg Haefliger wrote: On Thu, Oct 30, 2014 at 8:30 PM, Fred Wittekind r...@twister.dyndns.org mailto:r...@twister.dyndns.org wrote: On 8/7/2014 1:29 PM, Fred Wittekind wrote: On 8/5/2014 5:55 PM, Juerg Haefliger wrote: Hi Fred, On Tue, Aug 5, 2014 at 10:33 PM, Fred Wittekind r...@twister.dyndns.org mailto:r...@twister.dyndns.org wrote: How soon might a el7 version of this package be available? I can see that there is already a bug entered in bugzilla for it (https://bugzilla.redhat.com/show_bug.cgi?id=1117416) and it's listed here https://apps.fedoraproject.org/packages/cloud-initramfs-tools (with no release yet). I just started to look at this today. I hope to have something ready for testing later this week. ...Juerg I tried the patch in the bug report linked above, and it it tries to work. boot.log shows that it is unable to write to the partition table. Have you gotten far enough in your testing to have any results, maybe the same as mine? Fred Any progress towards a release? Not really. I looked into it but it doesn't seem to be a trivial thing to do with systemd. RHEL7 ships with a kernel that is new enough and is capable of online resizing partitions, so the initrd hack is not required. Is there a specific reason why you need this package in EPEL7? I've built the package with the patch provided in the bugreport, and it tries, but, it fails to be able to write to the partition table, I get the same results command line. I've tried with and without SELinux. I am looking for a automated way to do this, on first boot after a drive resize. So far I haven't found a manual way to do it that works. I know I could create a second PV, and add it to a VG, and then resize the LV, but, would prefer not to do it this way, seems messy. Fred ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] [Extra Packages for Enterprise Linux] #22: Meeting Agenda for 2014-10-10
#22: Meeting Agenda for 2014-10-10 --+ Reporter: smooge | Owner: smooge Type: defect | Status: closed Priority: major| Milestone: Component: Package request |Version: Resolution: worksforme | Keywords: --+ Changes (by smooge): * status: new = closed * resolution: = worksforme -- Ticket URL: https://fedorahosted.org/epel/ticket/22#comment:1 Extra Packages for Enterprise Linux https://fedoraproject.org/wiki/EPEL Extra Packages for Enterprise Linux ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] [Extra Packages for Enterprise Linux] #2: How to handle systemd service activation defaults in EPEL7
#2: How to handle systemd service activation defaults in EPEL7 -+ Reporter: orion | Owner: epel-wranglers Type: task| Status: new Priority: major | Milestone: EPEL-7 Component: Policy problem |Version: Resolution: | Keywords: -+ Comment (by smooge): +1 to put in EPEL-release -- Ticket URL: https://fedorahosted.org/epel/ticket/2#comment:9 Extra Packages for Enterprise Linux https://fedoraproject.org/wiki/EPEL Extra Packages for Enterprise Linux ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] [Extra Packages for Enterprise Linux] #4: Decide on criteria to unretire packages.
#4: Decide on criteria to unretire packages. -+ Reporter: till| Owner: epel-wranglers Type: defect | Status: new Priority: major | Milestone: Component: Policy problem |Version: Resolution: | Keywords: -+ Comment (by smooge): Agreed by bstinson, Evolution, smooge, nirik a) smooge volunteers to be a reviewer who will do reviews of needed packages on Friday afternoons after I have been retrained. b) We have a bug-killing day once a month where CentOS packagers help c) We expect all packages that have been removed from the collection over 14 days to be re-reviewed. [This is to match upstream FESCO policy] -- Ticket URL: https://fedorahosted.org/epel/ticket/4#comment:3 Extra Packages for Enterprise Linux https://fedoraproject.org/wiki/EPEL Extra Packages for Enterprise Linux ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] [Extra Packages for Enterprise Linux] #4: Decide on criteria to unretire packages.
#4: Decide on criteria to unretire packages. -+ Reporter: till| Owner: epel-wranglers Type: task| Status: closed Priority: major | Milestone: Component: Policy problem |Version: Resolution: fixed | Keywords: -+ Changes (by smooge): * resolution: = fixed * type: defect = task * status: new = closed -- Ticket URL: https://fedorahosted.org/epel/ticket/4#comment:4 Extra Packages for Enterprise Linux https://fedoraproject.org/wiki/EPEL Extra Packages for Enterprise Linux ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] [Extra Packages for Enterprise Linux] #8: EPEL-latest link rpm
#8: EPEL-latest link rpm -+ Reporter: smooge | Owner: epel-wranglers Type: enhancement | Status: new Priority: minor | Milestone: Component: Policy problem |Version: Resolution: | Keywords: -+ Comment (by smooge): Will start looking at what needs to be done in MASH to get this working since this will be helpful to multiple projects. -- Ticket URL: https://fedorahosted.org/epel/ticket/8#comment:4 Extra Packages for Enterprise Linux https://fedoraproject.org/wiki/EPEL Extra Packages for Enterprise Linux ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] [Extra Packages for Enterprise Linux] #8: EPEL-latest link rpm
#8: EPEL-latest link rpm -+-- Reporter: smooge | Owner: smooge Type: enhancement | Status: accepted Priority: minor | Milestone: Component: Policy problem |Version: Resolution: | Keywords: -+-- Changes (by smooge): * status: new = accepted * owner: epel-wranglers = smooge -- Ticket URL: https://fedorahosted.org/epel/ticket/8#comment:5 Extra Packages for Enterprise Linux https://fedoraproject.org/wiki/EPEL Extra Packages for Enterprise Linux ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Font issues in F21
Hi, On 10/30/2014 11:01 PM, Orion Poplawski wrote: As a fix for this: https://bugzilla.redhat.com/show_bug.cgi?id=1046341 The following symbolic link was added to xorg-x11-font-utils: lrwxrwxrwx. 1 root root 12 Aug 18 23:08 /usr/share/fonts/X11 - ../X11/fonts This causes fontconfig to search the full X11 hierarchy whereas before it only searched the Type1 and TTF subdirs. This fix has triggered: https://bugzilla.redhat.com/show_bug.cgi?id=1158468 and I suspect other issues will crop up as well. Can some font experts weigh in on how to properly solve the first issue without triggering the second? The first issue can be fixed by patching luit to search under /usr/share/X11/fonts rather then /usr/share/fonts/X11, my thinking behind adding the symlink was that their will likely be other apps with the same problem as luit. So I asked my fellow graphics team members about why we were using /usr/share/X11/fonts instead of /usr/share/fonts/X11 in the first place, and there did not seem be a special reason, so I added the symlink. Since the symlink is clearly causing issues I'll do an update removing the symlink and another update fixing luit, and push them as one update in bodhi, which should resolve both issues. As said their will likely be more cases of the luit problem hiding elsewhere, but since the symlink is causing issues, we will need to fix those on a case by case basis. Regards, Hans -- 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 Perl from minimal build root
Dne 30.10.2014 v 18:57 Matěj Cepl napsal(a): On 2014-10-30, 14:04 GMT, Chris Adams wrote: Once upon a time, Vít Ondruch vondr...@redhat.com said: I am pretty sure, that this was already discussed many times, but I proposed to drop the seemingly last dependency of RPM on Perl in this [1] ticket and hence Perl from minimal buildroot (unless it will be pulled in by some other packages). The RPM maintainers as well as Perl maintainers seems to be in favor of this change. One other thing to check for is spec files that use perl (maybe when the resulting package does not). I know I've written spec files that use perl to fix things and what not. Sure, it should be checked, but not that it would free those packages from being broken. Let me quote https://fedoraproject.org/wiki/Packaging:Guidelines Note: If you call perl or python in your spec file (and it is not already a BuildRequires for the package), you need to explicitly add a BuildRequires for perl or python. Moreover, perl is not (and I believe it never was) in the list in https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2 Matěj This is really good point Matěj, thanks for bringing this up! 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
Re: Remove Perl from minimal build root
Dne 31.10.2014 v 00:37 Nico Kadel-Garcia napsal(a): On Thu, Oct 30, 2014 at 3:01 PM, Richard Hughes hughsi...@gmail.com wrote: On 30 October 2014 14:02, Vít Ondruch vondr...@redhat.com wrote: If you have any comments, please speak up now. No comment, just lots of thanks! Richard I tried this, *twice*. Once way, way back when with Red Hat 6.x (not RHEL 6.x, Red Hat 6.x, think back to around 2001). It was not pleasant work, there are a *lot* of hidden dependencies. And once about 6 years ago to to shrink and secure a CentOS build, along with ripping out gcc and build tools. It really wasn't pretty to watch, and I don't recommend burning your timne on this. I wound up writing a lot of plugins to work around the dependencies, and it rapidly exceeded the expense and time of just installing perl. I understand, but fortunately time is changing and some things are better now then they used to be. I can't say this will be successful, but as I said, RPM, which was the usual excuse, is Perl independent, with the last exception I suggest to get rid off and I believe that Perl team can now do bootstrap and rebuild of all Perl packages, which should help with testing prior this lands, so all these makes me optimistic. 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
Re: Font issues in F21
De: Hans de Goede hdego...@redhat.com Hi, On 10/30/2014 11:01 PM, Orion Poplawski wrote: Can some font experts weigh in on how to properly solve the first issue without triggering the second? The first issue can be fixed by patching luit to search under /usr/share/X11/fonts rather then /usr/share/fonts/X11, my thinking behind adding the symlink was that their will likely be other apps with the same problem as luit. The root of the problem of course is that luit and other similar apps have still not be updated to use fontconfig properly, 12 years after it was introduced. And every time someone adds a hack to avoid fixing those apps it breaks something else. I personnaly think that short of making them fail fast and hard nothing will convince their upstreams to look at fontconfig and till then they will continue to produce side effects on the rest of the system. You get all the problems that caused fontconfig to be written in the first place, without any hope of improvement (since the solution is to use fontconfig, it was written to handle font discovery sanely). Regards, -- 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: Font issues in F21
Hi, On 10/31/2014 10:20 AM, nicolas.mail...@laposte.net wrote: De: Hans de Goede hdego...@redhat.com Hi, On 10/30/2014 11:01 PM, Orion Poplawski wrote: Can some font experts weigh in on how to properly solve the first issue without triggering the second? The first issue can be fixed by patching luit to search under /usr/share/X11/fonts rather then /usr/share/fonts/X11, my thinking behind adding the symlink was that their will likely be other apps with the same problem as luit. The root of the problem of course is that luit and other similar apps have still not be updated to use fontconfig properly, 12 years after it was introduced. And every time someone adds a hack to avoid fixing those apps it breaks something else. I personnaly think that short of making them fail fast and hard nothing will convince their upstreams to look at fontconfig and till then they will continue to produce side effects on the rest of the system. You get all the problems that caused fontconfig to be written in the first place, without any hope of improvement (since the solution is to use fontconfig, it was written to handle font discovery sanely). Erm, luit is not looking for font files at all, it is an encoding translator, as such it wants the encoding files found under /usr/share/X11/fonts/encodings. Which it expects to be under /usr/share/fonts/X11/encodings. Fixing this in luit is trivial, but I was afraid other apps would have similar hardcoded paths, so the symlink seemed like a good idea. Sorry for the problems I've caused by adding the X11 symlink I'll push an updated package reverting it asap. Regards, Hans -- 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: 20141031 changes
Compose started at Fri Oct 31 05:15:03 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [alienarena] alienarena-7.66-4.fc22.i686 requires libode-double.so.3 [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [collectd] collectd-onewire-5.4.1-10.fc22.i686 requires libowcapi-2.9.so.7 [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so [debconf] debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2) [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [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 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires libLLVM-3.4.so dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [gcc-python-plugin] gcc-python2-debug-plugin-0.13-1.fc22.1.i686 requires gcc = 0:4.9.1-11.fc22 gcc-python2-plugin-0.13-1.fc22.1.i686 requires gcc = 0:4.9.1-11.fc22 gcc-python3-debug-plugin-0.13-1.fc22.1.i686 requires gcc = 0:4.9.1-11.fc22 gcc-python3-plugin-0.13-1.fc22.1.i686 requires gcc = 0:4.9.1-11.fc22 [gdesklet-SlideShow] gdesklet-SlideShow-0.9-16.fc21.noarch requires gdesklets [gdesklets-citation] gdesklets-citation-2.0-3.20120702git355e2ee.fc19.noarch requires gdesklets [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [ghc-hjsmin] ghc-hjsmin-0.1.4.7-3.fc22.i686 requires libHSoptparse-applicative-0.9.0-ghc7.6.3.so [glances] glances-2.1.2-2.fc22.noarch requires python-psutil = 0:2.0.0 [gnome-shell-extensions] gnome-shell-extension-common-3.15.1-1.fc22.noarch requires gnome-shell = 0:3.15.1 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [iwhd] iwhd-1.6-11.fc22.i686 requires libmongoclient.so [kmid2] kmid2-2.4.0-7.fc22.i686 requires libdrumstick-file.so.0 kmid2-2.4.0-7.fc22.i686 requires libdrumstick-alsa.so.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3 libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.i686 requires fuse-unionfs ltsp-server-5.4.5-8.fc21.i686 requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.i686 requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.i686 requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.i686 requires vala 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [nwchem] nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1 [ocaml-cairo] 1:ocaml-cairo-1.2.0-0.18.git08b40192975.fc22.i686 requires ocaml(Gdk) = 0:f378ca801294b82336e5c6c17354aafa [ocaml-camlimages] ocaml-camlimages-4.1.0-8.fc22.i686 requires ocaml(Gdk) = 0:f378ca801294b82336e5c6c17354aafa ocaml-camlimages-4.1.0-8.fc22.i686 requires ocaml(GDraw) = 0:deb7a227126b52043bc5519b151161a3 [ocaml-cryptokit] ocaml-cryptokit-1.9-6.fc22.i686 requires ocaml(Obj) = 0:31e1329a4c3d9c2947b31f79b700fcfd [ocaml-mysql] ocaml-mysql-1.1.2-4.fc22.i686 requires ocaml(Obj) = 0:31e1329a4c3d9c2947b31f79b700fcfd [ocaml-ocamlnet] ocaml-ocamlnet-3.7.4-9.fc22.i686 requires ocaml(GdkEvent) = 0:888bfbb798af9ae801076132037be1fb ocaml-ocamlnet-3.7.4-9.fc22.i686 requires ocaml(Gdk) = 0:f378ca801294b82336e5c6c17354aafa ocaml-ocamlnet-3.7.4-9.fc22.i686 requires ocaml(GObj) = 0:aaf1de74e8c9dee7550f58369abca98b ocaml-ocamlnet-3.7.4-9.fc22.i686 requires ocaml(GDraw) = 0:deb7a227126b52043bc5519b151161a3 ocaml-ocamlnet-3.7.4-9.fc22.i686 requires
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 02:47 AM, Matthew Miller wrote: Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Found ordering cycle on basic.target/start Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Breaking ordering cycle by deleting job sysinit.target/start Matthew, are you showing only messages at loglevel warning and higher? Because in between these two lines I'd expect to see some Found dependency on service/job_type at loglevel info. Regards, Michal -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, Oct 31, 2014 at 12:33:20PM +0100, Michal Schmidt wrote: Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Found ordering cycle on basic.target/start Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Breaking ordering cycle by deleting job sysinit.target/start are you showing only messages at loglevel warning and higher? Because in between these two lines I'd expect to see some Found dependency on service/job_type at loglevel info. That's everything with _COMM=systemd since boot. Possibly loglevel itself is set low? I'll enable more debugging and post 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
F-21 Branched report: 20141031 changes
Compose started at Fri Oct 31 07:15:02 UTC 2014 Broken deps for armhfp -- [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gdesklet-SlideShow] gdesklet-SlideShow-0.9-16.fc21.noarch requires gdesklets [gdesklets-citation] gdesklets-citation-2.0-3.20120702git355e2ee.fc19.noarch requires gdesklets [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django 0:1.5 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [openvas-client] openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6 [perl-RT-Authen-ExternalAuth] perl-RT-Authen-ExternalAuth-0.11-5.fc21.noarch requires rt3 [perl-RT-Extension-CommandByMail] perl-RT-Extension-CommandByMail-0.07-10.fc21.noarch requires perl(RT::Interface::Email) [pipelight-selinux] pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight [pootle] pootle-2.1.6-8.fc21.noarch requires python-django14 [python-askbot-fedmsg] python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot [python-coffin] python-coffin-0.3.7-3.fc21.noarch requires python-django14 [python-django-addons] python-django-addons-0.6.6-2.fc21.noarch requires python-django14 [python-django-longerusername] python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21.noarch requires python-django14 [rubygem-linecache19] rubygem-linecache19-0.5.13-6.fc20.armv7hl requires libruby.so.2.0
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, Oct 31, 2014 at 07:39:42AM -0400, Matthew Miller wrote: On Fri, Oct 31, 2014 at 12:33:20PM +0100, Michal Schmidt wrote: Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Found ordering cycle on basic.target/start Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Breaking ordering cycle by deleting job sysinit.target/start are you showing only messages at loglevel warning and higher? Because in between these two lines I'd expect to see some Found dependency on service/job_type at loglevel info. That's everything with _COMM=systemd since boot. Possibly loglevel itself is set low? I'll enable more debugging and post that. Oct 31 07:42:29 ubik systemd[1]: Found ordering cycle on basic.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on sysinit.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-update-utmp.service/verify-active Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-tmpfiles-setup.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-journal-flush.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on remote-fs.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on remote-fs-pre.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on nfs-client.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on gssproxy.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on basic.target/start Oct 31 07:42:29 ubik systemd[1]: Breaking ordering cycle by deleting job systemd-update-utmp.service/verify-active Oct 31 07:42:29 ubik systemd[1]: Job systemd-update-utmp.service/verify-active deleted to break ordering cycle starting with basic.target/start Oct 31 07:42:29 ubik systemd[1]: Deleting job systemd-update-utmp-runlevel.service/start as dependency of job systemd-update-utmp.service/verify-active Oct 31 07:42:29 ubik systemd[1]: Found ordering cycle on basic.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on sysinit.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on auditd.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-tmpfiles-setup.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-journal-flush.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on remote-fs.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on remote-fs-pre.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on nfs-client.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on gssproxy.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on basic.target/start Oct 31 07:42:29 ubik systemd[1]: Breaking ordering cycle by deleting job auditd.service/start Oct 31 07:42:29 ubik systemd[1]: Job auditd.service/start deleted to break ordering cycle starting with basic.target/start Oct 31 07:42:29 ubik systemd[1]: Found ordering cycle on basic.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on sysinit.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-tmpfiles-setup.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-journal-flush.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on remote-fs.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on remote-fs-pre.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on nfs-client.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on gssproxy.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on basic.target/start Oct 31 07:42:29 ubik systemd[1]: Breaking ordering cycle by deleting job systemd-tmpfiles-setup.service/start Oct 31 07:42:29 ubik systemd[1]: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with basic.target/start Oct 31 07:42:29 ubik systemd[1]: Looking at job sshd-keygen.service/stop conflicted_by=no Oct 31 07:42:29 ubik systemd[1]: Looking at job sshd-keygen.service/start conflicted_by=no Oct 31 07:42:29 ubik systemd[1]: Fixing conflicting jobs sshd-keygen.service/stop,sshd-keygen.service/start by deleting job sshd-keygen.service/stop Oct 31 07:42:29 ubik systemd[1]: Looking at job plymouth-quit.service/stop conflicted_by=yes Oct 31 07:42:29 ubik systemd[1]: Looking at job plymouth-quit.service/start conflicted_by=no Oct 31 07:42:29 ubik systemd[1]: Fixing conflicting jobs plymouth-quit.service/stop,plymouth-quit.service/start by deleting job plymouth-quit.service/start Oct 31 07:42:29 ubik systemd[1]: Looking at job gdm.service/start conflicted_by=no Oct 31 07:42:29 ubik systemd[1]: Looking at job gdm.service/stop conflicted_by=no Oct 31 07:42:29 ubik systemd[1]: Fixing conflicting jobs gdm.service/start,gdm.service/stop by deleting job gdm.service/stop Oct 31 07:42:29 ubik systemd[1]: Looking at job getty@tty1.service/stop conflicted_by=yes Oct 31 07:42:29 ubik systemd[1]: Looking at job getty@tty1.service/start
Re: Remove Perl from minimal build root
On 2014-10-31, 08:54 GMT, Vít Ondruch wrote: This is really good point Matěj, thanks for bringing this up! It’s like alcoholism: once lawyer, always lawyer, I am afraid. Best, Matěj -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
By the way, sudo systemctl start systemd-tmpfiles-setup sudo rm /var/run/nologin sudo systemctl restart gdm got me to a functioning GNOME desktop. -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 12:57 PM, Matthew Miller wrote: Oct 31 07:42:29 ubik systemd[1]: Found ordering cycle on basic.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on sysinit.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-update-utmp.service/verify-active Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-tmpfiles-setup.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-journal-flush.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on remote-fs.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on remote-fs-pre.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on nfs-client.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on gssproxy.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on basic.target/start Oct 31 07:42:29 ubik systemd[1]: Breaking ordering cycle by deleting job systemd-update-utmp.service/verify-active This ordering cycle was introduced recently by changes in nfs-utils's unit files when nfs-client.target got an After dependency on gssproxy. nfs-client.target wants to be started before any remote filesystems are mounted (which is before basic.target). gssproxy.service has default dependencies, so it wants to start quite late during boot (after basic.target). [CC Steve.] Regards, Michal -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, 31.10.14 07:57, Matthew Miller (mat...@fedoraproject.org) wrote: On Fri, Oct 31, 2014 at 07:39:42AM -0400, Matthew Miller wrote: On Fri, Oct 31, 2014 at 12:33:20PM +0100, Michal Schmidt wrote: Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Found ordering cycle on basic.target/start Oct 30 21:39:47 ubik.home.mkmiller.org systemd[1]: Breaking ordering cycle by deleting job sysinit.target/start are you showing only messages at loglevel warning and higher? Because in between these two lines I'd expect to see some Found dependency on service/job_type at loglevel info. That's everything with _COMM=systemd since boot. Possibly loglevel itself is set low? I'll enable more debugging and post that. Oct 31 07:42:29 ubik systemd[1]: Found ordering cycle on basic.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on sysinit.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-update-utmp.service/verify-active Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-tmpfiles-setup.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on systemd-journal-flush.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on remote-fs.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on remote-fs-pre.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on nfs-client.target/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on gssproxy.service/start Oct 31 07:42:29 ubik systemd[1]: Found dependency on basic.target/start So the problem appears to be that gssproxy.service been ordered before remote-fs-pre.target. That target is ordered before basic.target. However gssproxy.service also is ordered after basic.target (simply because all services by default are ordered before basic.target, unless they explicitly specify DefaultDependencies=no), hence there's an ordering cycle. Most likely some NFS maintainers tried to move gss-proxy.service into the early boot, and didn't set DefaultDependencies=no. That said, services running in early boot must be written in a specific style (i.e. not assume /var to be around, and suchlike), I do wonder if gssproxy is ready for that. Anyway, long story short: file a bug against the gssproxy package. Lennart -- Lennart Poettering, 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
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, Oct 31, 2014 at 01:44:27PM +0100, Michal Schmidt wrote: This ordering cycle was introduced recently by changes in nfs-utils's unit files when nfs-client.target got an After dependency on gssproxy. Are you sure? Looks like I last updated nfs-utils on Oct 26th, and I've rebooted several times since then without incident — it's only after this last update that the problem occured. I mean, I believe you that this is a problem, but did something else change too? -- 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Wed, 2014-10-15 at 12:28 +0200, Vít Ondruch wrote: Nevertheless, I am still unsure how to proceed with RubyGems. Should I ship the bundled certificates again? Or should I wait until somebody notices? Sorry for my late reply, because I didn't have a good suggestion earlier. We should work with the upstream OpenSSL and the GnuTLS projects, and motivate them to implement more advanced path building. This would be a long term project. For the short term, I'd like to suggest the following strategy: All legacy root CA certificates, which seem to be required for full compatibility with either OpenSSL or GnuTLS, will continue to be included and enabled in the ca-certificates package. For users who are willing to accept the breakage and prefer using the latest trust, only, we provide a mechanism to disable the legacy trust. I've described the proposed approach in more detail at https://bugzilla.redhat.com/show_bug.cgi?id=1158197 I've pushed experimental packages with this implementation to Rawhide and updates-testing for Fedora 21. I have disabled the karma automatism, because I'll be offline for the next 2 weeks, and don't want things to go live while I'm away. I think it will be helpful to collect test feedback during that time, and see if it's suitable, and make a ship/no-ship decision of this approach later. So, to answer Vít's original question: I'd prefer if RubyGems didn't ship its own copy. I think our recent achievement that all software packages on a system use the same (default) set of trusted CA certificates is a good improvement, and I think we should keep it. Thanks Kai -- 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 31 October 2014 15:00 UTC on #fedora-meeting
Agenda: - Status buildrequires cleanup work (davids nils!) - Update on factory-reset work - Docker update - Phil on PTO for 3 weeks - 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 02:03 PM, Matthew Miller wrote: On Fri, Oct 31, 2014 at 01:44:27PM +0100, Michal Schmidt wrote: This ordering cycle was introduced recently by changes in nfs-utils's unit files when nfs-client.target got an After dependency on gssproxy. Are you sure? Looks like I last updated nfs-utils on Oct 26th, and I've rebooted several times since then without incident — it's only after this last update that the problem occured. I mean, I believe you that this is a problem, but did something else change too? Maybe you already had an ordering cycle on Oct 26, but different units were chosen for deletion when breaking the cycle, and by luck it had fewer directly observable consequences. Could you check older logs for ordering cycles? Michal -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, Oct 31, 2014 at 02:15:45PM +0100, Michal Schmidt wrote: Maybe you already had an ordering cycle on Oct 26, but different units were chosen for deletion when breaking the cycle, and by luck it had fewer directly observable consequences. Could you check older logs for ordering cycles? Yeah, I was just doing that, and there's no ordering cycle logged before late last night (e.g. the ill-fated reboot). That said, as you expected, disabling nfs-client.target does make the system boot successfully. I'm still getting a problem with dev-mqueue.mount, though: Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount: Directory /dev/mqueue to mount over is not empty, mounting anyway. Oct 31 09:19:46 ubik mount[4484]: mount: mount point /dev/mqueue does not exist Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount mount process exited, code=exited status=32 Oct 31 09:19:46 ubik systemd[1]: Failed to mount POSIX Message Queue File System. On a related but different note — is there a way to detect potential ordering cycles from a set of RPMs on disk (possibly installed in a chroot or something) _without_ actually booting? Maybe we could add a taskotron check for that for packages with changes to systemd unit files. (I realize that what is enabled on people's systems will have an impact, but we could check against a set of defaults at least.) -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 02:30 PM, Matthew Miller wrote: Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount: Directory /dev/mqueue to mount over is not empty, mounting anyway. Oct 31 09:19:46 ubik mount[4484]: mount: mount point /dev/mqueue does not exist Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount mount process exited, code=exited status=32 Oct 31 09:19:46 ubik systemd[1]: Failed to mount POSIX Message Queue File System. I saw this too, but didn't look into it. On a related but different note — is there a way to detect potential ordering cycles from a set of RPMs on disk (possibly installed in a chroot or something) _without_ actually booting? Maybe we could add a taskotron check for that for packages with changes to systemd unit files. (I realize that what is enabled on people's systems will have an impact, but we could check against a set of defaults at least.) It's not the perfect solution, but this command would report the cycle you saw: /usr/lib/systemd/systemd --test --system Michal -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
I see many this messages. But Matthew solution haven't fixed my problem. -Igor Gnatenko On Oct 31, 2014 4:42 PM, Michal Schmidt mschm...@redhat.com wrote: On 10/31/2014 02:30 PM, Matthew Miller wrote: Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount: Directory /dev/mqueue to mount over is not empty, mounting anyway. Oct 31 09:19:46 ubik mount[4484]: mount: mount point /dev/mqueue does not exist Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount mount process exited, code=exited status=32 Oct 31 09:19:46 ubik systemd[1]: Failed to mount POSIX Message Queue File System. I saw this too, but didn't look into it. On a related but different note — is there a way to detect potential ordering cycles from a set of RPMs on disk (possibly installed in a chroot or something) _without_ actually booting? Maybe we could add a taskotron check for that for packages with changes to systemd unit files. (I realize that what is enabled on people's systems will have an impact, but we could check against a set of defaults at least.) It's not the perfect solution, but this command would report the cycle you saw: /usr/lib/systemd/systemd --test --system Michal -- 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Fri, 2014-10-31 at 14:05 +0100, Kai Engert wrote: On Wed, 2014-10-15 at 12:28 +0200, Vít Ondruch wrote: Nevertheless, I am still unsure how to proceed with RubyGems. Should I ship the bundled certificates again? Or should I wait until somebody notices? Sorry for my late reply, because I didn't have a good suggestion earlier. We should work with the upstream OpenSSL and the GnuTLS projects, and motivate them to implement more advanced path building. This would be a long term project. Is there some issue with gnutls in F21? As far as I understand it should work as expected with the certificates removed. So, to answer Vít's original question: I'd prefer if RubyGems didn't ship its own copy. I think our recent achievement that all software packages on a system use the same (default) set of trusted CA certificates is a good improvement, and I think we should keep it. More than agree. No package should try provide better defaults than the shipped ca-certificates, not only because it won't be better, but because this is system configuration which administrators can and _do_ change. regards, Nikos -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Thu, Oct 30, 2014 at 21:47:36 -0400, Matthew Miller mat...@fedoraproject.org wrote: Updated my rawhide system. Now it doesn't boot cleanly. Will try to figure out the details in the morning (long week!), but Found ordering cycle on basic.target/start seems to be part of it, and I wanted to see if anyone else is hitting this (and possibly caution care on upgrading right now). Note Breaking ordering cycle by deleting job sysinit.target/start. The system partially comes up, but there is a _lot_ of failure-to-work afterwards - probably related. I have a similar but not identical issue on some of my systems. It has been a problem for a couple of weeks that I have been avoiding by using older initramfs for. I haven't wanted to spend the time to figure out exactly what is triggering the problem. (It doesn't happen on all of my machines.) -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, 31 Oct 2014 14:01:12 +0100 Lennart Poettering mzerq...@0pointer.de wrote: So the problem appears to be that gssproxy.service been ordered before remote-fs-pre.target. That target is ordered before basic.target. However gssproxy.service also is ordered after basic.target (simply because all services by default are ordered before basic.target, unless they explicitly specify DefaultDependencies=no), hence there's an ordering cycle. Most likely some NFS maintainers tried to move gss-proxy.service into the early boot, and didn't set DefaultDependencies=no. That said, services running in early boot must be written in a specific style (i.e. not assume /var to be around, and suchlike), I do wonder if gssproxy is ready for that. Anyway, long story short: file a bug against the gssproxy package. I don't think this explains all the problems folks are having with systemd-217. I have gssproxy disabled here and still see loops and issues. I did not with 216. gssproxy itself hasn't been updated in a long time. Happy to provide info from my install here, what info would be good to get from everyone? Perhaps in bug would be a better place to collect it: https://bugzilla.redhat.com/show_bug.cgi?id=1159117 kevin signature.asc Description: 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Fri, 2014-10-31 at 15:00 +0100, Nikos Mavrogiannopoulos wrote: We should work with the upstream OpenSSL and the GnuTLS projects, and motivate them to implement more advanced path building. This would be a long term project. Is there some issue with gnutls in F21? As far as I understand it should work as expected with the certificates removed. It works as expected in the sense that GnuTLS can no longer handle major web sites like Amazon and Kickstarter, this being the natural consequence of removing a root before the certificates issued by it have expired 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Fri, 2014-10-31 at 09:49 -0500, Michael Catanzaro wrote: We should work with the upstream OpenSSL and the GnuTLS projects, and motivate them to implement more advanced path building. This would be a long term project. Is there some issue with gnutls in F21? As far as I understand it should work as expected with the certificates removed. It works as expected in the sense that GnuTLS can no longer handle major web sites like Amazon and Kickstarter, this being the natural consequence of removing a root before the certificates issued by it have expired Are you sure that this is the case with the current package? My F21 can no longer connect to network to test, but gnutls in it should reconstruct the chain similarly to what nss does (not very similarly to be precise but the end result should be the same). If it is not the case please report it as bug and I'll check it out. regards, Nikos -- 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
Am 31.10.2014 um 15:53 schrieb Nikos Mavrogiannopoulos: On Fri, 2014-10-31 at 09:49 -0500, Michael Catanzaro wrote: We should work with the upstream OpenSSL and the GnuTLS projects, and motivate them to implement more advanced path building. This would be a long term project. Is there some issue with gnutls in F21? As far as I understand it should work as expected with the certificates removed. It works as expected in the sense that GnuTLS can no longer handle major web sites like Amazon and Kickstarter, this being the natural consequence of removing a root before the certificates issued by it have expired Are you sure that this is the case with the current package? My F21 can no longer connect to network to test, but gnutls in it should reconstruct the chain similarly to what nss does (not very similarly to be precise but the end result should be the same). If it is not the case please report it as bug and I'll check it out. the point is that if somebody buys a certificate for 6 years he may have a checklist when to change them and if some 3rd party decides to remove the CA certificate - game over for users of that 3rd party from where will you reconstruct the chain? * webserver a) has a certificate for 6 years * the issuer is CA b) which you remove * you make that certificate invalid by intention * frankly, that certificate still shows i am valid until * that certificate would have to be replaced * that won't happen in many cases you can hope and expect that large internet copmanies are doing that in a timely manner, but you *really really* can not expect that from anybody out there and you won't notice small websites and other services breaking caused by that the worst case is that somebody with no technical clue installed the certificate, becomes very few complaints, verfies that it works everywhere and claims Fedora to be broken - and frankly he is just right with that claim because nobody but the CA is in the position to revoke CA certs which are valid there is a difference in CA's call back certificates and force there users to re-new their certificates or a random OS supplier just removes them from the chain - the CA normally knows which certificates are issued for which customer with a specific CA certificate - the blind butcher making CA certificates invalid don't know the whole CA trust idea is broken by design, but you won't fix it by remove vaild CA certificates *without coordinate that with the affected CA and make sure all affected customer certificates are replaced* 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 03:42 PM, Kevin Fenzi wrote: On Fri, 31 Oct 2014 14:01:12 +0100 Lennart Poettering mzerq...@0pointer.de wrote: So the problem appears to be that gssproxy.service been ordered before remote-fs-pre.target. That target is ordered before basic.target. However gssproxy.service also is ordered after basic.target (simply because all services by default are ordered before basic.target, unless they explicitly specify DefaultDependencies=no), hence there's an ordering cycle. Most likely some NFS maintainers tried to move gss-proxy.service into the early boot, and didn't set DefaultDependencies=no. That said, services running in early boot must be written in a specific style (i.e. not assume /var to be around, and suchlike), I do wonder if gssproxy is ready for that. Anyway, long story short: file a bug against the gssproxy package. I don't think this explains all the problems folks are having with systemd-217. I wonder if the new ordering dependency between systemd-journal-flush.service and systemd-tmpfiles-setup.service (added in 74055aa76 journalctl: add new --flush command and make use of it in systemd-journal-flush.service) participates in the ordering cycles. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Suggested Freeze Policy change for Fedora 22+
I talked to several people over the last couple days about what we can do to try to avoid the hero testing treadmill that we've been on during every Freeze in recent memory (specifically that we're usually fixing Blocker bugs until the day before the Go/No-Go meeting and that means that our QA team is pulling all-night test runs basically every week). I made the following suggestion to both Adam Williamson and David Cantrell over the last couple of days and both seemed to think that this is a reasonable approach (but for different reasons, interestingly). Beginning with Alpha Freeze in Fedora 22, the policy would be amended to include the following: 1. As currently, the Go/No-Go meeting must be held on the Thursday preceding the planned Tuesday of public release. 2. At 1600 UTC on the Monday preceding Go/No-Go, a check of the known Blocker list must be performed. If there are any blocker bugs that are not marked as MODIFIED or ON_QA (meaning that they are filed as an update in Bodhi), then the Go/No-Go meeting that week is canceled (or converted to a Blocker Bug review) and a slip is *automatic*. 3. Relevant to the above, a Release Candidate compose must be started immediately after the above blocker review and must complete successfully by 1300 UTC on Tuesday. Otherwise, the Go/No-Go meeting that week is canceled (or converted to a Blocker Bug review) and a slip is *automatic*. 4. If *new* blockers are discovered (or regressed) between the Monday blocker review and Thursday Go/No-Go, it is *permissible* for another compose to be created if the following conditions are met: a. The fix is capable of being produced and built quickly. b. There is at least 24 hours remaining between the expected completion of the compose and the Go/No-Go meeting. The idea here is to ensure that there is a clear engineering deadline in order to guarantee that the QA team has a reasonable time period in which to perform validation tests. I think this approach is too risky this late in the F21 process, which is why I propose this only for Fedora 22 and later. 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, 31.10.14 16:13, Michal Schmidt (mschm...@redhat.com) wrote: On 10/31/2014 03:42 PM, Kevin Fenzi wrote: On Fri, 31 Oct 2014 14:01:12 +0100 Lennart Poettering mzerq...@0pointer.de wrote: So the problem appears to be that gssproxy.service been ordered before remote-fs-pre.target. That target is ordered before basic.target. However gssproxy.service also is ordered after basic.target (simply because all services by default are ordered before basic.target, unless they explicitly specify DefaultDependencies=no), hence there's an ordering cycle. Most likely some NFS maintainers tried to move gss-proxy.service into the early boot, and didn't set DefaultDependencies=no. That said, services running in early boot must be written in a specific style (i.e. not assume /var to be around, and suchlike), I do wonder if gssproxy is ready for that. Anyway, long story short: file a bug against the gssproxy package. I don't think this explains all the problems folks are having with systemd-217. I wonder if the new ordering dependency between systemd-journal-flush.service and systemd-tmpfiles-setup.service (added in 74055aa76 journalctl: add new --flush command and make use of it in systemd-journal-flush.service) participates in the ordering cycles. Ahh, indeed. It moves remote-fs.target into the early-boot where it doesn't belong. My fault. Will drop the remote-fs.target dep from the flush service. Thanks for tracking this down. Lennart -- Lennart Poettering, 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
Re: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Fri, 2014-10-31 at 15:00 +0100, Nikos Mavrogiannopoulos wrote: Sorry for my late reply, because I didn't have a good suggestion earlier. We should work with the upstream OpenSSL and the GnuTLS projects, and motivate them to implement more advanced path building. This would be a long term project. Is there some issue with gnutls in F21? As far as I understand it should work as expected with the certificates removed. I confirm that using GnuTLS 3.3.9-2.fc21 on Fedora 21 testing, with ca-certificates-2014.2.1-1.3.fc21, and ca-legacy set to disabled, the command gnutls-cli -p443 www.amazon.com reports a trusted certificate. That's great, thanks Nikos for fixing it in the newer GnuTLS on Fedora 21! (Just for the record, using gnutls 3.1.27 on Fedora 20, and a scratch build of the new ca-certificates package, and set to disabled, the certificate is still rejected, which I understand is because of the older GnuTLS version.) If anyone can still see problems with GnuTLS and the above configuration (disable) on Fedora 21, please let us know which site has the issue. This means, the remaining package that needs fixing is OpenSSL. Thanks Kai -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, 31.10.14 16:20, Lennart Poettering (mzerq...@0pointer.de) wrote: On Fri, 31.10.14 16:13, Michal Schmidt (mschm...@redhat.com) wrote: On 10/31/2014 03:42 PM, Kevin Fenzi wrote: On Fri, 31 Oct 2014 14:01:12 +0100 Lennart Poettering mzerq...@0pointer.de wrote: So the problem appears to be that gssproxy.service been ordered before remote-fs-pre.target. That target is ordered before basic.target. However gssproxy.service also is ordered after basic.target (simply because all services by default are ordered before basic.target, unless they explicitly specify DefaultDependencies=no), hence there's an ordering cycle. Most likely some NFS maintainers tried to move gss-proxy.service into the early boot, and didn't set DefaultDependencies=no. That said, services running in early boot must be written in a specific style (i.e. not assume /var to be around, and suchlike), I do wonder if gssproxy is ready for that. Anyway, long story short: file a bug against the gssproxy package. I don't think this explains all the problems folks are having with systemd-217. I wonder if the new ordering dependency between systemd-journal-flush.service and systemd-tmpfiles-setup.service (added in 74055aa76 journalctl: add new --flush command and make use of it in systemd-journal-flush.service) participates in the ordering cycles. Ahh, indeed. It moves remote-fs.target into the early-boot where it doesn't belong. My fault. Will drop the remote-fs.target dep from the flush service. Thanks for tracking this down. Would be good if somebody who ran into this problem could check if this change fixes it: http://cgit.freedesktop.org/systemd/systemd/commit/units/systemd-journal-flush.service.in?id=919699ec301ea507edce4a619141ed22e789ac0d (the actual commit unfortunately contains an unrelated change to nspawn, I fucked that up, sorry. Ignore everything but the change to systemd-journal-flush.service) Thanks, Lennart -- Lennart Poettering, 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
Re: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Fri, 2014-10-31 at 16:11 +0100, Reindl Harald wrote: Are you sure that this is the case with the current package? My F21 can no longer connect to network to test, but gnutls in it should reconstruct the chain similarly to what nss does (not very similarly to be precise but the end result should be the same). If it is not the case please report it as bug and I'll check it out. the point is that if somebody buys a certificate for 6 years he may have a checklist when to change them and if some 3rd party decides to remove the CA certificate - game over for users of that 3rd party from where will you reconstruct the chain? * webserver a) has a certificate for 6 years * the issuer is CA b) which you remove I'm also not particularly fond of this approach as it adds complexity to an otherwise very complex protocol. However, in gnutls an alternative certificate path is calculated if there is a trusted certificate which has the same name as the issuer of a CA certificate in the path, and it also has the same key. This is the particular case that Kai refers to. For example in that case, a verisign intermediate certificate was removed, and replaced with a root CA certificate, that has the same DN, and the same key. regards, Nikos -- 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: Suggested Freeze Policy change for Fedora 22+
On Fri, Oct 31, 2014 at 11:17:39 -0400, Stephen Gallagher sgall...@redhat.com wrote: The idea here is to ensure that there is a clear engineering deadline in order to guarantee that the QA team has a reasonable time period in which to perform validation tests. I think this approach is too risky this late in the F21 process, which is why I propose this only for Fedora 22 and later. Are the automatic slips always going to be a full week? While we normally slip full week, there have been cases recently where slips of less than a week have been contemplated. -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, 31 Oct 2014 16:30:31 +0100 Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 31.10.14 16:20, Lennart Poettering (mzerq...@0pointer.de) wrote: On Fri, 31.10.14 16:13, Michal Schmidt (mschm...@redhat.com) wrote: On 10/31/2014 03:42 PM, Kevin Fenzi wrote: On Fri, 31 Oct 2014 14:01:12 +0100 Lennart Poettering mzerq...@0pointer.de wrote: So the problem appears to be that gssproxy.service been ordered before remote-fs-pre.target. That target is ordered before basic.target. However gssproxy.service also is ordered after basic.target (simply because all services by default are ordered before basic.target, unless they explicitly specify DefaultDependencies=no), hence there's an ordering cycle. Most likely some NFS maintainers tried to move gss-proxy.service into the early boot, and didn't set DefaultDependencies=no. That said, services running in early boot must be written in a specific style (i.e. not assume /var to be around, and suchlike), I do wonder if gssproxy is ready for that. Anyway, long story short: file a bug against the gssproxy package. I don't think this explains all the problems folks are having with systemd-217. I wonder if the new ordering dependency between systemd-journal-flush.service and systemd-tmpfiles-setup.service (added in 74055aa76 journalctl: add new --flush command and make use of it in systemd-journal-flush.service) participates in the ordering cycles. Ahh, indeed. It moves remote-fs.target into the early-boot where it doesn't belong. My fault. Will drop the remote-fs.target dep from the flush service. Thanks for tracking this down. Would be good if somebody who ran into this problem could check if this change fixes it: http://cgit.freedesktop.org/systemd/systemd/commit/units/systemd-journal-flush.service.in?id=919699ec301ea507edce4a619141ed22e789ac0d (the actual commit unfortunately contains an unrelated change to nspawn, I fucked that up, sorry. Ignore everything but the change to systemd-journal-flush.service) Yep. Seems to fix up the looping here. ;) I still see: Oct 31 09:42:29 voldemort.scrye.com systemd[1]: Cannot add dependency job for unit nfs.target, ignoring: Unit nfs.target failed to load: No such file or directory. Oct 31 09:42:29 voldemort.scrye.com systemd[1]: Cannot add dependency job for unit systemd-readahead-replay.service, ignoring: Unit systemd-readahead-replay.service failed to load: No such file or directory. Oct 31 09:42:29 voldemort.scrye.com systemd[1]: Cannot add dependency job for unit systemd-readahead-collect.service, ignoring: Unit systemd-readahead-collect.service failed to load: No such file or directory. But those seem cosmetic/unrelated. Thanks much for the quick fix! kevin signature.asc Description: 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, Oct 31, 2014 at 09:46:13AM -0600, Kevin Fenzi wrote: I still see: Oct 31 09:42:29 voldemort.scrye.com systemd[1]: Cannot add dependency job for unit nfs.target, ignoring: Unit nfs.target failed to load: No such file or directory. Oct 31 09:42:29 voldemort.scrye.com systemd[1]: Cannot add dependency job for unit systemd-readahead-replay.service, ignoring: Unit systemd-readahead-replay.service failed to load: No such file or directory. Oct 31 09:42:29 voldemort.scrye.com systemd[1]: Cannot add dependency job for unit systemd-readahead-collect.service, ignoring: Unit systemd-readahead-collect.service failed to load: No such file or directory. But those seem cosmetic/unrelated. Readahead was removed from systemd, so if you were using it, you should remove stale symlinks. -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, 31.10.14 16:55, Tomasz Torcz (to...@pipebreaker.pl) wrote: On Fri, Oct 31, 2014 at 09:46:13AM -0600, Kevin Fenzi wrote: I still see: Oct 31 09:42:29 voldemort.scrye.com systemd[1]: Cannot add dependency job for unit nfs.target, ignoring: Unit nfs.target failed to load: No such file or directory. Oct 31 09:42:29 voldemort.scrye.com systemd[1]: Cannot add dependency job for unit systemd-readahead-replay.service, ignoring: Unit systemd-readahead-replay.service failed to load: No such file or directory. Oct 31 09:42:29 voldemort.scrye.com systemd[1]: Cannot add dependency job for unit systemd-readahead-collect.service, ignoring: Unit systemd-readahead-collect.service failed to load: No such file or directory. But those seem cosmetic/unrelated. Readahead was removed from systemd, so if you were using it, you should remove stale symlinks. I figure systemd.rpm is currently missing the right postinst scripts to remove those automatically on upgrade... Lennart -- Lennart Poettering, 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
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
Fixes my problem, but black screen instead of gdm On Oct 31, 2014 7:31 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 31.10.14 16:20, Lennart Poettering (mzerq...@0pointer.de) wrote: On Fri, 31.10.14 16:13, Michal Schmidt (mschm...@redhat.com) wrote: On 10/31/2014 03:42 PM, Kevin Fenzi wrote: On Fri, 31 Oct 2014 14:01:12 +0100 Lennart Poettering mzerq...@0pointer.de wrote: So the problem appears to be that gssproxy.service been ordered before remote-fs-pre.target. That target is ordered before basic.target. However gssproxy.service also is ordered after basic.target (simply because all services by default are ordered before basic.target, unless they explicitly specify DefaultDependencies=no), hence there's an ordering cycle. Most likely some NFS maintainers tried to move gss-proxy.service into the early boot, and didn't set DefaultDependencies=no. That said, services running in early boot must be written in a specific style (i.e. not assume /var to be around, and suchlike), I do wonder if gssproxy is ready for that. Anyway, long story short: file a bug against the gssproxy package. I don't think this explains all the problems folks are having with systemd-217. I wonder if the new ordering dependency between systemd-journal-flush.service and systemd-tmpfiles-setup.service (added in 74055aa76 journalctl: add new --flush command and make use of it in systemd-journal-flush.service) participates in the ordering cycles. Ahh, indeed. It moves remote-fs.target into the early-boot where it doesn't belong. My fault. Will drop the remote-fs.target dep from the flush service. Thanks for tracking this down. Would be good if somebody who ran into this problem could check if this change fixes it: http://cgit.freedesktop.org/systemd/systemd/commit/units/systemd-journal-flush.service.in?id=919699ec301ea507edce4a619141ed22e789ac0d (the actual commit unfortunately contains an unrelated change to nspawn, I fucked that up, sorry. Ignore everything but the change to systemd-journal-flush.service) Thanks, Lennart -- Lennart Poettering, 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 -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Thu, Oct 30, 2014 at 09:47:36PM -0400, Matthew Miller wrote: Oct 30 21:39:37 ubik.home.mkmiller.org systemd[1]: Configuration file /usr/lib/systemd/system/auditd.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway. Nb. audit maintainer still refuses to fix this bug. https://bugzilla.redhat.com/show_bug.cgi?id=959483 -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
systemd-logind: failed to get session: PID 879 doesnt belong to any known session On Oct 31, 2014 7:31 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 31.10.14 16:20, Lennart Poettering (mzerq...@0pointer.de) wrote: On Fri, 31.10.14 16:13, Michal Schmidt (mschm...@redhat.com) wrote: On 10/31/2014 03:42 PM, Kevin Fenzi wrote: On Fri, 31 Oct 2014 14:01:12 +0100 Lennart Poettering mzerq...@0pointer.de wrote: So the problem appears to be that gssproxy.service been ordered before remote-fs-pre.target. That target is ordered before basic.target. However gssproxy.service also is ordered after basic.target (simply because all services by default are ordered before basic.target, unless they explicitly specify DefaultDependencies=no), hence there's an ordering cycle. Most likely some NFS maintainers tried to move gss-proxy.service into the early boot, and didn't set DefaultDependencies=no. That said, services running in early boot must be written in a specific style (i.e. not assume /var to be around, and suchlike), I do wonder if gssproxy is ready for that. Anyway, long story short: file a bug against the gssproxy package. I don't think this explains all the problems folks are having with systemd-217. I wonder if the new ordering dependency between systemd-journal-flush.service and systemd-tmpfiles-setup.service (added in 74055aa76 journalctl: add new --flush command and make use of it in systemd-journal-flush.service) participates in the ordering cycles. Ahh, indeed. It moves remote-fs.target into the early-boot where it doesn't belong. My fault. Will drop the remote-fs.target dep from the flush service. Thanks for tracking this down. Would be good if somebody who ran into this problem could check if this change fixes it: http://cgit.freedesktop.org/systemd/systemd/commit/units/systemd-journal-flush.service.in?id=919699ec301ea507edce4a619141ed22e789ac0d (the actual commit unfortunately contains an unrelated change to nspawn, I fucked that up, sorry. Ignore everything but the change to systemd-journal-flush.service) Thanks, Lennart -- Lennart Poettering, 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 -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On 10/31/2014 04:57 PM, Igor Gnatenko wrote: systemd-logind: failed to get session: PID 879 doesnt belong to any known session That's not necessarily related to the problem. I have this message in the log even when gdm works fine. Michal -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
On Fri, 31 Oct 2014 20:04:24 +0400 Igor Gnatenko i.gnatenko.br...@gmail.com wrote: Probably. How to debug? On Oct 31, 2014 8:01 PM, Michal Schmidt mschm...@redhat.com wrote: On 10/31/2014 04:57 PM, Igor Gnatenko wrote: systemd-logind: failed to get session: PID 879 doesnt belong to any known session That's not necessarily related to the problem. I have this message in the log even when gdm works fine. Michal One possible reason for this: what version of mutter do you have? You might have the new 3.15 one, but the older gnome-shell. Either downgrade mutter or upgrade gnome-shell from the one just built in koji. They would have both gone out in today's rawhide, but there was a build failure on the gnome-shell build. kevin signature.asc Description: 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
Probably. How to debug? On Oct 31, 2014 8:01 PM, Michal Schmidt mschm...@redhat.com wrote: On 10/31/2014 04:57 PM, Igor Gnatenko wrote: systemd-logind: failed to get session: PID 879 doesnt belong to any known session That's not necessarily related to the problem. I have this message in the log even when gdm works fine. Michal -- 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: RHEL 6.6 MPI mess
Orion Poplawski or...@cora.nwra.com writes: Just a quick note - this discussion belongs on the EPEL mailing list. Apologies. I don't remember seeing that when I read the instructions to try to get packages into EPEL. I'll check whether it's there/obvious when I have a chance. -- 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: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
I have all packages from koji. On Oct 31, 2014 8:10 PM, Kevin Fenzi ke...@scrye.com wrote: On Fri, 31 Oct 2014 20:04:24 +0400 Igor Gnatenko i.gnatenko.br...@gmail.com wrote: Probably. How to debug? On Oct 31, 2014 8:01 PM, Michal Schmidt mschm...@redhat.com wrote: On 10/31/2014 04:57 PM, Igor Gnatenko wrote: systemd-logind: failed to get session: PID 879 doesnt belong to any known session That's not necessarily related to the problem. I have this message in the log even when gdm works fine. Michal One possible reason for this: what version of mutter do you have? You might have the new 3.15 one, but the older gnome-shell. Either downgrade mutter or upgrade gnome-shell from the one just built in koji. They would have both gone out in today's rawhide, but there was a build failure on the gnome-shell build. kevin -- 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
Requiring all files in /usr to be world-readable?
I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467 Thoughts? -- 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Fri, 2014-10-31 at 15:53 +0100, Nikos Mavrogiannopoulos wrote: Are you sure that this is the case with the current package? My F21 can no longer connect to network to test, but gnutls in it should reconstruct the chain similarly to what nss does (not very similarly to be precise but the end result should be the same). If it is not the case please report it as bug and I'll check it out. No, I haven't tested this in a month or two. If there's been recent work on NSS compatibility, that's awesome. Complicating the matter is that these pages sometimes work and sometimes don't (CDN magic I suppose) so we really have to rely on bug reports to know if there's breakage, and we won't get those unless the compat certificates are removed (which I certainly don't suggest). Thanks, Michael 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: Requiring all files in /usr to be world-readable?
Once upon a time, Andrew Lutomirski l...@mit.edu said: I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467 Thoughts? I've filed individual bugs in the past. IMHO every file that is RPM-installed that is not marked config should be world-readable (regardless of location). There is no reason for any other permissions. -- Chris Adams li...@cmadams.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
Self Introduction: Alexander Ploumistos
Hello everyone, I've decided to join the package maintainers and I would like to introduce myself. I have been a linux user since 2001 and a Red Hat/Fedora user since 2003. My main systems run on Fedora (of course) and Gentoo. I have a background in chemistry, particularly molecular modeling and for the past decade I have been working as a general purpose IT guy and part-time web-developer. I build systems, I design and deploy SOHO networks, I do some light pen-testing and provide tech support. I have experience coding in Fortran, Perl, PHP, Python, shell scripts, (X)HTML/CSS, I have worked with several CMSs -though in the past few years mostly with Joomla- and I have built some customized versions of embedded distros such as OpenWRT and other device-related software. During the past decade I have done alpha/beta/QA testing for a number of projects (most of them FLOSS) and I have provided translations and bug reports for others. I would like to give back something more than bug reports and translations and also improve my coding skills along the way. I have a couple of programs that I would like to maintain, but for the moment there remains an issue with their licenses. There is also a patched version of libatasmart, that takes care of an issue with several older Western Digital hard drives, that is awaiting review ( https://bugzilla.redhat.com/show_bug.cgi?id=1157150) and I would really appreciate it if someone could take the time to look into that. Best Regards Alexander -- 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
On Fri, 2014-10-31 at 16:28 +0100, Kai Engert wrote: I confirm that using GnuTLS 3.3.9-2.fc21 on Fedora 21 testing, with ca-certificates-2014.2.1-1.3.fc21, and ca-legacy set to disabled, the command gnutls-cli -p443 www.amazon.com reports a trusted certificate. This isn't a recent change, see [1]. I presume Amazon is most likely still broken in Epiphany (when these roots are removed) as there's been no action on [1], where we decided that gnutls-cli accepted www.amazon.com because it uses certs if they're valid for either email or TLS, whereas GLib only uses certs if they're valid for TLS. Note that due to CDN magic, sites like Amazon load lots of subresources like images and CSS over connections using unrelated certs, so a more reliable test is to actually open the web page in a browser. P.S. To both Kai and Nikos: thanks for all your effort on this matter. A couple months ago I was quite worried, but now I expect things will turn out fine. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1134602 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: Requiring all files in /usr to be world-readable?
- Original Message - I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467 Thoughts? My intuition is that if an application needs _everything_ in /usr to be readable then it is likely broken. Something being placed in /usr does _not_ imply that it is supposed to be used by everyone. An administrator can come and change the permissions at any time, and the packaging guideline would not affect anything not included in Fedora-distributed RPMs. And if we look only at the cases that would be helped by the proposed guideline, i.e. only depending on Fedora RPM-distributed files (but not being particular about what the purpose of kind of file this is), the application would probably be better off just opening and reading the RPMs from repos directly instead of reusing whatever local damage could have been done to the partition. Perhaps there are useful subsets of files in /usr where mandating this would be useful; but all of /usr is seems like an unnecessary overreach. (And to the specific examples brought up: No opinion on systemd services; making setuid binaries not world-readable has a _definite_ benefit when prelink is set up, OTOH that is no longer a default.) 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
Re: Requiring all files in /usr to be world-readable?
On Fri, Oct 31, 2014 at 10:59 AM, Miloslav Trmač m...@redhat.com wrote: - Original Message - I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467 Thoughts? My intuition is that if an application needs _everything_ in /usr to be readable then it is likely broken. Something being placed in /usr does _not_ imply that it is supposed to be used by everyone. An administrator can come and change the permissions at any time, and the packaging guideline would not affect anything not included in Fedora-distributed RPMs. And if we look only at the cases that would be helped by the proposed guideline, i.e. only depending on Fedora RPM-distributed files (but not being particular about what the purpose of kind of file this is), the application would probably be better off just opening and reading the RPMs from repos directly instead of reusing whatever local damage could have been done to the partition. I'm fine with having various user tools that want to read from /usr stop working as non-root if the admin changes the permissions. But I think they should work by default. Perhaps there are useful subsets of files in /usr where mandating this would be useful; but all of /usr is seems like an unnecessary overreach. That's why I think that individual exceptions should be allowed. I don't yet know of a case where I would agree that an exception would be a good idea, but I don't want to rule it out. (And to the specific examples brought up: No opinion on systemd services; making setuid binaries not world-readable has a _definite_ benefit when prelink is set up, OTOH that is no longer a default.) I certainly agree with the prelink issue, but I think that that issue is obsolete. There's already a guideline stating that suid binaries MUST be PIE, and the guideline claims (hopefully correctly) that prelink doesn't work for PIE executables, so there shouldn't be any prelinked suid binaries in the first place. --Andy -- 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: Suggested Freeze Policy change for Fedora 22+
On Fri, 2014-10-31 at 10:34 -0500, Bruno Wolff III wrote: On Fri, Oct 31, 2014 at 11:17:39 -0400, Stephen Gallagher sgall...@redhat.com wrote: The idea here is to ensure that there is a clear engineering deadline in order to guarantee that the QA team has a reasonable time period in which to perform validation tests. I think this approach is too risky this late in the F21 process, which is why I propose this only for Fedora 22 and later. Are the automatic slips always going to be a full week? While we normally slip full week, there have been cases recently where slips of less than a week have been contemplated. Well, we learned during those questions that it's a matter of coordination with the mirrors. They expect to have our master trees prepared at certain times or they can't be mirrored out in time for the Tuesday launches. So really, we need to keep to the same schedule wherever possible. 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: ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys
- Original Message - This isn't a recent change, see [1]. I presume Amazon is most likely still broken in Epiphany (when these roots are removed) as there's been no action on [1], where we decided that gnutls-cli accepted www.amazon.com because it uses certs if they're valid for either email or TLS, whereas GLib only uses certs if they're valid for TLS. Note that due to CDN magic, sites like Amazon load lots of subresources like images and CSS over connections using unrelated certs, so a more reliable test is to actually open the web page in a browser. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1134602 I've reassigned the original bug to gnutls and closed with next release (F21). A fix for F20 is very hard to occur and would most probably introduce unncessary issues. If anything remains, feel free to reopen with more information. regards, Nikos -- 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: Alexander Ploumistos
On 10/31/2014 11:28 AM, Alexander Ploumistos wrote: Hello everyone, I've decided to join the package maintainers and I would like to introduce myself. ... There is also a patched version of libatasmart, that takes care of an issue with several older Western Digital hard drives, that is awaiting review (https://bugzilla.redhat.com/show_bug.cgi?id=1157150) and I would really appreciate it if someone could take the time to look into that. Best Regards Alexander I've closed that NOTABUG - we already have libatasmart in Fedora. Although perhaps we need some new maintainers, even upstream. Lennart - comments? https://bugzilla.redhat.com/show_bug.cgi?id=921430 https://bugs.freedesktop.org/show_bug.cgi?id=61998 -- 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: Self Introduction: Alexander Ploumistos
So am I allowed to submit it to bodhi, or does it still need to be approved beforehand? I'm sorry for the mix-up, but it wasn't clear in the wiki. 2014-10-31 22:09 GMT+02:00 Orion Poplawski or...@cora.nwra.com: On 10/31/2014 11:28 AM, Alexander Ploumistos wrote: Hello everyone, I've decided to join the package maintainers and I would like to introduce myself. ... There is also a patched version of libatasmart, that takes care of an issue with several older Western Digital hard drives, that is awaiting review (https://bugzilla.redhat.com/show_bug.cgi?id=1157150) and I would really appreciate it if someone could take the time to look into that. Best Regards Alexander I've closed that NOTABUG - we already have libatasmart in Fedora. Although perhaps we need some new maintainers, even upstream. Lennart - comments? https://bugzilla.redhat.com/show_bug.cgi?id=921430 https://bugs.freedesktop.org/show_bug.cgi?id=61998 -- 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
5tFTW: Fedora Beta, Council Elections, Strategic Planning, Outreach Committee, and FUDCon Reports (2014-10-31)
Reposted from http://fedoramagazine.org/5tftw-2014-10-31/. Fedora is a big project, and it’s hard to keep up with everything that goes on. This series highlights interesting happenings in five different areas every week. It isn’t comprehensive news coverage — just quick summaries with links to each. Here are the five things for October 31st, 2014: Fedora Beta due Next Week - I’ll keep this item short: Fedora 21 Beta is Go, and will be available Tuesday, November 4th. Next week, we’ll do an all-beta 5tFTW. This puts the final release target at December 9th. As always, these targets are more like guidelines than deadlines, but as we are verging on the holiday season we are going to make extra effort to avoid further adjustment. * https://lists.fedoraproject.org/pipermail/devel-announce/2014-October/001455.html * http://fedoraproject.org/wiki/Releases/21/Schedule * https://www.youtube.com/watch?v=6GMkuPiIZ2k Council Update and Elections The Fedora Council — our new top-level leadership body — includes two of seats appointed by elected committees and two seats elected by the Fedora Contributor community at large. The appointed seats covering Fedora Engineering and Fedora Outreach (more on that below) are now filled, by Josh Boyer and Christoph Wickert respectively. (Congratulations and thank you to Josh and Christoph!) Now it’s time to fill the elected seats — see the schedule announcement for details. Quick summary: nomination period next week; “campaign” week after that, and finally a week for community voting after that. The Council will take over from the Fedora Project Board when this is complete. * https://fedoraproject.org/wiki/Council * https://lists.fedoraproject.org/pipermail/announce/2014-October/003236.html * http://fedoraproject.org/wiki/Board Fedora Objectives - If you haven’t seen it already, I would like everyone who cares about what Fedora does and where the project is going to take a look at my recent Fedora Magazine article about Fedora objectives — why, how, and eventually what. As I mentioned a few weeks ago, high-level strategy discussions can feel disconnected and pointless. This is a process by which we can actually connect them into what we’re doing in a meaningful way, and by doing so increase the impact of our actions. Take a look, and take part in upcoming discussions on the public board discuss list. * http://fedoramagazine.org/lets-talk-about-fedora-project-objectives/ * https://lists.fedoraproject.org/pipermail/announce/2014-October/003235.html * https://admin.fedoraproject.org/mailman/listinfo/board-discuss Fedora Outreach Steering Committee? --- Fedora has long had two high-level elected steering committees, FESCo, the Fedora Engineering Steering Committee, and FAmSCo, the Fedora Ambassadors Steering Committee. The meritocratic representative positions on the Council are appointed by these committees. This is straightforward for the relatively wide-reaching FESCo, but the seat appointed by FAmSCo is actually intended to represent a much broader section of the project than ambassadors alone. This lead to a discussion about creating a new Outreach steering committee, tying together and coordinating efforts of Ambassadors, Marketing, Brand/Design, some aspects of the product Working Groups, Docs, various support channels — overall, all the parts of the project which are outward looking rather than focused on building the distro and infrastructure. Since FAmSCo has successfully delegated a lot of responsibility to regional ambassadors committees, and since the new Council will work on the high level community budget, this new body would make FAmSCo obsolete — so we’re not just piling on yet more committees, here! If you’re interested, join the new Fedora Outreach mailing list and let’s start building this! * https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee * http://fedoraproject.org/wiki/Fedora_Ambassadors_Steering_Committee * https://lists.fedoraproject.org/mailman/listinfo/outreach Reports from FUDCon Managua --- As promised last week, some updates from FUDCon Managua, our user-and-developer conference held this year in Nicaragua. Check out reports from: - Alejandro Prez (Lots of pictures and people!) - William Moreno Reyes (In Spanish *and* English!) - Rino Rondan (All in Spanish, although the photographs are multilingual) - Robert Mayr (Just “day 0″ so far; check back for more updates from robyduck!) - Kiara Navarro (In Spanish with a lot of details, and again a lot of photos — and also, there’s part 2 and part 3) - Abdel G. Martínez L. (Particularly, highlights positive impact of the event on project contribution — nice!) - Daniel Bruno (In English) Thanks to everyone who made these reports, and thanks to the FUDCon LATAM organizers, and
Re: possibly problem with rawhide (systemd-217?): Found ordering cycle on basic.target/start
yeah. gnome-shell 3.15.1 fixes problem. On Fri, Oct 31, 2014 at 7:09 PM, Kevin Fenzi ke...@scrye.com wrote: On Fri, 31 Oct 2014 20:04:24 +0400 Igor Gnatenko i.gnatenko.br...@gmail.com wrote: Probably. How to debug? On Oct 31, 2014 8:01 PM, Michal Schmidt mschm...@redhat.com wrote: On 10/31/2014 04:57 PM, Igor Gnatenko wrote: systemd-logind: failed to get session: PID 879 doesnt belong to any known session That's not necessarily related to the problem. I have this message in the log even when gdm works fine. Michal One possible reason for this: what version of mutter do you have? You might have the new 3.15 one, but the older gnome-shell. Either downgrade mutter or upgrade gnome-shell from the one just built in koji. They would have both gone out in today's rawhide, but there was a build failure on the gnome-shell build. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] Significant bug in fedup to Fedora 21, do not use it right now
There's a major bug with fedup to Fedora 21 right at the moment, discovered this morning by Robin Lee (thanks Robin). We should be able to deal with it some way or another in time for Beta release day, but for right now it's not a very good idea *at all* to try and upgrade any system you care about to F21 with fedup. (Of course, it's never a good idea to upgrade to a pre-release without a recovery plan!) https://www.happyassassin.net/2014/10/31/psa-dont-fedup-to-fedora-21-right-now/ https://bugzilla.redhat.com/show_bug.cgi?id=1159292 Of course, if you want to help out with solving this, it'll be a great help. It'd be good to have folks confirm that the bug happens any time the 'install updated packages' boot takes more than 15 minutes, and maybe that the scratch builds I've posted in the bug - https://bugzilla.redhat.com/show_bug.cgi?id=1159292#c18 - solve it (the final fix may be different, but that bodge should at least illustrate that the problem is really what we think it is, if it works). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-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: Suggested Freeze Policy change for Fedora 22+
On Fri, Oct 31, 2014 at 14:44:06 -0400, Stephen Gallagher sgall...@redhat.com wrote: Well, we learned during those questions that it's a matter of coordination with the mirrors. They expect to have our master trees prepared at certain times or they can't be mirrored out in time for the Tuesday launches. So really, we need to keep to the same schedule wherever possible. I was really questioning that the policy didn't say how long the slip is, rather than what the amount is. Though my opinion is that it is better to always slip a week as the one or two day slips will just encourage more of what you are trying to avoid. I think there is real risk of burn out in the QA volunteers, with not only the quick turn around commonly needed for testing right before release, but also with the really long blocker meetings leading up to that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Email-Sender-1.300016.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Email-Sender: 758b2dcb2ca1dfb6f9c94ddf94aa0a57 Email-Sender-1.300016.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-Email-Sender] 1.300016 bump
commit 03f7b37cfa4599bc6add291982c863259a1e7dfb
Author: Jitka Plesnikova jples...@redhat.com
Date: Fri Oct 31 11:21:50 2014 +0100
1.300016 bump
.gitignore |1 +
perl-Email-Sender.spec | 39 ---
sources|2 +-
3 files changed, 30 insertions(+), 12 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a9b9972..fec99a6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@ Email-Sender-0.101760.tar.gz
/Email-Sender-0.110005.tar.gz
/Email-Sender-0.120001.tar.gz
/Email-Sender-0.120002.tar.gz
+/Email-Sender-1.300016.tar.gz
diff --git a/perl-Email-Sender.spec b/perl-Email-Sender.spec
index e96395e..4e5d69e 100644
--- a/perl-Email-Sender.spec
+++ b/perl-Email-Sender.spec
@@ -1,6 +1,6 @@
Name: perl-Email-Sender
-Version:0.120002
-Release:6%{?dist}
+Version:1.300016
+Release:1%{?dist}
Summary:A library for sending email
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,35 +8,49 @@ URL:http://search.cpan.org/dist/Email-Sender/
Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Email-Sender-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl(Capture::Tiny) = 0.08
+BuildRequires: perl(Carp)
BuildRequires: perl(Config)
BuildRequires: perl(Cwd)
BuildRequires: perl(Data::Dumper)
-BuildRequires: perl(Email::Abstract) = 3
+BuildRequires: perl(Email::Abstract) = 3.006
BuildRequires: perl(Email::Address)
BuildRequires: perl(Email::Simple) = 1.998
+BuildRequires: perl(Errno)
BuildRequires: perl(Exporter)
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.11
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Fcntl)
+BuildRequires: perl(File::Basename)
+BuildRequires: perl(File::Path) = 2.06
+BuildRequires: perl(File::Spec)
BuildRequires: perl(File::Temp)
+BuildRequires: perl(IO::File)
+BuildRequires: perl(IO::Handle)
BuildRequires: perl(JSON)
+BuildRequires: perl(lib)
BuildRequires: perl(List::MoreUtils)
-BuildRequires: perl(Moose) = 0.70
-BuildRequires: perl(Moose::Role)
+BuildRequires: perl(Module::Runtime)
+BuildRequires: perl(Moo) = 1.08
+BuildRequires: perl(Moo::Role)
+BuildRequires: perl(MooX::Types::MooseLike::Base)
BuildRequires: perl(Net::SMTP)
BuildRequires: perl(Net::SMTP::SSL)
BuildRequires: perl(Pod::Coverage::TrustPod)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(strict)
BuildRequires: perl(Sub::Exporter)
BuildRequires: perl(Sub::Exporter::Util)
BuildRequires: perl(Sub::Override)
+BuildRequires: perl(Sys::Hostname)
BuildRequires: perl(Test::MinimumVersion)
BuildRequires: perl(Test::MockObject)
BuildRequires: perl(Test::More) = 0.96
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::Pod::Coverage)
-BuildRequires: perl(Throwable::Error) = 0.100090
+BuildRequires: perl(Test::Pod) = 1.41
+BuildRequires: perl(Throwable::Error) = 0.23
BuildRequires: perl(Try::Tiny)
-Requires: perl(Email::Abstract) = 3
+BuildRequires: perl(warnings)
+Requires: perl(Email::Abstract) = 3.006
Requires: perl(Net::SMTP::SSL)
-Requires: perl(Throwable::Error) = 0.100090
+Requires: perl(Throwable::Error) = 0.23
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%{?perl_default_filter}
@@ -72,6 +86,9 @@ RELEASE_TESTING=1 make test
%{_mandir}/man3/*
%changelog
+* Fri Oct 31 2014 Jitka Plesnikova jples...@redhat.com - 1.300016-1
+- 1.300016 bump
+
* Mon Sep 01 2014 Jitka Plesnikova jples...@redhat.com - 0.120002-6
- Perl 5.20 rebuild
diff --git a/sources b/sources
index f5cf315..a1e465e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8671410f17dc316d925bbcdeb97af9c6 Email-Sender-0.120002.tar.gz
+758b2dcb2ca1dfb6f9c94ddf94aa0a57 Email-Sender-1.300016.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
Broken dependencies: perl-Qt
perl-Qt has broken dependencies in the rawhide tree: On x86_64: perl-Qt-0.96.0-11.fc22.x86_64 requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.x86_64 requires libperl.so.5.18()(64bit) On i386: perl-Qt-0.96.0-11.fc22.i686 requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.i686 requires libperl.so.5.18 On armhfp: perl-Qt-0.96.0-11.fc22.armv7hl requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.armv7hl requires libperl.so.5.18 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
[perl-Throwable/f21] 0.200012 bump
commit b222b8a852b633ba269b7641f44a2bdd87a8fe89
Author: Jitka Plesnikova jples...@redhat.com
Date: Fri Oct 31 12:16:00 2014 +0100
0.200012 bump
.gitignore |1 +
perl-Throwable.spec | 34 +++---
sources |2 +-
3 files changed, 25 insertions(+), 12 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index dcf69b7..14c355a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Throwable-0.101110.tar.gz
Throwable-0.102080.tar.gz
+/Throwable-0.200012.tar.gz
diff --git a/perl-Throwable.spec b/perl-Throwable.spec
index 4da71c7..c00c5a4 100644
--- a/perl-Throwable.spec
+++ b/perl-Throwable.spec
@@ -1,22 +1,31 @@
Name: perl-Throwable
-Version:0.102080
-Release:12%{?dist}
+Version:0.200012
+Release:1%{?dist}
Summary:Role for classes that can be thrown
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Throwable/
Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Throwable-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(Devel::StackTrace) = 1.21
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker) = 6.11
-BuildRequires: perl(Moose) = 0.87
-BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::Pod::Coverage)
-BuildRequires: perl(Pod::Coverage::TrustPod)
-
-Requires: perl(Devel::StackTrace) = 1.21
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+# Run-time
+BuildRequires: perl(Carp)
+BuildRequires: perl(Devel::StackTrace) = 1.32
+BuildRequires: perl(Module::Runtime) = 0.002
+BuildRequires: perl(Moo) = 1.01
+BuildRequires: perl(Moo::Role)
+BuildRequires: perl(overload)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Sub::Quote)
+# Tests
+BuildRequires: perl(base)
+BuildRequires: perl(Test::More) = 0.96
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(Devel::StackTrace) = 1.32
+Requires: perl(overload)
%{?perl_default_filter}
@@ -41,7 +50,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
-RELEASE_TESTING=1 make test
+make test
%files
%defattr(-,root,root,-)
@@ -50,6 +59,9 @@ RELEASE_TESTING=1 make test
%{_mandir}/man3/*
%changelog
+* Fri Oct 31 2014 Jitka Plesnikova jples...@redhat.com - 0.200012-1
+- 0.200012 bump
+
* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.102080-12
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
diff --git a/sources b/sources
index 46fbe41..a510396 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f048e133a92eab91a1975001d2a55a38 Throwable-0.102080.tar.gz
+458e43d3ec7a816720d5f6aa614b46e1 Throwable-0.200012.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: FESCo to orphan iarnell's packages
On Thu, Oct 30, 2014 at 03:15:00PM +0100, Petr Pisar wrote: Hello, as you could read in last (2014-10-29) FESCo meeting minutes https://lists.fedoraproject.org/pipermail/devel/2014-October/203801.html, packages under Iain Arnell's maintence https://admin.fedoraproject.org/pkgdb/packager/iarnell/ will be orphaned because Iain is not functional anymore. It's about four hunders mostly Perl packages. Please feel free to take care about them after dgilmore announces the act on the Fedora devel mailing list. -- Petr I'm willing to maintain most of them. I hope it won't be just me, however :) P pgp__7ngGLft6.pgp Description: PGP signature -- 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-Throwable/f20] 0.200012 bump
commit 2760eda5d4a2e8f522756e180dd71bab529605d4
Author: Jitka Plesnikova jples...@redhat.com
Date: Fri Oct 31 12:45:45 2014 +0100
0.200012 bump
.gitignore |1 +
perl-Throwable.spec | 34 +++---
sources |2 +-
3 files changed, 25 insertions(+), 12 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index dcf69b7..14c355a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Throwable-0.101110.tar.gz
Throwable-0.102080.tar.gz
+/Throwable-0.200012.tar.gz
diff --git a/perl-Throwable.spec b/perl-Throwable.spec
index bbeca7c..a40d804 100644
--- a/perl-Throwable.spec
+++ b/perl-Throwable.spec
@@ -1,22 +1,31 @@
Name: perl-Throwable
-Version:0.102080
-Release:11%{?dist}
+Version:0.200012
+Release:1%{?dist}
Summary:Role for classes that can be thrown
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Throwable/
Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Throwable-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(Devel::StackTrace) = 1.21
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker) = 6.11
-BuildRequires: perl(Moose) = 0.87
-BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::Pod::Coverage)
-BuildRequires: perl(Pod::Coverage::TrustPod)
-
-Requires: perl(Devel::StackTrace) = 1.21
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+# Run-time
+BuildRequires: perl(Carp)
+BuildRequires: perl(Devel::StackTrace) = 1.32
+BuildRequires: perl(Module::Runtime) = 0.002
+BuildRequires: perl(Moo) = 1.01
+BuildRequires: perl(Moo::Role)
+BuildRequires: perl(overload)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Sub::Quote)
+# Tests
+BuildRequires: perl(base)
+BuildRequires: perl(Test::More) = 0.96
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(Devel::StackTrace) = 1.32
+Requires: perl(overload)
%{?perl_default_filter}
@@ -41,7 +50,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
-RELEASE_TESTING=1 make test
+make test
%files
%defattr(-,root,root,-)
@@ -50,6 +59,9 @@ RELEASE_TESTING=1 make test
%{_mandir}/man3/*
%changelog
+* Fri Oct 31 2014 Jitka Plesnikova jples...@redhat.com - 0.200012-1
+- 0.200012 bump
+
* Wed Jan 29 2014 Ralf Corsépius corse...@fedoraproject.org - 0.102080-11
- Remove bogus R: perl(ExtUtils::MakeMaker) (RHBZ #1052853).
- Remove redundant R: perl(Moose).
diff --git a/sources b/sources
index 46fbe41..a510396 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f048e133a92eab91a1975001d2a55a38 Throwable-0.102080.tar.gz
+458e43d3ec7a816720d5f6aa614b46e1 Throwable-0.200012.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 1159047] Please update to at least v1.300011
https://bugzilla.redhat.com/show_bug.cgi?id=1159047 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Assignee|iarn...@gmail.com |jples...@redhat.com -- 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=2BEjWtdFKYa=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
File Net-DNS-SEC-0.21.tar.gz uploaded to lookaside cache by pwouters
A file has been added to the lookaside cache for perl-Net-DNS-SEC: 4cd803cf77f853b3079fdf539aa92749 Net-DNS-SEC-0.21.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-Net-DNS-SEC] - Updated to 0.21, restores canonicalization of a RRSIG’s Signer Name
commit 8f8d1c603165a34c5086b1d250f80dc99193a09d
Author: Paul Wouters pwout...@redhat.com
Date: Fri Oct 31 11:00:36 2014 -0400
- Updated to 0.21, restores canonicalization of a RRSIG’s Signer Name
.gitignore|1 +
perl-Net-DNS-SEC.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index aa5af1c..fdbe9d3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@ Net-DNS-SEC-0.14.tar.gz
/Net-DNS-SEC-0.17.tar.gz
/Net-DNS-SEC-0.18.tar.gz
/Net-DNS-SEC-0.20.tar.gz
+/Net-DNS-SEC-0.21.tar.gz
diff --git a/perl-Net-DNS-SEC.spec b/perl-Net-DNS-SEC.spec
index 81ac06b..b9c3e8e 100644
--- a/perl-Net-DNS-SEC.spec
+++ b/perl-Net-DNS-SEC.spec
@@ -1,6 +1,6 @@
Name: perl-Net-DNS-SEC
-Version:0.20
-Release:2%{?dist}
+Version:0.21
+Release:1%{?dist}
Summary:DNSSEC modules for Perl
License:GPL+ or Artistic
Group: Development/Libraries
@@ -61,6 +61,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Oct 31 2014 Paul Wouters pwout...@redhat.com - 0.21-1
+- Updated to 0.21, restores canonicalization of a RRSIG’s Signer Name
+
* Thu Aug 28 2014 Jitka Plesnikova jples...@redhat.com - 0.20-2
- Perl 5.20 rebuild
diff --git a/sources b/sources
index ffa1467..3214f15 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8f376c0e2473744689457efa642f75bf Net-DNS-SEC-0.20.tar.gz
+4cd803cf77f853b3079fdf539aa92749 Net-DNS-SEC-0.21.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-Email-Sender/f21] 1.300016 bump
commit f4dc437d0055e03948f4530eeed14cae6596002b
Author: Jitka Plesnikova jples...@redhat.com
Date: Fri Oct 31 16:00:04 2014 +0100
1.300016 bump
.gitignore |1 +
perl-Email-Sender.spec | 39 ---
sources|2 +-
3 files changed, 30 insertions(+), 12 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a9b9972..fec99a6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@ Email-Sender-0.101760.tar.gz
/Email-Sender-0.110005.tar.gz
/Email-Sender-0.120001.tar.gz
/Email-Sender-0.120002.tar.gz
+/Email-Sender-1.300016.tar.gz
diff --git a/perl-Email-Sender.spec b/perl-Email-Sender.spec
index 93b3f80..ac5db64 100644
--- a/perl-Email-Sender.spec
+++ b/perl-Email-Sender.spec
@@ -1,6 +1,6 @@
Name: perl-Email-Sender
-Version:0.120002
-Release:5%{?dist}
+Version:1.300016
+Release:1%{?dist}
Summary:A library for sending email
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,35 +8,49 @@ URL:http://search.cpan.org/dist/Email-Sender/
Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Email-Sender-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl(Capture::Tiny) = 0.08
+BuildRequires: perl(Carp)
BuildRequires: perl(Config)
BuildRequires: perl(Cwd)
BuildRequires: perl(Data::Dumper)
-BuildRequires: perl(Email::Abstract) = 3
+BuildRequires: perl(Email::Abstract) = 3.006
BuildRequires: perl(Email::Address)
BuildRequires: perl(Email::Simple) = 1.998
+BuildRequires: perl(Errno)
BuildRequires: perl(Exporter)
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.11
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Fcntl)
+BuildRequires: perl(File::Basename)
+BuildRequires: perl(File::Path) = 2.06
+BuildRequires: perl(File::Spec)
BuildRequires: perl(File::Temp)
+BuildRequires: perl(IO::File)
+BuildRequires: perl(IO::Handle)
BuildRequires: perl(JSON)
+BuildRequires: perl(lib)
BuildRequires: perl(List::MoreUtils)
-BuildRequires: perl(Moose) = 0.70
-BuildRequires: perl(Moose::Role)
+BuildRequires: perl(Module::Runtime)
+BuildRequires: perl(Moo) = 1.08
+BuildRequires: perl(Moo::Role)
+BuildRequires: perl(MooX::Types::MooseLike::Base)
BuildRequires: perl(Net::SMTP)
BuildRequires: perl(Net::SMTP::SSL)
BuildRequires: perl(Pod::Coverage::TrustPod)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(strict)
BuildRequires: perl(Sub::Exporter)
BuildRequires: perl(Sub::Exporter::Util)
BuildRequires: perl(Sub::Override)
+BuildRequires: perl(Sys::Hostname)
BuildRequires: perl(Test::MinimumVersion)
BuildRequires: perl(Test::MockObject)
BuildRequires: perl(Test::More) = 0.96
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::Pod::Coverage)
-BuildRequires: perl(Throwable::Error) = 0.100090
+BuildRequires: perl(Test::Pod) = 1.41
+BuildRequires: perl(Throwable::Error) = 0.23
BuildRequires: perl(Try::Tiny)
-Requires: perl(Email::Abstract) = 3
+BuildRequires: perl(warnings)
+Requires: perl(Email::Abstract) = 3.006
Requires: perl(Net::SMTP::SSL)
-Requires: perl(Throwable::Error) = 0.100090
+Requires: perl(Throwable::Error) = 0.23
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%{?perl_default_filter}
@@ -72,6 +86,9 @@ RELEASE_TESTING=1 make test
%{_mandir}/man3/*
%changelog
+* Fri Oct 31 2014 Jitka Plesnikova jples...@redhat.com -1.300016-1
+- 1.300016 bump
+
* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.120002-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
diff --git a/sources b/sources
index f5cf315..a1e465e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8671410f17dc316d925bbcdeb97af9c6 Email-Sender-0.120002.tar.gz
+758b2dcb2ca1dfb6f9c94ddf94aa0a57 Email-Sender-1.300016.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-Net-DNS-SEC/f21] (3 commits) ...- Updated to 0.21, restores canonicalization of a RRSIG’s Signer Name
Summary of changes: a76e169... * Sat Aug 16 2014 Paul Wouters pwout...@redhat.com - 0.20 (*) bc6ab3b... Perl 5.20 rebuild (*) 8f8d1c6... - Updated to 0.21, restores canonicalization of a RRSIG’s (*) (*) This commit already existed in another branch; no separate mail sent -- 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-Net-DNS-SEC/f20: 3/3] Merge branch 'master' into f20
commit ffebbcb585f9c27052f6abbd5dc23365449694e3 Merge: 75f20d1 8f8d1c6 Author: Paul Wouters pwout...@redhat.com Date: Fri Oct 31 11:10:07 2014 -0400 Merge branch 'master' into f20 .gitignore|1 + perl-Net-DNS-SEC.spec |8 +++- sources |2 +- 3 files changed, 9 insertions(+), 2 deletions(-) --- -- 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-Net-DNS-SEC/f20] (3 commits) ...Merge branch 'master' into f20
Summary of changes: bc6ab3b... Perl 5.20 rebuild (*) 8f8d1c6... - Updated to 0.21, restores canonicalization of a RRSIG’s (*) ffebbcb... Merge branch 'master' into f20 (*) This commit already existed in another branch; no separate mail sent -- 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-Net-DNS-SEC/el6] - Updated to 0.21, restores canonicalization of a RRSIG’s Signer Name
commit 9945af6cd0dba15e41455f4b872ed07404d07cf1
Author: Paul Wouters pwout...@redhat.com
Date: Fri Oct 31 11:13:53 2014 -0400
- Updated to 0.21, restores canonicalization of a RRSIG’s Signer Name
.gitignore|1 +
perl-Net-DNS-SEC.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index aa5af1c..fdbe9d3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@ Net-DNS-SEC-0.14.tar.gz
/Net-DNS-SEC-0.17.tar.gz
/Net-DNS-SEC-0.18.tar.gz
/Net-DNS-SEC-0.20.tar.gz
+/Net-DNS-SEC-0.21.tar.gz
diff --git a/perl-Net-DNS-SEC.spec b/perl-Net-DNS-SEC.spec
index fb0d8da..5947016 100644
--- a/perl-Net-DNS-SEC.spec
+++ b/perl-Net-DNS-SEC.spec
@@ -1,5 +1,5 @@
Name: perl-Net-DNS-SEC
-Version:0.20
+Version:0.21
Release:1%{?dist}
Summary:DNSSEC modules for Perl
License:GPL+ or Artistic
@@ -61,6 +61,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Oct 31 2014 Paul Wouters pwout...@redhat.com - 0.21-1
+- Updated to 0.21, restores canonicalization of a RRSIG’s Signer Name
+
* Sat Aug 16 2014 Paul Wouters pwout...@redhat.com - 0.20-1
- Updated to 0.20, fixes - (zero) salt fields in NSEC3 representation
- Remove inappropriate deprecation warning in DNSKEY.pm (0.19 upstream)
diff --git a/sources b/sources
index ffa1467..3214f15 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8f376c0e2473744689457efa642f75bf Net-DNS-SEC-0.20.tar.gz
+4cd803cf77f853b3079fdf539aa92749 Net-DNS-SEC-0.21.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 1159047] Please update to at least v1.300011
https://bugzilla.redhat.com/show_bug.cgi?id=1159047 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-Email-Sender-1.300016-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-Email-Sender-1.300016-1.fc21 -- 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=FctQcUbVv4a=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-Email-Sender/f20] 1.300016 bump
commit 9edf3fb8869d7168e382897a6c2c4e1452147cec
Author: Jitka Plesnikova jples...@redhat.com
Date: Fri Oct 31 16:32:27 2014 +0100
1.300016 bump
.gitignore |1 +
perl-Email-Sender.spec | 39 ---
sources|2 +-
3 files changed, 30 insertions(+), 12 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a9b9972..fec99a6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@ Email-Sender-0.101760.tar.gz
/Email-Sender-0.110005.tar.gz
/Email-Sender-0.120001.tar.gz
/Email-Sender-0.120002.tar.gz
+/Email-Sender-1.300016.tar.gz
diff --git a/perl-Email-Sender.spec b/perl-Email-Sender.spec
index 4fbce43..df065e6 100644
--- a/perl-Email-Sender.spec
+++ b/perl-Email-Sender.spec
@@ -1,6 +1,6 @@
Name: perl-Email-Sender
-Version:0.120002
-Release:4%{?dist}
+Version:1.300016
+Release:1%{?dist}
Summary:A library for sending email
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,35 +8,49 @@ URL:http://search.cpan.org/dist/Email-Sender/
Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Email-Sender-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl(Capture::Tiny) = 0.08
+BuildRequires: perl(Carp)
BuildRequires: perl(Config)
BuildRequires: perl(Cwd)
BuildRequires: perl(Data::Dumper)
-BuildRequires: perl(Email::Abstract) = 3
+BuildRequires: perl(Email::Abstract) = 3.006
BuildRequires: perl(Email::Address)
BuildRequires: perl(Email::Simple) = 1.998
+BuildRequires: perl(Errno)
BuildRequires: perl(Exporter)
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.11
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Fcntl)
+BuildRequires: perl(File::Basename)
+BuildRequires: perl(File::Path) = 2.06
+BuildRequires: perl(File::Spec)
BuildRequires: perl(File::Temp)
+BuildRequires: perl(IO::File)
+BuildRequires: perl(IO::Handle)
BuildRequires: perl(JSON)
+BuildRequires: perl(lib)
BuildRequires: perl(List::MoreUtils)
-BuildRequires: perl(Moose) = 0.70
-BuildRequires: perl(Moose::Role)
+BuildRequires: perl(Module::Runtime)
+BuildRequires: perl(Moo) = 1.08
+BuildRequires: perl(Moo::Role)
+BuildRequires: perl(MooX::Types::MooseLike::Base)
BuildRequires: perl(Net::SMTP)
BuildRequires: perl(Net::SMTP::SSL)
BuildRequires: perl(Pod::Coverage::TrustPod)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(strict)
BuildRequires: perl(Sub::Exporter)
BuildRequires: perl(Sub::Exporter::Util)
BuildRequires: perl(Sub::Override)
+BuildRequires: perl(Sys::Hostname)
BuildRequires: perl(Test::MinimumVersion)
BuildRequires: perl(Test::MockObject)
BuildRequires: perl(Test::More) = 0.96
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::Pod::Coverage)
-BuildRequires: perl(Throwable::Error) = 0.100090
+BuildRequires: perl(Test::Pod) = 1.41
+BuildRequires: perl(Throwable::Error) = 0.23
BuildRequires: perl(Try::Tiny)
-Requires: perl(Email::Abstract) = 3
+BuildRequires: perl(warnings)
+Requires: perl(Email::Abstract) = 3.006
Requires: perl(Net::SMTP::SSL)
-Requires: perl(Throwable::Error) = 0.100090
+Requires: perl(Throwable::Error) = 0.23
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%{?perl_default_filter}
@@ -72,6 +86,9 @@ RELEASE_TESTING=1 make test
%{_mandir}/man3/*
%changelog
+* Fri Oct 31 2014 Jitka Plesnikova jples...@redhat.com - 1.300016-1
+- 1.300016 bump
+
* Mon Aug 05 2013 Petr Pisar ppi...@redhat.com - 0.120002-4
- Perl 5.18 rebuild
diff --git a/sources b/sources
index f5cf315..a1e465e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8671410f17dc316d925bbcdeb97af9c6 Email-Sender-0.120002.tar.gz
+758b2dcb2ca1dfb6f9c94ddf94aa0a57 Email-Sender-1.300016.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 1159047] Please update to at least v1.300011
https://bugzilla.redhat.com/show_bug.cgi?id=1159047 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-Email-Sender-1.300016-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Email-Sender-1.300016-1.fc20 -- 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=AvIy7LNzPRa=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: FESCo to orphan iarnell's packages
* Petr Šabata [31/10/2014 12:27] : I'm willing to maintain most of them. I hope it won't be just me, however :) I'll be glad to give a hand, especially for all HTML/HTTP-related modules. Emmanuel -- 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-Locale-Maketext-Fuzzy/f20] Upstream upgrade.
Summary of changes: 3becdbc... Upstream upgrade. (*) (*) This commit already existed in another branch; no separate mail sent -- 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 1136340] perl-Qt-0.96.0-12.fc22: FTBFS with Perl 5.20
https://bugzilla.redhat.com/show_bug.cgi?id=1136340 Chris chrisbu...@gmail.com changed: What|Removed |Added CC||chrisbu...@gmail.com --- Comment #9 from Chris chrisbu...@gmail.com --- This appears to be a change in Perl's behavior. The way the operator overloading in PerlQt works is that it first tries to find an operator method on the class itself, and then next it tries to find one in the so-called QGlobalSpace, which is a place defined by the smoke library for global Qt functions. Perl passes the underlying XS code the full package and function being called, which PerlQt splits into 2 strings, one for the package name, and one for the method name. PerlQt null-terminates the package name string, and in previous versions of Perl, this modification did not affect the source $AUTOLOAD variable. In Perl 5.20.0, it does update the Perl variable, and then causes confusion down the line. I've pushed both Petr's change, and a change to fix this issue, to the master branch in perlqt's git repo at git://anongit.kde.org/perlqt. Can someone try it out? -- 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=Myhc6HxrS4a=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-qpid/f20] (15 commits) ...Rebased on Qpid 0.30 rebased.
Summary of changes: 85c9d7c... Rebased on Qpid 0.22. (*) fb3b419... Perl Makefile.PL now generates the Swig bindings source. (*) e88eed1... Updated build to fix dependency issues on qpid-cpp. (*) 11fcf0d... Rebased on Qpid 0.24. (*) ab54c51... Merge branch 'master' into f19 (*) 448e6f4... Merge branch 'f20' into f19 (*) f97686f... Rebase on Qpid 0.28. (*) f0c7c8f... - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass (*) 2d2a2ed... qpid-cpp now builds on ARM (*) 2a322ac... Updated the virtual package dependencies. (*) 19552ba... Merge branch 'master' into f21 (*) e55afa6... - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_M (*) 185facd... Fixed a typo in the requires. (*) 92466c1... Perl 5.20 rebuild (*) 14b81f1... Rebased on Qpid 0.30 rebased. (*) (*) This commit already existed in another branch; no separate mail sent -- 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 1078083] CVE-2014-2525 libyaml: heap-based buffer overflow when parsing URLs
https://bugzilla.redhat.com/show_bug.cgi?id=1078083 Marianne Feifer mfei...@redhat.com changed: What|Removed |Added CC|mfei...@redhat.com | Kurt Seifried kseifr...@redhat.com changed: What|Removed |Added Whiteboard|impact=important,public=201 |impact=important,public=201 |40327,reported=20140318,sou |40327,reported=20140318,sou |rce=distros,cvss2=6.8/AV:N/ |rce=distros,cvss2=6.8/AV:N/ |AC:M/Au:N/C:P/I:P/A:P,rhel- |AC:M/Au:N/C:P/I:P/A:P,rhel- |6/libyaml=affected,rhel-7/l |6/libyaml=affected,rhel-7/l |ibyaml=affected,rhscl-1/rub |ibyaml=affected,rhscl-1/rub |y193-libyaml=affected,rhscl |y193-libyaml=affected,rhscl |-1/libyaml=affected,mrg-1/l |-1/libyaml=affected,mrg-1/l |ibyaml=wontfix,mrg-2/libyam |ibyaml=wontfix,mrg-2/libyam |l=wontfix,rhn_satellite_5.3 |l=wontfix,rhn_satellite_5.3 |/libyaml=affected,rhn_satel |/libyaml=affected,rhn_satel |lite_5.4/libyaml=affected,r |lite_5.4/libyaml=affected,r |hn_satellite_5.5/libyaml=af |hn_satellite_5.5/libyaml=af |fected,rhn_satellite_5.6/li |fected,rhn_satellite_5.6/li |byaml=affected,rhn_satellit |byaml=affected,rhn_satellit |e_6/libyaml=affected,rhui-2 |e_6/libyaml=affected,rhui-2 |/libyaml=wontfix,sam-1/liby |/libyaml=wontfix,sam-1/liby |aml=defer,cfme-5/mingw-liby |aml=defer,cfme-5/mingw-liby |aml=defer,cfme-5/ruby193-li |aml=wontfix,cfme-5/ruby193- |byaml=defer,openstack-3/lib |libyaml=affected,openstack- |yaml=affected,openstack-3/r |3/libyaml=affected,openstac |uby193-libyaml=affected,ope |k-3/ruby193-libyaml=affecte |nstack-4/libyaml=affected,o |d,openstack-4/libyaml=affec |penshift-enterprise-1/ruby1 |ted,openshift-enterprise-1/ |93-libyaml=wontfix,openshif |ruby193-libyaml=wontfix,ope |t-1/ruby193-libyaml=affecte |nshift-1/ruby193-libyaml=af |d,fedora-all/libyaml=affect |fected,fedora-all/libyaml=a |ed,epel-all/libyaml=affecte |ffected,epel-all/libyaml=af |d,fedora-all/perl-YAML-LibY |fected,fedora-all/perl-YAML |AML=affected,epel-6/perl-YA |-LibYAML=affected,epel-6/pe |ML-LibYAML=affected |rl-YAML-LibYAML=affected -- 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=F5MTEYZhwya=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 1078083] CVE-2014-2525 libyaml: heap-based buffer overflow when parsing URLs
https://bugzilla.redhat.com/show_bug.cgi?id=1078083 Kurt Seifried kseifr...@redhat.com changed: What|Removed |Added Depends On||1159403 Depends On||1159404 -- 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=5OjhtbrSpxa=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 1017972] [abrt] shutter-0.90-2.fc19: g_str_hash: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
https://bugzilla.redhat.com/show_bug.cgi?id=1017972 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||shutter-0.93-1.fc20 Resolution|--- |ERRATA Last Closed||2014-10-31 21:44:44 --- Comment #14 from Fedora Update System upda...@fedoraproject.org --- shutter-0.93-1.fc20, perl-WebService-Dropbox-1.22-2.fc20 has been pushed to the Fedora 20 stable repository. -- 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=pavujEDqy0a=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 1153984] perl-WebService-Linode-0.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1153984 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-WebService-Linode-0.23 ||-1.fc20 Resolution|--- |ERRATA Last Closed||2014-10-31 21:46:37 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-WebService-Linode-0.23-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=wOvNxnGYMSa=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
