Re: Why sysrq is limited to only sync command on official fedora kernel?
On 02/27/2015 06:14 PM, Nico Kadel-Garcia wrote: Except, of course, that it is apparently Leonard Pottering's announced desire to stop people from using /etc/ No, it's not. Why do people insist on misinterpreting him? He wants it to be possible to have a read-only / (including /etc), so *dynamic* information needs to be stored elsewhere. -- 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: Why sysrq is limited to only sync command on official fedora kernel?
On Wed, Feb 25, 2015 at 9:39 AM, Michal Schmidt mschm...@redhat.com wrote: On 02/25/2015 03:04 PM, Josh Boyer wrote: On Wed, Feb 25, 2015 at 8:54 AM, Ali AlipourR alipoo...@gmail.com wrote: Hi, Why sysrq is limited to only sync command on official fedora kernel? The kernel itself isn't limited. It's just set that way in /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You can edit that file, The file in /usr will be overwritten by the next package update. create your own in /etc/sysctl.d/, Yes, local configuration belongs to /etc. See also man sysctl.d. Except, of course, that it is apparently Leonard Pottering's announced desire to stop people from using /etc/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1195573] Review Request: dropbox-api-command - Dropbox API wrapper command
https://bugzilla.redhat.com/show_bug.cgi?id=1195573 --- Comment #9 from Ben Boeckel maths...@gmail.com --- Spec URL: http://mathstuf.fedorapeople.org//dropbox-api-command.spec SRPM URL: http://mathstuf.fedorapeople.org//dropbox-api-command-1.17-3.fc23.src.rpm http://koji.fedoraproject.org/koji/taskinfo?taskID=9096721 -- 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=IMN9xIHGuBa=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: Apps using default Python in Fedora vs. EPEL
Miro Hrončok пишет: On 27.2.2015 21:06, Miro Hrončok wrote: Oh it seems only in the latest revision someone took the courtesy of translating it all to Russian. That text is machine-translated and poorly at that. -- Zart ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
[Test-Announce] 2015-03-02 @ 1700 UTC ** Fedora 22 Blocker Review Meeting
# F22 Blocker Review meeting # Date: 2015-03-02 # Time: 1700 UTC # Location: #fedora-blocker-review on irc.freenode.net Another week and a couple TCs later, it's time for some blocker review goodness! Also, as an added bonus, Alpha Freeze is upon us so we get to look over FE bugs as well. Currently we have 8/1/0 for blockers and 10/0/0 FE's to look at. It'll likely be a longer meeting than what we've grown accustomed to, so take some time this weekend to check out the proposals (you can even vote in the bug comments if you like). If you want to take a look at the proposed or accepted blockers, the full list can be found here: https://qa.fedoraproject.org/blockerbugs/ We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F22 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting See you Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org ___ 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
[EPEL-devel] distribution component in bugzilla
Could we get a Distribution component for Fedora EPEL in Bugzilla? Might be useful for things like https://bugzilla.redhat.com/show_bug.cgi?id=1197264 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Why sysrq is limited to only sync command on official fedora kernel?
Am 28.02.2015 um 03:14 schrieb Nico Kadel-Garcia: On Wed, Feb 25, 2015 at 9:39 AM, Michal Schmidt mschm...@redhat.com wrote: On 02/25/2015 03:04 PM, Josh Boyer wrote: On Wed, Feb 25, 2015 at 8:54 AM, Ali AlipourR alipoo...@gmail.com wrote: Hi, Why sysrq is limited to only sync command on official fedora kernel? The kernel itself isn't limited. It's just set that way in /usr/lib/sysctl.d/50-default.conf which is provided by systemd. You can edit that file, The file in /usr will be overwritten by the next package update. create your own in /etc/sysctl.d/, Yes, local configuration belongs to /etc. See also man sysctl.d. Except, of course, that it is apparently Leonard Pottering's announced desire to stop people from using /etc/ stop that trolling *local* CONFIGURATIONS belong to /etc and nothing else Lennarts point is that any defaults and package data don't belong there and he is not completly wrong in that context - in the best case you would have a operating system with *nothing* in /etc and any package shipped stuff can have a *override* file with the same name in /etc at the end this would also obsolete all that rpmnew / rpmsave stuff just because files from packages would no longer be touched by a user but *completly* ignored from the moment there is a replacement in /etc 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
[389-devel] Build failed in Jenkins: 389-ds-base #512
See http://jenkins.cloud.fedoraproject.org/job/389-ds-base/512/changes
Changes:
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
[Noriko Hosoi] Ticket #48048 - Fix coverity issues - 2015/2/24
--
Started by an SCM change
Building remotely on Fedora20 in workspace
http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/
Wiping out workspace first.
Cloning the remote Git repository
Cloning repository git://git.fedorahosted.org/git/389/ds.git
git init http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/ #
timeout=10
Fetching upstream changes from git://git.fedorahosted.org/git/389/ds.git
git --version # timeout=10
git fetch --tags --progress git://git.fedorahosted.org/git/389/ds.git
+refs/heads/*:refs/remotes/origin/*
git config remote.origin.url git://git.fedorahosted.org/git/389/ds.git #
timeout=10
git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/* #
timeout=10
git config remote.origin.url git://git.fedorahosted.org/git/389/ds.git #
timeout=10
Fetching upstream changes from git://git.fedorahosted.org/git/389/ds.git
git fetch --tags --progress git://git.fedorahosted.org/git/389/ds.git
+refs/heads/*:refs/remotes/origin/*
git rev-parse origin/master^{commit} # timeout=10
Checking out Revision 1f59d618b7cadc7df46c05025cf2fd93f0449654 (origin/master)
git config core.sparsecheckout # timeout=10
git checkout -f 1f59d618b7cadc7df46c05025cf2fd93f0449654
git rev-list 1aeaf342ff5050cfda23e05ae66b180a56a70e0e # timeout=10
[389-ds-base] $ /bin/sh -e /tmp/hudson2901972639951056040.sh
Running configure...
CFLAGS= -Wall CXXFLAGS= -Wall ./configure --with-tmpfiles-d=/etc/tmpfiles.d
--with-openldap --enable-autobind --with-selinux
--with-systemdsystemunitdir=/lib/systemd/system
--with-systemdsystemconfdir=/etc/systemd/system --enable-debug
Build log is
http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/build.512.txt
Running make...
Build log is
http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/build.512.txt
Checking for warnings...
Build http://jenkins.cloud.fedoraproject.org/job/389-ds-base/512/ failed
There are build warnings
Warning log is
http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/build-warns.512.txt
Last 100 lines of warning log:
ldap/servers/slapd/log.c:2296:4: warning: format '%ld' expects argument of type
'long int', but argument 8 has type 'long long int' [-Wformat=]
ldap/servers/slapd/log.c:3909:4: warning:
[Bug 1195573] Review Request: dropbox-api-command - Dropbox API wrapper command
https://bugzilla.redhat.com/show_bug.cgi?id=1195573
--- Comment #10 from Ben Boeckel maths...@gmail.com ---
Spec URL: http://mathstuf.fedorapeople.org//dropbox-api-command.spec
SRPM URL:
http://mathstuf.fedorapeople.org//dropbox-api-command-1.17-4.fc23.src.rpm
http://koji.fedoraproject.org/koji/taskinfo?taskID=9096834
So --prefix is required and %{perl_vendorlib} is the wrong path.
--
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=AX7An31vPHa=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: koji is broken
I still met
Could not execute build: [('SSL routines', 'SSL3_WRITE_BYTES', 'ssl
handshake failure')]
this morning (2 hrs ago).
--
Yours sincerely,
Christopher Meng
http://cicku.me
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[389-devel] Jenkins build is back to normal : 389-ds-base #513
See http://jenkins.cloud.fedoraproject.org/job/389-ds-base/513/changes -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/26/2015 02:54 PM, Miloslav Trmač wrote: = Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora == Detailed Description == This is no real work proposal. Stepping back, I’m not sure this has been said explicitly: this is really a packaging guideline proposal, not really a Change, so it should probably go through the FPC. (https://fedoraproject.org/wiki/Packaging_Committee?rd=Packaging:Committee#Guideline_Change_Procedure ) (This is not intended to kill or affect the implementation details discussion at all. I’m just trying to minimize the bureaucracy (hah!) by not setting a precedent for doing it this way, so that all future packaging guideline proposals go directly to the FPC and skip this redirection step.) Mirek This proposal had been withdraw until real legacy JDK maintainer is found. https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora 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: systemd-219 issues with 22 and Rawhide composes
On Fri, Feb 27, 2015 at 8:18 AM, Nico Kadel-Garcia nka...@gmail.com wrote: Look, deciding to ignore the File System Hierarchy for installing config files and creating new locations to store system configuration is part of what killed the old daemontools init system replacement. tool. You and the other developers have gone well past that. But these are not tiny surprises, and the anaconda team is far, far, far from the only people who need a heads up on structural surprises like this. I seem to be having trouble with my positive and negative parity this morning. I meant that they've gone well past the stage of acceptance and deployment that daemontools ever reached, so it's unlikely to be effectively abandoned as daemontools has been. I'll restrain my technical comparisons. And you've introduced a permanent inconsistency between systems that were ever touched by an admin or a tool aware of symlinks, and one that has not been so touched. And introduced a backup configuration issue: network configuration backups, or even source control systems that store /etc/resolv.conf, all need to be tweaked. See above. I meant an admin *unaware* of symlinks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Compress-Raw-Lzma] Rebuild for xz-5.2.1 in Rawhide
commit eab644c67456c960432bc8667d0c091c2d7fd504
Author: Paul Howarth p...@city-fan.org
Date: Fri Feb 27 14:14:05 2015 +
Rebuild for xz-5.2.1 in Rawhide
perl-Compress-Raw-Lzma.spec | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
---
diff --git a/perl-Compress-Raw-Lzma.spec b/perl-Compress-Raw-Lzma.spec
index 80e0720..b83351b 100644
--- a/perl-Compress-Raw-Lzma.spec
+++ b/perl-Compress-Raw-Lzma.spec
@@ -1,6 +1,6 @@
Name: perl-Compress-Raw-Lzma
Version: 2.068
-Release: 2%{?dist}
+Release: 3%{?dist}
Summary: Low-level interface to lzma compression library
Group: Development/Libraries
License: GPL+ or Artistic
@@ -69,6 +69,9 @@ make test
%{_mandir}/man3/Compress::Raw::Lzma.3*
%changelog
+* Fri Feb 27 2015 Paul Howarth p...@city-fan.org - 2.068-3
+- Rebuild for xz-5.2.1 in Rawhide
+
* Tue Jan 6 2015 Paul Howarth p...@city-fan.org - 2.068-2
- Rebuild for xz-5.2.0 in Rawhide (#1179255)
--
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: [Scitech] OpenBabel rebase to pre-2.4 (current Git master)
On Friday, 27 February 2015 at 11:51, Alexander Ploumistos wrote: Do we need to tell upstream about these patches? Yes, it's part of maintainer responsibilities. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- 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: systemd-219 issues with 22 and Rawhide composes
On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nka...@gmail.com) wrote: [ notes snipped, ] You know, that systemd creates a symlink if the file is missing is not going to change behaviour of anything, since it will only do something if the file is *missing*. Congratulations. We now have inconsistent behavior if anyone, *ever*, edits /etc/resolf.conf with 'sed -i', uses rsync -a or cp -a tp reproduce it from a known good repository, and with a symlink in place we're storing absolutely critical system information in a non /etc location, meaning that non-modified backup systems won't get a copy with valid content. Just. great. Look, deciding to ignore the File System Hierarchy for installing config files and creating new locations to store system configuration is part of what killed the old daemontools init system replacement. tool. You and the other developers have gone well past that. But these are not tiny surprises, and the anaconda team is far, far, far from the only people who need a heads up on structural surprises like this. Hey, if you want to know what's going on in systemd development, then pelase join our upstream mailing list. You probably wouldn't like it. I'd scream about things like this. The time I can spare for this is spent cleaning up the mess when systemd based tools from Fedora are unusable under RHEL 5 or 6 without folks like me putting in hooks to detect and handle real init scripts, and vice versa. It's over hat https://github.com/nkadel/. And no, I will not forward all systemd design discussions to the fedora ML, it has no place there. We don't forward them to the suse, debian, ubuntu MLs either. This wasn't merely a discussion, it was an unexpected behavioral change in a vital system configuration file. For example, now if I manipulate /etc/resolv.conf for whatever reason, and I edit it with vi or a management tool like chef that is unaware of symlinks, I'll break the link. Will systemd correctly re-establish the link? Will it wipe out my change, Did anyone even *think* about this? Nope. All that systemd does is create it as symlinks if it is otherwise missing. If you put something else there, then that's what counts. And you've introduced a permanent inconsistency between systems that were ever touched by an admin or a tool aware of symlinks, and one that has not been so touched. And introduced a backup configuration issue: network configuration backups, or even source control systems that store /etc/resolv.conf, all need to be tweaked. These are not the largest of issues, but they're very real. Personally? I'd say either always use a symlink, or never use one. Please do not try to deduce the sys-admin's intent from which editing tool they happen to use and its secondary behavior. The handling of symlinks can seriously, seriously bite you at odd moments. This is also not a new problem: this is not the first time that out-of-band information got stuck someplace weird and took extra work and knowledge to deal with. When tools like system-config-network started hiding content in /etc/sysconfig/networking/profiles and /etc/sysconfig/networking/devices, some of us had to learn about scrubbing those away or making them consistent in order to make sure that /etc/sysconfig/network-scripts/ifcfg-* changes got propagated reliably in Fedora and RHEL systems. But it's a *surprise* when it happens, and it's extra work in day to day network administration. And yeah, it happened Monday dealing with virtualized OS image given a new MAC address and with old MAC address embedded in weird places. -- 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 Text-Sprintf-Named-0.0402.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Text-Sprintf-Named: bcdcdb39c34c91e8a8ab0e399e70e16f Text-Sprintf-Named-0.0402.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: SIMVoleon, SoQt rebuilt against Coin3 on f22 and rawhide
On 02/27/2015 02:56 PM, Richard Shaw wrote: I'm not sure if it will be a problem or not but FreeCAD 0.15 will require Coin3 and as far as I know will still require python-pivy which is currently built against Coin2. OK, inbetween your lines, you are right, I missed pivy. This will also have to be changed to use Coin3 on Fedora 21 - I'll try to take care of this. Once pivy has been rebuilt for Coin3 on Fedora 21, there should not be any Coin related issues (modulo bugs), which are preventing FreeCAD-0.15 to be added to Fedora 21. However, FreeCAD-0.15 may impose problems on Fedora = 21. Therefore, I'd first raise a couple of problem: - Do you plan to upgrade FreeCAD to 0.15 on Fedora = 21? - Do you or somebody else have a FreeCAD-0.15 rpm, which I could use to investigate for details? - As mentioned before, I want to understand the reasons why FreeCAD seems to insist on Coin3. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On 02/27/2015 01:18 PM, Nico Kadel-Garcia wrote: On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nka...@gmail.com) wrote: [ notes snipped, ] You know, that systemd creates a symlink if the file is missing is not going to change behaviour of anything, since it will only do something if the file is*missing*. Congratulations. We now have inconsistent behavior if anyone,*ever*, edits /etc/resolf.conf with 'sed -i', uses rsync -a or cp -a tp reproduce it from a known good repository, and with a symlink in place we're storing absolutely critical system information in a non /etc location, meaning that non-modified backup systems won't get a copy with valid content. Just. great. I guess you missed the part that it did nothing if the file existed. Even after spending what 8 years in Fedora's QA ( longer than any of their so called hired employee working in that area ) as well as handling the systemd integration for wide variety of component I was not even allowed to see RHEL systemd integration bug trackers until in some case other Red Hat employees ranted over their coworkers how stupid they were not allowing the guy handling the integration doing so. I know first hand the state of systemd in Fedora and I have seen the state it's in RHEL and I know Red Hat did nothing to improve the situation from what it was in Fedora not even make some of those implementations enterprise grade so regarding the rest of your rant neither upstream nor Fedora ( despite Red Hat royally abusing it's community and shape it in it's image ) has any control over any decisions Red Hat makes about it's RHEL release so use that support contract you are paying Red Hat for and wreak havoc with them. Hopefully that havoc from you and from other customers will ring some wakeup bells with it's managers and get them thinking. JBG -- 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: [389-devel] No rule to make target dbmon.sh
On 02/26/2015 07:48 PM, William wrote: Could you check if you have ./ldap/admin/src/scripts/dbmon.sh in your build tree? I'm suspecting you might have wiped out by some clean procedure. The file dbmon.sh is removed after make clean because it is added to AUTOMAKE variable CLEANFILES. Details http://www.gnu.org/software/automake/manual/html_node/Clean.html BTW make clean removes also other files from git tree deleted:ldap/admin/src/scripts/dbmon.sh deleted:ldap/ldif/50posix-winsync-plugin.ldif deleted:ldap/ldif/50replication-plugins.ldif deleted:ldap/ldif/90betxn-plugins.ldif I expect that these files should not be removed with make clean. Must have been when I did a make clean earlier. I have now run a git reset --hard HEAD to restore the files, and the build appears to be working. Thanks, William and Lukas! I opened a ticket for it. https://fedorahosted.org/389/ticket/48111 --noriko -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Subject: Self Introduction: Sandro Bonazzola
2015-02-27 13:02 GMT-03:00 Sandro Bonazzola sbona...@redhat.com: Hi, Hello and Welcome Sandro! following [1] I'm writing for introducing myself. My name is Sandro Bonazzola and I'm a Senior Software Engineer at Red Hat. I'm leading RHEV integration team and I'm oVirt[2] project release manager. I'm also representing oVirt project in CentOS Virt SIG[3]. In the past I contributed to several open source projects[4] and I was a former Gentoo Linux developer[5] several years ago. My FAS account is sbonazzo[6]. I'm interested in packaging oVirt and its missing dependencies within Fedora. I am a Fedora packager sponsor, and have particular interest in learning more about virtualization related projects, so, I can help and sponsor you. Do you already have a review request? [1] http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Introduce_yourself [2] http://www.ovirt.org [3] http://wiki.centos.org/SpecialInterestGroup/Virtualization [4] https://www.openhub.net/accounts/sanchan [5] http://archives.gentoo.org/gentoo-dev/message/bb8da84f01bdba83c88ddf5d300eeafc [6] https://fedoraproject.org/wiki/User:Sbonazzo -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com Thanks, Paulo -- 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: SIMVoleon, SoQt rebuilt against Coin3 on f22 and rawhide
On 02/27/2015 06:06 PM, Richard Shaw wrote: On Fri, Feb 27, 2015 at 8:32 AM, Ralf Corsepius rc040...@freenet.de mailto:rc040...@freenet.de wrote: - As mentioned before, I want to understand the reasons why FreeCAD seems to insist on Coin3. As of version 0.15 (or in the current master) they started using SoRenderManager which they're using for a Quarter based viewer. OK, this explains it - they've forked Quarter ;) In this case, they likely also will have dropped SoQt and Pivy. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1195862] Review Request: perl-Class-Virtual - Base class for virtual base classes in Perl
https://bugzilla.redhat.com/show_bug.cgi?id=1195862 Denis Fateyev de...@fateyev.com changed: What|Removed |Added Flags||fedora-cvs? --- Comment #4 from Denis Fateyev de...@fateyev.com --- New Package SCM Request === Package Name: perl-Class-Virtual Short Description: Base class for virtual base classes in Perl Owners: dfateyev Branches: f20 f21 f22 el6 epel7 InitialCC: -- 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=E4Ig5dHvIGa=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 1195573] Review Request: dropbox-api-command - Dropbox API wrapper command
https://bugzilla.redhat.com/show_bug.cgi?id=1195573
--- Comment #7 from Ben Boeckel maths...@gmail.com ---
(In reply to Petr Šabata from comment #6)
1. I would use the release URL instead of just pointing to the commit (which
could be something entirely different and nobody will notice). For example
https://github.com/s-aska/%{name}/archive/%{version}.tar.gz should work just
fine. The tarball filename will be just the version plus extension but that
doesn't really matter.
https://fedoraproject.org/wiki/Packaging:SourceURL#Github
2. Missing buildtime dependencies: perl, perl(CPAN::Meta),
perl(CPAN::Meta::Prereqs), perl(File::Basename), perl(File::Spec),
perl(strict), perl(utf8), perl(warnings)
Hmm. Is there a way to detect these automatically? I think
perl(WebService::Dropbox) also necessary. Or is that just a runtime dep? I'm
not all that well-versed in Perl stuff.
3. Use perl macros for the perl lib paths in %files; changing
%{_datadir}/perl5/App/dropboxapi.pm to %{perl_vendorlib}/* would be fine.
Ah, I used rpmdev-newspec -t perl for this. Will do.
4. A more useful %description would be nice. This isn't necessary.
I'll put something together.
5. You shouldn't need to define prefix, I suppose?
rpmdev-newspec's doing; I'll remove it if that's more modern.
6. Perhaps the project Github page would work better for the URL.
Probably. Will do.
--
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=Pfv1gkInjQa=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: [Proposal] Ring-based Packaging Policies
On Tue, 17 Feb 2015 18:13:23 +0100, Ralf Corsepius wrote: On 02/17/2015 05:59 PM, Matthew Miller wrote: On Tue, Feb 17, 2015 at 05:39:48PM +0100, Ralf Corsepius wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. If the distinction were drawn based on _who_ rather than _what and why_, it would. (And that was fundamentally the problem with the old Core vs. Extras.) But no one is proposing a _society_-based distinction — instead, a _technical_ one. I know and understand this, but I expect the outcome to be the same: Ring 0 == Red Hat Ring 1 == The Red Hat business/RHEL-irrelevant parts In other words, on the techicall level I do not see any difference to CentOS+RHEL and to Core+Extras On the political and social level, it raises questions going far beyond these consideration I wonder why it has become silent in this thread already? Is there another place where those ideas get discussed? | https://twitter.com/Worldcleaver/status/565957125600321538 | | Stephen Gallagher @Worldcleaver | | Wherein I kick the hornets' nest again: | https://lists.fedoraproject.org/pipermail/devel/2015-February/207657.html | … (Proposal to relax Fedora packaging requirements in some cases) -- 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: [Proposal] Ring-based Packaging Policies
On Fri, Feb 27, 2015 at 12:32 PM, Michael Schwendt mschwe...@gmail.com wrote: On Tue, 17 Feb 2015 18:13:23 +0100, Ralf Corsepius wrote: On 02/17/2015 05:59 PM, Matthew Miller wrote: On Tue, Feb 17, 2015 at 05:39:48PM +0100, Ralf Corsepius wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. If the distinction were drawn based on _who_ rather than _what and why_, it would. (And that was fundamentally the problem with the old Core vs. Extras.) But no one is proposing a _society_-based distinction -- instead, a _technical_ one. I know and understand this, but I expect the outcome to be the same: Ring 0 == Red Hat Ring 1 == The Red Hat business/RHEL-irrelevant parts In other words, on the techicall level I do not see any difference to CentOS+RHEL and to Core+Extras On the political and social level, it raises questions going far beyond these consideration I wonder why it has become silent in this thread already? Because commentary on the proposal was made, and nothing new has been resubmitted? Is there another place where those ideas get discussed? Not that I'm aware of. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1195573] Review Request: dropbox-api-command - Dropbox API wrapper command
https://bugzilla.redhat.com/show_bug.cgi?id=1195573
--- Comment #8 from Petr Šabata psab...@redhat.com ---
(In reply to Ben Boeckel from comment #7)
(In reply to Petr Šabata from comment #6)
1. I would use the release URL instead of just pointing to the commit (which
could be something entirely different and nobody will notice). For example
https://github.com/s-aska/%{name}/archive/%{version}.tar.gz should work just
fine. The tarball filename will be just the version plus extension but that
doesn't really matter.
https://fedoraproject.org/wiki/Packaging:SourceURL#Github
Indeed. Let me quote your link:
If the upstream does not create tarballs for releases, you can use this
mechanism to produce them. If the upstream does create tarballs you should use
them as tarballs provide an easier trail for people auditing the packages.
Your upstream provides tarballs.
https://github.com/s-aska/dropbox-api-command/releases
2. Missing buildtime dependencies: perl, perl(CPAN::Meta),
perl(CPAN::Meta::Prereqs), perl(File::Basename), perl(File::Spec),
perl(strict), perl(utf8), perl(warnings)
Hmm. Is there a way to detect these automatically? I think
perl(WebService::Dropbox) also necessary. Or is that just a runtime dep? I'm
not all that well-versed in Perl stuff.
Yes, perl(WebService::Dropbox) is just a runtime dependency and is generated
automatically by rpmbuild (via perl-generators). It's required by
script/dropbox-api which isn't used neither during %build nor %check phases.
You can use the `tangerine' command (from perl-Tangerine) to check perl files
for what modules they provide or require. For example in your case, to see
buildtime deps you could run `tangerine Build.PL lib t'.
--
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=dzg7RAXxuea=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: SIMVoleon, SoQt rebuilt against Coin3 on f22 and rawhide
On Fri, Feb 27, 2015 at 8:32 AM, Ralf Corsepius rc040...@freenet.de wrote: - As mentioned before, I want to understand the reasons why FreeCAD seems to insist on Coin3. As of version 0.15 (or in the current master) they started using SoRenderManager which they're using for a Quarter based viewer. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
qt3 rebuild in f23?
pdfedit depends on qt3 and fails to link in f23: .obj/mergeform.o: In function `gui::MergeDialog::initFileList(QString)': mergeform.cc:(.text+0xf94): undefined reference to `QString::QString(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' .obj/propertyeditor.o: In function `gui::PropertyEditor::setObject(boost::shared_ptrpdfobjects::IProperty)': propertyeditor.cc:(.text+0x3418): undefined reference to `QString::QString(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' propertyeditor.cc:(.text+0x38f0): undefined reference to `QString::QString(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: error: ld returned 1 exit status Makefile.qt:542: recipe for target 'pdfedit' failed I rebuilt qt3 and pdfedit got linked fine (had to remove -posix from compiler arguments). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[PkgDB] jplesnik:perl-Text-Sprintf-Named watchbugzilla set to Obsolete
user: jplesnik set for jplesnik acl: watchbugzilla of package: perl-Text-Sprintf-Named from: Approved to: Obsolete on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Text-Sprintf-Named -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
New Format for QA Devel Meetings
After some discussion at devconf and farther discussion at this weeks qadevel meeting, we're going to try changing a few things about the meetings to make them faster and a bit more useful. - Start holding meetings every week, on Mondays one hour before the QA meetings - Discuss status and open floor every week, task assignments and planning every other week - Ask folks to have status #info messages ahead of time instead of writing them on-demand during the meeting The idea behind the last item is to spend less time waiting for folks to type since that's dead time for everyone else. You don't need to write a 1000 word essay on what you've been up to for the last week, just enough to keep everyone aware of what you're working on and the problems you may have hit. For some example status statements: Person 1 #info finished coding for woozles, review is underway and should be done in the next day or two #link https://phab.example.org/D125 #info after the woozle review is done, will start working on de-fraggling the stembasins #link https://phab.example.org/T421 Person 2 #info still working to get libcloudmagic to always use the right image, ran into some problems with having a consistent path on all clients. Will hopefully be ready for review later this week #link https://phab.example.org/T395 These are just examples, feel free to expand on them but try to include relevant links and enough detail for other folks to know what you're talking. We'll try this for a couple weeks to see if it works well for us. If it ends up not working so well, we'll try something else - probably some form of a shared document that's updated before the meeting. If you have any concerns or suggestions, this thread would be a great place to bring them up. Tim pgp_7HYVmRFDr.pgp Description: OpenPGP digital signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: SIMVoleon, SoQt rebuilt against Coin3 on f22 and rawhide
On Fri, Feb 27, 2015 at 8:32 AM, Ralf Corsepius rc040...@freenet.de wrote: However, FreeCAD-0.15 may impose problems on Fedora = 21. Therefore, I'd first raise a couple of problem: - Do you plan to upgrade FreeCAD to 0.15 on Fedora = 21? I would like to, especially for F21 as it still has a lot of life left. - Do you or somebody else have a FreeCAD-0.15 rpm, which I could use to investigate for details? I'm working on that now. I've seen references to people testing 0.15 but I'm not sure where they got the code. In browsing through the git repository I don't see any branches or tags referencing 0.15 of any kind. - As mentioned before, I want to understand the reasons why FreeCAD seems to insist on Coin3. Since I'm probably going to have to ask where I get a pre-release of 0.15, I'll ask that as well. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaning rubygem-spruz
Hi, I am orphaning rubygem-spruz. It was more or less deprecated by rubygem-tins (but the rename was never officially announced) and it is not maintained anymore. The package is not used by anything ATM. Feel free to pick it up if you have some use for it (but there is one minor issue with file conflicts) or let it fade away. 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: SIMVoleon, SoQt rebuilt against Coin3 on f22 and rawhide
I'm not sure if it will be a problem or not but FreeCAD 0.15 will require Coin3 and as far as I know will still require python-pivy which is currently built against Coin2. Thoughts? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[PkgDB] ppisar:perl-Text-Sprintf-Named watchbugzilla set to Obsolete
user: ppisar set for ppisar acl: watchbugzilla of package: perl-Text-Sprintf-Named from: Approved to: Obsolete on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Text-Sprintf-Named -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Compress-Raw-Lzma] Created tag perl-Compress-Raw-Lzma-2.068-3.fc23
The lightweight tag 'perl-Compress-Raw-Lzma-2.068-3.fc23' was created pointing to: eab644c... Rebuild for xz-5.2.1 in Rawhide -- 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
[PkgDB] ppisar:perl-Text-Sprintf-Named watchcommits set to Obsolete
user: ppisar set for ppisar acl: watchcommits of package: perl-Text-Sprintf-Named from: Approved to: Obsolete on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Text-Sprintf-Named -- 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
[PkgDB] jplesnik:perl-Text-Sprintf-Named watchcommits set to Obsolete
user: jplesnik set for jplesnik acl: watchcommits of package: perl-Text-Sprintf-Named from: Approved to: Obsolete on branch: master To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Text-Sprintf-Named -- 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
[dev machines] script for cleaning up temporary taskotron files
Hello, if you use libtaskotron in a developer environment (running some taskotron tasks locally from time to time), there is a new script that will make sure taskotron temporary files will get cleaned up regularly. Look into conf/tmpfiles.d/ in libtaskotron checkout. This will probably get handy with the recent addition for task artifacts - you probably don't want to keep them around permanently on a developer machine. Cheers, Kamil ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Coconut failures: use dl.fp.o not download.fp.o?
Please note, though, that we think that the mirror issue is a legitimate bug, either caused by dnf stack, or anaconda. Jan reported it yesterday here: https://bugzilla.redhat.com/show_bug.cgi?id=1196164 If this turns out to be true, it would also mean that OpenQA helped us uncover quite an interesting bug, which would be much harder to spot without the massive number of installations executed regularly. So there is also some value in using closest mirror as installation source. Yep, that's an interesting one for sure, and sorry, I should've been clearer: I was talking only about the tests where the actual test involves specifying a particular repository URL (via the GUI or a kickstart or on the cmdline or whatever), and we're currently using 'download.fedoraproject.org' in those URLs. OK, in that case, it completely makes sense. Moreover, I believe that using inst.repo=download.fp.o is explicitly forbidden and unsupported by anaconda (I would have to dig into past bug reports to find it). The problem is that anaconda does not resolve that once and then provide it to yum/dnf, but it uses it verbatim. Therefore that URL resolves itself on every request, potentially leading to different mirrors being used for metadata and packages, which can utterly break everything. At least that's what I remember from the past, maybe now with dnf it might work a bit differently. In any case, we should avoid using inst.repo=download.fp.o by any means. It's potentially very error-prone. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
[389-devel] Please review (resend): [389 Project] #48048: Fix coverity issues - 2015/2/24
Could you please review the patches? (Most of them are tedious just to make coverity happlier who has no chance to see the assertion failure in the debug build.) Thanks, --noriko On 02/25/2015 12:53 PM, Noriko Hosoi wrote: https://fedorahosted.org/389/attachment/ticket/48048 https://fedorahosted.org/389/attachment/ticket/48048/0002-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0003-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0004-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0005-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0006-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0007-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0008-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0009-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0010-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0011-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0012-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0013-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0014-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0015-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0016-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0017-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0018-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0019-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0020-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0021-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0022-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0023-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0024-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0025-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0026-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0027-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0028-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0029-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0030-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0031-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0032-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0033-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0034-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0035-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0036-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0037-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0038-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0039-Ticket-48048-Fix-coverity-issues-2015-2-24.patch https://fedorahosted.org/389/attachment/ticket/48048/0040-Ticket-48048-Fix-coverity-issues-2015-2-24.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [Proposal] Ring-based Packaging Policies
On Fri, 2015-02-27 at 18:32 +0100, Michael Schwendt wrote: On Tue, 17 Feb 2015 18:13:23 +0100, Ralf Corsepius wrote: On 02/17/2015 05:59 PM, Matthew Miller wrote: On Tue, Feb 17, 2015 at 05:39:48PM +0100, Ralf Corsepius wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. If the distinction were drawn based on _who_ rather than _what and why_, it would. (And that was fundamentally the problem with the old Core vs. Extras.) But no one is proposing a _society_- based distinction — instead, a _technical_ one. I know and understand this, but I expect the outcome to be the same: Ring 0 == Red Hat Ring 1 == The Red Hat business/RHEL-irrelevant parts In other words, on the techicall level I do not see any difference to CentOS+RHEL and to Core+Extras On the political and social level, it raises questions going far beyond these consideration I wonder why it has become silent in this thread already? Is there another place where those ideas get discussed? Speaking only for myself, I'm still digesting the responses. There are some very valid points made and I'm trying to figure out the best way to incorporate some of the ideas. Some valid holes were poked into it (not least because the proposal really is about two different things - ring policy and bundling as a special case - and should probably be divided up and considered independently. Also, I got pulled into some high-priority stuff at $DAYJOB, so my focus has wavered a bit :) This is the best (and really, only) place that this topic should be discussed. I'm vehemently opposed to closed-door meetings for anything involving Fedora policies. Which is why I kicked the hornets' nest publicly. 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: SIMVoleon, SoQt rebuilt against Coin3 on f22 and rawhide
Fri, Feb 27, 2015 at 11:46 AM, Ralf Corsepius rc040...@freenet.de wrote: On 02/27/2015 06:06 PM, Richard Shaw wrote: On Fri, Feb 27, 2015 at 8:32 AM, Ralf Corsepius rc040...@freenet.de mailto:rc040...@freenet.de wrote: - As mentioned before, I want to understand the reasons why FreeCAD seems to insist on Coin3. As of version 0.15 (or in the current master) they started using SoRenderManager which they're using for a Quarter based viewer. OK, this explains it - they've forked Quarter ;) In this case, they likely also will have dropped SoQt and Pivy. Pivy is not a hard requirement but it's used in the drafting module so if it's not present, that module is disabled. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[EPEL-devel] Python 3 discussion
This is a followup to the EPEL IRC meeting discussion about python 3. I had a couple questions which led me to take Slavek's excellent work and try some changes here: https://fedoraproject.org/wiki/User:Orion/EPEL7_Python3 Main ideas: - (bikeshedding) - I didn't like the wording other, so I went with next. - I didn't like having to toggle a macro in the spec files, I'm lazy - What happens on the user's end? So: Lifecycle of python3X stacks, rebuilding: when a new python3X+1 is built in EPEL - let's say that there is python34 and python35 has just been introduced: A new python3-pkgversion-macros is build defining the %python3_next* macros. (scripted) mass rebuild is run to build as much of the new stack possible automatically. At some point /usr/bin/python3 is switched from python34 to python35. at a certain point at time an announcement is made that python34 is to be retired and python35 is to be *the* one. At this point: python3-pkgversion-macros is rebuilt removing the %python3_next* macros. python35 is rebuilt defining the normal %python3_* macros all python34 packages are retired At this point all packages build just python35-X subpackages What I still don't understand is what this looks like on the user end, how do they go from 34 to 35? For app users (#!/usr/bin/python3), it seems like this should be as automatic as possible. So shouldn't they still use /usr/bin/python3 rather than /usr/bin/python3X so they get updated automatically? What about all of the old python34 packages left on their systems after retirement? Is there some way they can get cleaned up automatically? -- 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 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[Bug 1195862] Review Request: perl-Class-Virtual - Base class for virtual base classes in Perl
https://bugzilla.redhat.com/show_bug.cgi?id=1195862 Jon Ciesla limburg...@gmail.com changed: What|Removed |Added Flags|fedora-cvs? |fedora-cvs+ -- 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=7Kbj97rVNAa=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 1195862] Review Request: perl-Class-Virtual - Base class for virtual base classes in Perl
https://bugzilla.redhat.com/show_bug.cgi?id=1195862 --- Comment #5 from Jon Ciesla limburg...@gmail.com --- Git done (by process-git-requests). -- 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=hBhnXyhRdxa=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 1195573] Review Request: dropbox-api-command - Dropbox API wrapper command
https://bugzilla.redhat.com/show_bug.cgi?id=1195573
--- Comment #6 from Petr Šabata psab...@redhat.com ---
1. I would use the release URL instead of just pointing to the commit (which
could be something entirely different and nobody will notice). For example
https://github.com/s-aska/%{name}/archive/%{version}.tar.gz should work just
fine. The tarball filename will be just the version plus extension but that
doesn't really matter.
2. Missing buildtime dependencies: perl, perl(CPAN::Meta),
perl(CPAN::Meta::Prereqs), perl(File::Basename), perl(File::Spec),
perl(strict), perl(utf8), perl(warnings)
3. Use perl macros for the perl lib paths in %files; changing
%{_datadir}/perl5/App/dropboxapi.pm to %{perl_vendorlib}/* would be fine.
4. A more useful %description would be nice. This isn't necessary.
5. You shouldn't need to define prefix, I suppose?
6. Perhaps the project Github page would work better for the URL.
--
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=RMbyYtMaKDa=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: Fedora 22 Alpha Freeze
On Tue, Feb 24, 2015 at 11:24 AM, Dennis Gilmore den...@ausil.us wrote: Today is also the Alpha freeze[4]. This means that only packages which fix accepted blocker or freeze exception bugs[5][6] will be marked as 'stable' and included in the Alpha composes. Other builds will remain in updates-testing until the Alpha release is approved, at which point the Alpha freeze is lifted and packages can move to 'stable' as usual until the Beta freeze. I have a question on how I'm supposed to handle a new package. I was working on packaging iwyu [1] and it built for all of the target releases except for F22 because of some gcc 5.0 issues. It appears that the last one has been resolved [2], so how do I handle this situation? Do I just wait until the alpha freeze is over to build iwyu for F22? Or should I use a buildroot override? Thanks, Dave [1] https://bugzilla.redhat.com/show_bug.cgi?id=1091659 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1190329#c2 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Base Design WG agenda meeting 27 February 2015 15:00 UTC on #fedora-meeting
On 26.02.2015 13:02, Harald Hoyer wrote: Agenda: - Interview candidates for new memberships - Optionally accept new members - Vote for new chairman of the Base Design WG to replace Phil Knirsch - Open Floor Please add items by replying to this mail. Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2015-02-27/fedora_base_design_working_group.2015-02-27-15.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2015-02-27/fedora_base_design_working_group.2015-02-27-15.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2015-02-27/fedora_base_design_working_group.2015-02-27-15.00.log.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Subject: Self Introduction: Sandro Bonazzola
Hi, following [1] I'm writing for introducing myself. My name is Sandro Bonazzola and I'm a Senior Software Engineer at Red Hat. I'm leading RHEV integration team and I'm oVirt[2] project release manager. I'm also representing oVirt project in CentOS Virt SIG[3]. In the past I contributed to several open source projects[4] and I was a former Gentoo Linux developer[5] several years ago. My FAS account is sbonazzo[6]. I'm interested in packaging oVirt and its missing dependencies within Fedora. [1] http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Introduce_yourself [2] http://www.ovirt.org [3] http://wiki.centos.org/SpecialInterestGroup/Virtualization [4] https://www.openhub.net/accounts/sanchan [5] http://archives.gentoo.org/gentoo-dev/message/bb8da84f01bdba83c88ddf5d300eeafc [6] https://fedoraproject.org/wiki/User:Sbonazzo -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
2015-03-02 @ 15:00 UTC - Fedora QA Devel Meeting
We'll be holding a QA devel meeting on Monday and since the last meeting was status-only, we'll be getting into more planning and task discussion than last week. I've included a proposed agenda at the end of this email. If you have any topics to add, reply to this thread or let me know. Tim Proposed agenda === Status Updates -- - Please have #info statements ready so we can get through this as quickly as possible Tasking/Planning - Disposable Clients Startup - Remaining ExecDB, Artifacts work (if any) - F21 Migration Open Floor -- - TBD pgpqkgFf_eWjW.pgp Description: OpenPGP digital signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, Feb 27, 2015 at 08:18:12AM -0500, Nico Kadel-Garcia wrote: On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nka...@gmail.com) wrote: [ notes snipped, ] You know, that systemd creates a symlink if the file is missing is not going to change behaviour of anything, since it will only do something if the file is *missing*. Congratulations. We now have inconsistent behavior if anyone, *ever*, edits /etc/resolf.conf with 'sed -i', uses rsync -a or cp -a tp reproduce it from a known good repository, and with a symlink in place we're storing absolutely critical system information in a non /etc location, meaning that non-modified backup systems won't get a copy with valid content. Just. great. Look, deciding to ignore the File System Hierarchy for installing config files and creating new locations to store system configuration Actually it might be considered that we are *starting* to follow FHS. In many (most?) setups /etc/resolv.conf configuration is very dynamic: the set of resolvers depends on dhcp leases, VPNs, network interfaces coming and going. Storing this information in /etc/ is wrong. It's good that this ephmeral content is not backed up. If the machine reboots, you do not want to restore it, you want to recreate it from scratch. If someone has a static setup and a static resolv.conf is fine for them, there's no problem: just create a normal file. OK, this change is not transparent to tools that write resolver information. The new scheme requires some changes, but it's not more complicated than the old scheme. It is actually easier for the admin, because it gives full control over the symlink to them, and easier for the tools, because they don't have to fight over the contents of the file. Hey, if you want to know what's going on in systemd development, then pelase join our upstream mailing list. I know that this is not realistic. But it's not really necessary. This issue discussed before F21, and an number of Anaconda people participated in the discussion. The bug was open for the last 6 months. For example, now if I manipulate /etc/resolv.conf for whatever reason, and I edit it with vi or a management tool like chef that is unaware of symlinks, I'll break the link. Will systemd correctly re-establish the link? Will it wipe out my change, Did anyone even *think* about this? Nope. All that systemd does is create it as symlinks if it is otherwise missing. If you put something else there, then that's what counts. The file that is written by systemd-resolved contains the following header: # This file is managed by systemd-resolved(8). Do not edit. # # Third party programs must not access this file directly, but # only through the symlink at /etc/resolv.conf. To manage # resolv.conf(5) in a different way, replace the symlink by a # static file or a different symlink. I'll try to tweak this text a bit to be clearer on the symlink issue. I don't have a NetworkManager generated file at hand to see, but it should probably carry something similar. Personally? I'd say either always use a symlink, or never use one. Please do not try to deduce the sys-admin's intent from which editing tool they happen to use and its secondary behavior. The handling of symlinks can seriously, seriously bite you at odd moments. We need the file to be a symlink for some usecases. We *could* deprecate /etc/resolv.conf as a normal file, and always create it as a symlink. Anaconda would then write (say) /etc/resolv.conf.static, and symlink /etc/resolv.conf → resolv.conf.static. This is really beyond systemd, since systemd does not create the static file ever. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 Alpha Freeze
On Fri, Feb 27, 2015 at 3:23 PM, Dave Johansen davejohan...@gmail.com wrote: On Tue, Feb 24, 2015 at 11:24 AM, Dennis Gilmore den...@ausil.us wrote: Today is also the Alpha freeze[4]. This means that only packages which fix accepted blocker or freeze exception bugs[5][6] will be marked as 'stable' and included in the Alpha composes. Other builds will remain in updates-testing until the Alpha release is approved, at which point the Alpha freeze is lifted and packages can move to 'stable' as usual until the Beta freeze. I have a question on how I'm supposed to handle a new package. I was working on packaging iwyu [1] and it built for all of the target releases except for F22 because of some gcc 5.0 issues. It appears that the last one has been resolved [2], so how do I handle this situation? Do I just wait until the alpha freeze is over to build iwyu for F22? Or should I use a buildroot override? Build it as per normal, if it's a single package submit it to bodhi as an update for F-22, if you need to build other packages against it you'll need to do a build override as per normal stable releases. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1195573] Review Request: dropbox-api-command - Dropbox API wrapper command
https://bugzilla.redhat.com/show_bug.cgi?id=1195573 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com Assignee|nob...@fedoraproject.org|psab...@redhat.com Flags||fedora-review? --- Comment #5 from Petr Šabata psab...@redhat.com --- I'll do the rest of the review :) -- 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=qLX2Ymvprya=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: GCC5 rebuilds required for sflphone: ccrtp, libzrtpcpp, dbus-c++
On Thu, Feb 26, 2015 at 02:52:42PM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Feb 26, 2015 at 01:36:31PM +0100, Sandro Mani wrote: Hi, I need ccrtp, libzrtpcpp Building those two now. and dbus-c++ to be rebuilt against GCC5 to https://bugzilla.redhat.com/show_bug.cgi?id=1187045 get sflphone building [1]. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Apps using default Python in Fedora vs. EPEL
On 26.2.2015 00:13, Nick Coghlan wrote: For those not following along with the FPC ticket, Toshio and Tomspur have a nice write-up of the options at https://etherpad.mozilla.org/2Uqk0ikCll This thing is in Russian (while I guess it is actually about Python and I see some Fedora links in there) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: i686 kernel bug priority plan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 25 Feb 2015 10:35:22 -0500 Stephen Gallagher sgall...@redhat.com wrote: On Wed, 2015-02-25 at 14:01 +, Peter Robinson wrote: This is an opportunity for community members for whom i686 is a passion to join the team to participate in the bugfixing required. We previously called out the need for assistance[2], but had no substantial response. We hope that being transparent about our priorities will prompt interested community members to help. If you are interested to help, here are some resources to get started: snip Given our past history with passive requests for help, I think it might be beneficial to put a time limit on things. For example, if no i686 Kernel SIG steps up and agrees to handle bugs on that platform, we should strongly consider demoting i686 to secondary architecture for installation media at the Fedora 23 branch point (about six months from now). Note: I'm only suggesting that we would demote the kernel and install media, *NOT* the 32-bit runtime libraries on an x86_64 system; we would still need to be building those. How do you propose demoting to secondary only the kernel/install without the userspace? Do you mean de-emphasise the i686 bit platform? Well, that was more a political and rel-eng statement than a technical one. Effectively, we'd not build the kernel package or do release- blocking composes of i686 media. However, the Koji build-system would still have to be capable of producing i686 builds as a primary architecture. So yes, from a purely technical standpoint, it's a muddy statement. from a purely technical point of view it would be a complete and utter mess. given how secondary arches work, we would be largely screwed supporting such a model. at least without sitting down and majorly redoing things. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJU8MkfAAoJEH7ltONmPFDRrl0P/istndwIaewWAqOS8kRsXggc G6BXc+v6/fLwuZDzAcCD9f4ZcmvmVslSREaNI5W+GjEIIY4mUgsxfXR9BQuGm3OH +NZi5JLBtRdby36sstEIjM1OaKdi3vhB/7WwxZH8D/e1BEtmd3RI5ERORjAbUvqB Ogm8nKmEOUMezqxWGu+sBYHMdoYIK0rf/PACJ4NzzNeJLrU1qtOwVif78E+dPZ0F FWUlB8YckTUVrYDHk2ww/iNhhgwKaLpR4bLZf8QnqKiqhozpSw2D/MxLGHTUHEqW 0/lpFHi87rXC2vjHcsgNzzRwIoSJnhExi3BWzijy4r66jh/lRIl5Gxc/uEn45ANB iseDJJHrhulqigxeq/4zpc3iPpBssOrZmfWtc+tBjKHaZBjWPZ8YF38xN2Aa1uHl a/d7rh/XhBtYgs2BmvxkTd/sALfRONK8RVG9aCL8rY8Upck1ENfPx9DvCf1duLeO zwcnpC8ZeGv4JKMC5Mn6PdFqthPZUxaYlkZ+lYlE8+I3EnXOF0o31+bPdpQgvn/i EUuY1BBpldhmLe8GWZpqfABS6WoX9ErPTGqpB4iAZ4L2hgSn4PWnxCbdjc0Oak4w 4dOqTQ/rAHABcjpL07pJ2F+EMKFbDTxh5yCjTCsuIWRT9G6wSYg58dFC9Veu+gN1 KoZifUI74JXo+NjGDmWv =uxsR -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1196763] Review Request: perl-Tie-Cache - LRU Cache in Memory
https://bugzilla.redhat.com/show_bug.cgi?id=1196763 --- Comment #9 from Fedora Update System upda...@fedoraproject.org --- perl-Tie-Cache-0.21-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/perl-Tie-Cache-0.21-1.el5 -- 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=5p02GQG8uWa=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 1196763] Review Request: perl-Tie-Cache - LRU Cache in Memory
https://bugzilla.redhat.com/show_bug.cgi?id=1196763 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- perl-Tie-Cache-0.21-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Tie-Cache-0.21-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=G7HBIp6r4sa=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: Apps using default Python in Fedora vs. EPEL
On 27.2.2015 21:06, Miro Hrončok wrote: On 26.2.2015 00:13, Nick Coghlan wrote: For those not following along with the FPC ticket, Toshio and Tomspur have a nice write-up of the options at https://etherpad.mozilla.org/2Uqk0ikCll This thing is in Russian (while I guess it is actually about Python and I see some Fedora links in there) Oh it seems only in the latest revision someone took the courtesy of translating it all to Russian. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Hardened builds
On Tue, Feb 24, 2015 at 05:44:18PM -0700, Jerry James wrote: Also, http://fedoraproject.org/wiki/Hardened_Packages seems to be entirely useless at this point. Perhaps it could be replaced with a page that discusses the current state of the hardening flags. I am going to get this updated once the mass rebuild is done and I got the details worked out about what to do best, for example for allowing exceptions from this. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1196763] Review Request: perl-Tie-Cache - LRU Cache in Memory
https://bugzilla.redhat.com/show_bug.cgi?id=1196763 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-Tie-Cache-0.21-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-Tie-Cache-0.21-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=kzH3P3rpJUa=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 1196763] Review Request: perl-Tie-Cache - LRU Cache in Memory
https://bugzilla.redhat.com/show_bug.cgi?id=1196763 --- Comment #7 from Fedora Update System upda...@fedoraproject.org --- perl-Tie-Cache-0.21-1.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/perl-Tie-Cache-0.21-1.el7 -- 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=DObAW5rGeQa=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 1196763] Review Request: perl-Tie-Cache - LRU Cache in Memory
https://bugzilla.redhat.com/show_bug.cgi?id=1196763 --- Comment #8 from Fedora Update System upda...@fedoraproject.org --- perl-Tie-Cache-0.21-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-Tie-Cache-0.21-1.el6 -- 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=ipQnpyl1ARa=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 1196763] Review Request: perl-Tie-Cache - LRU Cache in Memory
https://bugzilla.redhat.com/show_bug.cgi?id=1196763 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Tie-Cache-0.21-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/perl-Tie-Cache-0.21-1.fc22 -- 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=K30Fsfbl0pa=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: [EPEL-devel] Question about EPEL 7 python-ipython*
It is purely because noone has stepped up to do the maintenance. It is not explicitly excluded. That would only really happen if RHEL itself ships the package or if there are licensing problems See https://bugzilla.redhat.com/show_bug.cgi?id=1136051 which has had some progress recently. Thanks, will follow up on that ticket! This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[Test-Announce] Fedora 22 Alpha Test Compose 7 (TC7) Available Now!
As per the Fedora 22 schedule [1], Fedora 22 Alpha Test Compose 7 (TC7) is now available for testing. Note a significant known bug in TC7: Workstation live image boot will often hang at the point where X should start up. This can be worked around by just booting a few times (sometimes it works...) or by editing 'rhgb quiet' out of the boot parameters. The bug report for this is https://bugzilla.redhat.com/show_bug.cgi?id=1197224 . Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/6102# comment:10. Please see the following pages for download links and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Workstation and Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Server: https://fedoraproject.org/wiki/Test_Results:Current_Server_Test Cloud: https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test Summary: https://fedoraproject.org/wiki/Test_Results:Current_Summary Ideally, all Alpha priority test cases for each of these test pages [2] should pass in order to meet the Alpha Release Criteria [3]. For the Fedora 22 cycle we are also trying to run the Beta and Final tests at this time, to try and identify later release blocker bugs as early as possible. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Create Fedora 22 Alpha test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/6102 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-22/f-22-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://admin.fedoraproject.org/mailman/listinfo/test -- 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
SIMVoleon, SoQt rebuilt against Coin3 on f22 and rawhide
Hi, as some already might have noticed, Coin3 is about to land in Fedora. Therefore, I rebuilt SIMVoleon and SoQt (two addon-packages to Coin), against Coin3 on rawhide and f22. I do not expect this to impose problems to Fedora, because I can't spot any packages depending on these in Fedora. On Fedora = 21 these packages will have to stay with Coin2 to avoid breaking backward-compatibility. Though it's thinkable to do so, I do not plan to provide Coin3-compiled versions of these packages for fc20, f21 and Coin2-compiled versions for fc22, f23, at the moment. Please speak up now, should you have such a demand. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1195862] Review Request: perl-Class-Virtual - Base class for virtual base classes in Perl
https://bugzilla.redhat.com/show_bug.cgi?id=1195862 Petr Šabata psab...@redhat.com changed: What|Removed |Added Flags|fedora-review? |fedora-review+ --- Comment #3 from Petr Šabata psab...@redhat.com --- Great. If he said so in an email, could you put that in %doc? Approving. -- 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=XiXLHEnjmCa=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
Broken dependencies: polymake
polymake has broken dependencies in the rawhide tree: On x86_64: polymake-2.13-18.git20141013.fc22.x86_64 requires perl = 4:5.20.1 On i386: polymake-2.13-18.git20141013.fc22.i686 requires perl = 4:5.20.1 On armhfp: polymake-2.13-18.git20141013.fc22.armv7hl requires perl = 4:5.20.1 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1193873] Parse-CPAN-Packages-2.40 bump
https://bugzilla.redhat.com/show_bug.cgi?id=1193873 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-Parse-CPAN-Packages-2.40-1.fc21 has been pushed to the Fedora 21 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=0XEWvBmxBEa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/26/2015 04:26 PM, Aleksandar Kurtakov wrote: - Original Message - From: Robert Marcano rob...@marcanoonline.com To: devel@lists.fedoraproject.org Sent: Thursday, February 26, 2015 5:20:04 PM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/24/2015 05:04 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora Change owner(s): Jiri Vanek jva...@redhat.com Currently Fedora supports one main Java runtime and Java Development Kit (JDK) and from time to time one future JDK as a tech preview. This change should be set of rules, which will enable community to maintain legacy JDKs. Please note, people are bugging main JDK maintainers pretty often with this, and to allow them to maintain legacy JDKs is a step in right direction. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This is no real work proposal. The result of this proposal is set of rules, which will allow community maintainers to pack any legacy jdk and will be ensuring that this JDKs will not conflict by any other JDK and will smoothly integrate to system. The results are summarized here, and pledged for discussion until final resolution is done. I think for this to work, real work should be done by all Java packagers. There is no advantages of being able to install any community maintained legacy JDK if I can't use already packaged code. An example PostgreSQL JDBC driver is currently built with Java 8 bytecode level, it can't be used with any previous Java release. This happen because upstream developers frequently forget to add the --target javac command line argument for the minimum supported Java release they support (and work with upstream to add it). So a lot of packages need to be patched because they will target the built time Java bytecode level. Now, this is the kind of work I would not do for my packages. There are 2 options for this to happen: * Interested person becomes maintainer of the package and takes care of such patching. I'll happily give maintainership to any such person. * Interested person fixes setting target upstream properly (note that this is double edged sword as target 1.5 would not work with Java 9 and requires keeping track). Once Fedora version is updated this would be fixed in Fedora. This should be out of scope. Nothing of javastack should be allowed to use use legacy jdk - see rule 7. Togehter with rule 2 it should prevent this happening. Alexander Kurtakov Red Hat Eclipse team === Proposed rules === 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. This must remain clear''' option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy 1. so from killed java-1.7.0-openjdk will become new package java-1.7.0- openjdk-legacy 2. next main jdk do Obsolete previous one as usually 2. new package '''must''' not do any virtual provides (aka java,java-devel)... (protection against random pull by as dependence) 1. it provides only itself by name 3 its priority '''must''' be kept on less digits (right now it would be 5) then main jdk (protection against winning in alternatives after update) 1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 are '''mandatory''' 4. at least one of the main-jdk's members '''must''' be set as comaintainer (to watch the commits and save the world if necessary) 5. new package '''should''' to follow both original jdk (ideally not change at all (except source updates and necessary)) and current main jdk as close as possibly 1. here it requires some common sense and a lot of testing if integration with system is as expected 6. as it is generally not new package, the review process '''should''' be only formal - to know maintainer and to create cvs repo 1. this is quite important, otherwise the new maintainer can become really frustrated, and we are forcing the dead package overorpahned so the full review (especially in alignment with rule 5) really should not be forced. 2. on the contrary, rules agreed here '''must''' be checked. (even the number 5) 7. all depending packages '''must''' keep requiring java-headless or java (and BuildRequires java-devel). Requirements on any exact jdk - or even worse on any exact legacy jdk are forbidden and needs FESCO exception. This option is forcing maintainers to fight with the name x current setup of alternatives. However, the work should be minimal. But it makes the update path pretty clear and it keeps users well protected against legacy jdk. option two - orphaning legacy jdks and ensure update path 1. main JDK is only orphaned when new
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/26/2015 02:51 PM, Jiri Vanek wrote: On 02/24/2015 10:34 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora Change owner(s): Jiri Vanek jva...@redhat.com Currently Fedora supports one main Java runtime and Java Development Kit (JDK) and from time to time one future JDK as a tech preview. This change should be set of rules, which will enable community to maintain legacy JDKs. Please note, people are bugging main JDK maintainers pretty often with this, and to allow them to maintain legacy JDKs is a step in right direction. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This is no real work proposal. The result of this proposal is set of rules, which will allow community maintainers to pack any legacy jdk and will be ensuring that this JDKs will not conflict by any other JDK and will smoothly integrate to system. The results are summarized here, and pledged for discussion until final resolution is done. === Proposed rules === 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. This must remain clear''' option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy 1. so from killed java-1.7.0-openjdk will become new package java-1.7.0- openjdk-legacy 2. next main jdk do Obsolete previous one as usually 2. new package '''must''' not do any virtual provides (aka java,java-devel)... (protection against random pull by as dependence) 1. it provides only itself by name 3 its priority '''must''' be kept on less digits (right now it would be 5) then main jdk (protection against winning in alternatives after update) 1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 are '''mandatory''' 4. at least one of the main-jdk's members '''must''' be set as comaintainer (to watch the commits and save the world if necessary) 5. new package '''should''' to follow both original jdk (ideally not change at all (except source updates and necessary)) and current main jdk as close as possibly 1. here it requires some common sense and a lot of testing if integration with system is as expected 6. as it is generally not new package, the review process '''should''' be only formal - to know maintainer and to create cvs repo 1. this is quite important, otherwise the new maintainer can become really frustrated, and we are forcing the dead package overorpahned so the full review (especially in alignment with rule 5) really should not be forced. 2. on the contrary, rules agreed here '''must''' be checked. (even the number 5) 7. all depending packages '''must''' keep requiring java-headless or java (and BuildRequires java-devel). Requirements on any exact jdk - or even worse on any exact legacy jdk are forbidden and needs FESCO exception. This option is forcing maintainers to fight with the name x current setup of alternatives. However, the work should be minimal. But it makes the update path pretty clear and it keeps users well protected against legacy jdk. option two - orphaning legacy jdks and ensure update path 1. main JDK is only orphaned when new main JDK landed 1. it do '''not''' Obsolate previous jdk 2. other rules (2-7) are same This is making life of legacy JDK maintainers a bit simpler. But I don't know, how to ensure proper obsolete implementation in this case. == Scope == * Proposal owners: are responsible for initial setup of those guidelines. The FESCO, the owners and pssible legacy JDKs maintainers have to agree on those rules. New legacy JDK can be then added anytime in Fedora lifecycle. * Other developers: no developers * Release engineering: in ideal case, no release engineer needed * Policies and guidelines: The proposal may split to proposal and Legacy JDKs in Fedora guidelines pages ___ Small restart. Looking to the discussion, although many people claimed against any rules at the end it seems to me that everybody agree on some rules - even if it would be existence of metapackage or only removed virtual provides and priority From that point of view, do you mind to help me to improve those rules? Looking to more inputs from https://fedorahosted.org/fpc/ticket/503 : Current state is fight between -legacy suffix and metapackage with provides. Except that : rule 2 is moreover agreed by all. rule 3 was not discussed by anybody == is ok? rule 4 was considered only once as to strict, except that seems ok. I don't insists on it. If nor me nor any of my colleagues will be comaintainer - good. less work for us. rule 5 and 7 were discussed only shortly without any clear result. However rule 6
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
- Original Message - From: Jiri Vanek jva...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, February 27, 2015 11:43:53 AM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/26/2015 02:51 PM, Jiri Vanek wrote: On 02/24/2015 10:34 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora Change owner(s): Jiri Vanek jva...@redhat.com Currently Fedora supports one main Java runtime and Java Development Kit (JDK) and from time to time one future JDK as a tech preview. This change should be set of rules, which will enable community to maintain legacy JDKs. Please note, people are bugging main JDK maintainers pretty often with this, and to allow them to maintain legacy JDKs is a step in right direction. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This is no real work proposal. The result of this proposal is set of rules, which will allow community maintainers to pack any legacy jdk and will be ensuring that this JDKs will not conflict by any other JDK and will smoothly integrate to system. The results are summarized here, and pledged for discussion until final resolution is done. === Proposed rules === 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. This must remain clear''' option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy 1. so from killed java-1.7.0-openjdk will become new package java-1.7.0- openjdk-legacy 2. next main jdk do Obsolete previous one as usually 2. new package '''must''' not do any virtual provides (aka java,java-devel)... (protection against random pull by as dependence) 1. it provides only itself by name 3 its priority '''must''' be kept on less digits (right now it would be 5) then main jdk (protection against winning in alternatives after update) 1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 are '''mandatory''' 4. at least one of the main-jdk's members '''must''' be set as comaintainer (to watch the commits and save the world if necessary) 5. new package '''should''' to follow both original jdk (ideally not change at all (except source updates and necessary)) and current main jdk as close as possibly 1. here it requires some common sense and a lot of testing if integration with system is as expected 6. as it is generally not new package, the review process '''should''' be only formal - to know maintainer and to create cvs repo 1. this is quite important, otherwise the new maintainer can become really frustrated, and we are forcing the dead package overorpahned so the full review (especially in alignment with rule 5) really should not be forced. 2. on the contrary, rules agreed here '''must''' be checked. (even the number 5) 7. all depending packages '''must''' keep requiring java-headless or java (and BuildRequires java-devel). Requirements on any exact jdk - or even worse on any exact legacy jdk are forbidden and needs FESCO exception. This option is forcing maintainers to fight with the name x current setup of alternatives. However, the work should be minimal. But it makes the update path pretty clear and it keeps users well protected against legacy jdk. option two - orphaning legacy jdks and ensure update path 1. main JDK is only orphaned when new main JDK landed 1. it do '''not''' Obsolate previous jdk 2. other rules (2-7) are same This is making life of legacy JDK maintainers a bit simpler. But I don't know, how to ensure proper obsolete implementation in this case. == Scope == * Proposal owners: are responsible for initial setup of those guidelines. The FESCO, the owners and pssible legacy JDKs maintainers have to agree on those rules. New legacy JDK can be then added anytime in Fedora lifecycle. * Other developers: no developers * Release engineering: in ideal case, no release engineer needed * Policies and guidelines: The proposal may split to proposal and Legacy JDKs in Fedora guidelines pages ___ Small restart. Looking to the discussion, although many people claimed against any rules at the end it seems to me that everybody agree on some rules - even if it would be existence of metapackage or only removed virtual provides and priority From that point of view, do you mind to help me to improve those rules? Looking to more inputs from
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On Thu, 2015-02-26 at 15:46 +0100, Mikolaj Izdebski wrote: On 02/26/2015 02:46 PM, Jiri Vanek wrote: On 02/26/2015 10:13 AM, Mikolaj Izdebski wrote: On 02/26/2015 09:23 AM, Jiri Vanek wrote: On 02/26/2015 09:20 AM, Mikolaj Izdebski wrote: On 02/26/2015 08:42 AM, Jiri Vanek wrote: Also, my proposal of introducing java metapackage (see my other post in this thread), which would always require the latest JDK, solves this problem in a different way, without modifying ordinary Java packages at all. May you be more exact with the metapackage? Before I come up with legacy, I hoped to solve the issues via some metapackage. At the end I gave up, because the touch of user was always necessary. I described it in much detail in other posts in this thread (for example message-ID 54eca102.1070...@redhat.com) Yah. Sorry. I walked across it later then replied this. However - I'm not convinced that metapackage will work as expected. If Still the metapackge's correct dependence have to be someones responsibility. Will you be able to take this burden? Sure, I can create and maintain metapackage. (In this case it would probably be subpackage of javapackages-tools.) nothing else it will need some changes in current infrastructure which I wonted to avoid. It works exactly how I described it. Old JDK won't be removed during Is it really wonted? If so, we can skip the option one and continue with with option two. If you really think that old JDK should be removed during update and insist on that then there is still a way to achieve that with versioned obsoletes. Metapackage would Obsolete: java-1.N.0-openjdk* e:v-(r+1), where e:v-r is the latest evr of java-1.N.0-openjdk* when JDK N was considered as main JDK. I've just tested it and it works, see below. Lets start with JDK 7 installed. sh-4.3# rpm -qa | grep java java-1.7.0-1.fc23.x86_64 java-1.7.0-openjdk-1.7.0-1.fc23.x86_64 Update installs JDK 8 and erases JDK 7. sh-4.3# dnf -y update Using metadata from Thu Feb 26 15:37:47 2015 Dependencies resolved. Nothing to do. sh-4.3# rm -rf /var/cache/dnf/ sh-4.3# rm -rf rpm sh-4.3# dnf -y update rpm 966 kB/s | 1.3 kB 00:00 Using metadata from Thu Feb 26 15:38:06 2015 Dependencies resolved. Package Arch Version Repository Size Installing: java-1.8.0-openjdk x86_64 666:1.8.0-1.fc23 rpm 5.6 k Upgrading: java x86_64 666:1.8.0-1.fc23 rpm 5.7 k replacing java-1.7.0-openjdk.x86_64 666:1.7.0-1.fc23 Transaction Summary Install 1 Package Upgrade 1 Package Total size: 11 k Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Installing : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6 1/4 Upgrading : java-666:1.8.0-1.fc23.x86_642/4 Cleanup : java-666:1.7.0-1.fc23.x86_643/4 Obsoleting : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6 4/4 Verifying : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6 1/4 Verifying : java-666:1.8.0-1.fc23.x86_642/4 Verifying : java-666:1.7.0-1.fc23.x86_643/4 Verifying : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6 4/4 Installed: java-1.8.0-openjdk.x86_64 666:1.8.0-1.fc23 Upgraded: java.x86_64 666:1.8.0-1.fc23 Complete! After update only JDK 8 is installed: sh-4.3# rpm -qa | grep java java-1.8.0-openjdk-1.8.0-1.fc23.x86_64 java-1.8.0-1.fc23.x86_64 But user can still install JDK 7: sh-4.3# dnf install -y java-1.7.0-openjdk Using metadata from Thu Feb 26 15:38:06 2015 Dependencies resolved. Package Arch Version Repository Size Installing: java-1.7.0-openjdk x86_64 666:1.7.0-2.fc23 rpm 5.7 k Transaction Summary Install 1 Package Total size: 5.7 k Installed size: 0 Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Installing : java-1.7.0-openjdk-666:1.7.0-2.fc23.x86_6 1/1 Verifying : java-1.7.0-openjdk-666:1.7.0-2.fc23.x86_6 1/1 Installed: java-1.7.0-openjdk.x86_64 666:1.7.0-2.fc23 Complete! JDK 7 and 8 can coexist without any problem: sh-4.3# rpm -qa | grep java
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/27/2015 11:48 AM, Severin Gehwolf wrote: On Thu, 2015-02-26 at 15:46 +0100, Mikolaj Izdebski wrote: On 02/26/2015 02:46 PM, Jiri Vanek wrote: On 02/26/2015 10:13 AM, Mikolaj Izdebski wrote: On 02/26/2015 09:23 AM, Jiri Vanek wrote: On 02/26/2015 09:20 AM, Mikolaj Izdebski wrote: On 02/26/2015 08:42 AM, Jiri Vanek wrote: Also, my proposal of introducing java metapackage (see my other post in this thread), which would always require the latest JDK, solves this problem in a different way, without modifying ordinary Java packages at all. May you be more exact with the metapackage? Before I come up with legacy, I hoped to solve the issues via some metapackage. At the end I gave up, because the touch of user was always necessary. I described it in much detail in other posts in this thread (for example message-ID 54eca102.1070...@redhat.com) Yah. Sorry. I walked across it later then replied this. However - I'm not convinced that metapackage will work as expected. If Still the metapackge's correct dependence have to be someones responsibility. Will you be able to take this burden? Sure, I can create and maintain metapackage. (In this case it would probably be subpackage of javapackages-tools.) nothing else it will need some changes in current infrastructure which I wonted to avoid. It works exactly how I described it. Old JDK won't be removed during Is it really wonted? If so, we can skip the option one and continue with with option two. If you really think that old JDK should be removed during update and insist on that then there is still a way to achieve that with versioned obsoletes. Metapackage would Obsolete: java-1.N.0-openjdk* e:v-(r+1), where e:v-r is the latest evr of java-1.N.0-openjdk* when JDK N was considered as main JDK. I've just tested it and it works, see below. Lets start with JDK 7 installed. sh-4.3# rpm -qa | grep java java-1.7.0-1.fc23.x86_64 java-1.7.0-openjdk-1.7.0-1.fc23.x86_64 Update installs JDK 8 and erases JDK 7. sh-4.3# dnf -y update Using metadata from Thu Feb 26 15:37:47 2015 Dependencies resolved. Nothing to do. sh-4.3# rm -rf /var/cache/dnf/ sh-4.3# rm -rf rpm sh-4.3# dnf -y update rpm 966 kB/s | 1.3 kB 00:00 Using metadata from Thu Feb 26 15:38:06 2015 Dependencies resolved. Package Arch Version Repository Size Installing: java-1.8.0-openjdk x86_64 666:1.8.0-1.fc23 rpm 5.6 k Upgrading: java x86_64 666:1.8.0-1.fc23 rpm 5.7 k replacing java-1.7.0-openjdk.x86_64 666:1.7.0-1.fc23 Transaction Summary Install 1 Package Upgrade 1 Package Total size: 11 k Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Installing : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6 1/4 Upgrading : java-666:1.8.0-1.fc23.x86_642/4 Cleanup : java-666:1.7.0-1.fc23.x86_643/4 Obsoleting : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6 4/4 Verifying : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6 1/4 Verifying : java-666:1.8.0-1.fc23.x86_642/4 Verifying : java-666:1.7.0-1.fc23.x86_643/4 Verifying : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6 4/4 Installed: java-1.8.0-openjdk.x86_64 666:1.8.0-1.fc23 Upgraded: java.x86_64 666:1.8.0-1.fc23 Complete! After update only JDK 8 is installed: sh-4.3# rpm -qa | grep java java-1.8.0-openjdk-1.8.0-1.fc23.x86_64 java-1.8.0-1.fc23.x86_64 But user can still install JDK 7: sh-4.3# dnf install -y java-1.7.0-openjdk Using metadata from Thu Feb 26 15:38:06 2015 Dependencies resolved. Package Arch Version Repository Size Installing: java-1.7.0-openjdk x86_64 666:1.7.0-2.fc23 rpm 5.7 k Transaction Summary Install 1 Package Total size: 5.7 k Installed size: 0 Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Installing : java-1.7.0-openjdk-666:1.7.0-2.fc23.x86_6 1/1 Verifying : java-1.7.0-openjdk-666:1.7.0-2.fc23.x86_6 1/1 Installed: java-1.7.0-openjdk.x86_64 666:1.7.0-2.fc23 Complete! JDK 7 and 8 can coexist without any problem: sh-4.3# rpm -qa | grep java java-1.8.0-openjdk-1.8.0-1.fc23.x86_64 java-1.7.0-openjdk-1.7.0-2.fc23.x86_64 java-1.8.0-1.fc23.x86_64
Re: [Scitech] OpenBabel rebase to pre-2.4 (current Git master)
Do we need to tell upstream about these patches? -- 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: koji is broken
On 02/27/2015 11:15 AM, Michael J Gruber wrote: Ralf Corsepius venit, vidit, dixit 26.02.2015 19:09: Yes Ralf, fedora-cert is the better way to deal with the certs (rather than re-running setup). We used to be able to download a new cert from FAS. That page seems to be MIA now without any reference to the cli tools. Doesn't help either. Have you tried getting a new cert (even though yours is supposed to be valid)? No. Things appear to be fully operational again now. It likely was my fault to have rebooted the machine I was using or to try on a different machine to furtherly investigate - but I didn't :( I have absolutely no clue about what might have been going on. Saying more about it would be speculation. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/27/2015 11:47 AM, Aleksandar Kurtakov wrote: - Original Message - From: Jiri Vanek jva...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, February 27, 2015 11:43:53 AM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/26/2015 02:51 PM, Jiri Vanek wrote: On 02/24/2015 10:34 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora Change owner(s): Jiri Vanek jva...@redhat.com Currently Fedora supports one main Java runtime and Java Development Kit (JDK) and from time to time one future JDK as a tech preview. This change should be set of rules, which will enable community to maintain legacy JDKs. Please note, people are bugging main JDK maintainers pretty often with this, and to allow them to maintain legacy JDKs is a step in right direction. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This is no real work proposal. The result of this proposal is set of rules, which will allow community maintainers to pack any legacy jdk and will be ensuring that this JDKs will not conflict by any other JDK and will smoothly integrate to system. The results are summarized here, and pledged for discussion until final resolution is done. === Proposed rules === 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. This must remain clear''' option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy 1. so from killed java-1.7.0-openjdk will become new package java-1.7.0- openjdk-legacy 2. next main jdk do Obsolete previous one as usually 2. new package '''must''' not do any virtual provides (aka java,java-devel)... (protection against random pull by as dependence) 1. it provides only itself by name 3 its priority '''must''' be kept on less digits (right now it would be 5) then main jdk (protection against winning in alternatives after update) 1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 are '''mandatory''' 4. at least one of the main-jdk's members '''must''' be set as comaintainer (to watch the commits and save the world if necessary) 5. new package '''should''' to follow both original jdk (ideally not change at all (except source updates and necessary)) and current main jdk as close as possibly 1. here it requires some common sense and a lot of testing if integration with system is as expected 6. as it is generally not new package, the review process '''should''' be only formal - to know maintainer and to create cvs repo 1. this is quite important, otherwise the new maintainer can become really frustrated, and we are forcing the dead package overorpahned so the full review (especially in alignment with rule 5) really should not be forced. 2. on the contrary, rules agreed here '''must''' be checked. (even the number 5) 7. all depending packages '''must''' keep requiring java-headless or java (and BuildRequires java-devel). Requirements on any exact jdk - or even worse on any exact legacy jdk are forbidden and needs FESCO exception. This option is forcing maintainers to fight with the name x current setup of alternatives. However, the work should be minimal. But it makes the update path pretty clear and it keeps users well protected against legacy jdk. option two - orphaning legacy jdks and ensure update path 1. main JDK is only orphaned when new main JDK landed 1. it do '''not''' Obsolate previous jdk 2. other rules (2-7) are same This is making life of legacy JDK maintainers a bit simpler. But I don't know, how to ensure proper obsolete implementation in this case. == Scope == * Proposal owners: are responsible for initial setup of those guidelines. The FESCO, the owners and pssible legacy JDKs maintainers have to agree on those rules. New legacy JDK can be then added anytime in Fedora lifecycle. * Other developers: no developers * Release engineering: in ideal case, no release engineer needed * Policies and guidelines: The proposal may split to proposal and Legacy JDKs in Fedora guidelines pages ___ Small restart. Looking to the discussion, although many people claimed against any rules at the end it seems to me that everybody agree on some rules - even if it would be existence of metapackage or only removed virtual provides and priority From that point of view, do you mind to help me to improve those rules? Looking to more inputs from https://fedorahosted.org/fpc/ticket/503 : Current state is fight between -legacy suffix and metapackage with provides. Except that : rule 2 is moreover agreed by all. rule 3
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
- Original Message - From: Jiri Vanek jva...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, February 27, 2015 12:54:04 PM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/27/2015 11:47 AM, Aleksandar Kurtakov wrote: - Original Message - From: Jiri Vanek jva...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, February 27, 2015 11:43:53 AM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/26/2015 02:51 PM, Jiri Vanek wrote: On 02/24/2015 10:34 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora Change owner(s): Jiri Vanek jva...@redhat.com Currently Fedora supports one main Java runtime and Java Development Kit (JDK) and from time to time one future JDK as a tech preview. This change should be set of rules, which will enable community to maintain legacy JDKs. Please note, people are bugging main JDK maintainers pretty often with this, and to allow them to maintain legacy JDKs is a step in right direction. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This is no real work proposal. The result of this proposal is set of rules, which will allow community maintainers to pack any legacy jdk and will be ensuring that this JDKs will not conflict by any other JDK and will smoothly integrate to system. The results are summarized here, and pledged for discussion until final resolution is done. === Proposed rules === 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. This must remain clear''' option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy 1. so from killed java-1.7.0-openjdk will become new package java-1.7.0- openjdk-legacy 2. next main jdk do Obsolete previous one as usually 2. new package '''must''' not do any virtual provides (aka java,java-devel)... (protection against random pull by as dependence) 1. it provides only itself by name 3 its priority '''must''' be kept on less digits (right now it would be 5) then main jdk (protection against winning in alternatives after update) 1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 are '''mandatory''' 4. at least one of the main-jdk's members '''must''' be set as comaintainer (to watch the commits and save the world if necessary) 5. new package '''should''' to follow both original jdk (ideally not change at all (except source updates and necessary)) and current main jdk as close as possibly 1. here it requires some common sense and a lot of testing if integration with system is as expected 6. as it is generally not new package, the review process '''should''' be only formal - to know maintainer and to create cvs repo 1. this is quite important, otherwise the new maintainer can become really frustrated, and we are forcing the dead package overorpahned so the full review (especially in alignment with rule 5) really should not be forced. 2. on the contrary, rules agreed here '''must''' be checked. (even the number 5) 7. all depending packages '''must''' keep requiring java-headless or java (and BuildRequires java-devel). Requirements on any exact jdk - or even worse on any exact legacy jdk are forbidden and needs FESCO exception. This option is forcing maintainers to fight with the name x current setup of alternatives. However, the work should be minimal. But it makes the update path pretty clear and it keeps users well protected against legacy jdk. option two - orphaning legacy jdks and ensure update path 1. main JDK is only orphaned when new main JDK landed 1. it do '''not''' Obsolate previous jdk 2. other rules (2-7) are same This is making life of legacy JDK maintainers a bit simpler. But I don't know, how to ensure proper obsolete implementation in this case. == Scope == * Proposal owners: are responsible for initial setup of those guidelines. The FESCO, the owners and pssible legacy JDKs maintainers have to agree on those rules. New legacy JDK can be then added anytime in Fedora lifecycle. * Other developers: no developers * Release engineering: in ideal case, no release engineer needed * Policies and guidelines: The proposal may split to proposal and Legacy JDKs in Fedora guidelines pages ___ Small
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
- Original Message -
From: Aleksandar Kurtakov akurt...@redhat.com
To: Development discussions related to Fedora
devel@lists.fedoraproject.org
Sent: Friday, February 27, 2015 12:58:05 PM
Subject: Re: F22 System Wide Change: Legacy implementations of the Java
platform in Fedora
- Original Message -
From: Jiri Vanek jva...@redhat.com
To: Development discussions related to Fedora
devel@lists.fedoraproject.org
Sent: Friday, February 27, 2015 12:54:04 PM
Subject: Re: F22 System Wide Change: Legacy implementations of the Java
platform in Fedora
On 02/27/2015 11:47 AM, Aleksandar Kurtakov wrote:
- Original Message -
From: Jiri Vanek jva...@redhat.com
To: devel@lists.fedoraproject.org
Sent: Friday, February 27, 2015 11:43:53 AM
Subject: Re: F22 System Wide Change: Legacy implementations of the Java
platform in Fedora
On 02/26/2015 02:51 PM, Jiri Vanek wrote:
On 02/24/2015 10:34 AM, Jaroslav Reznik wrote:
= Proposed System Wide Change: Legacy implementations of the Java
platform
in
Fedora =
https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora
Change owner(s): Jiri Vanek jva...@redhat.com
Currently Fedora supports one main Java runtime and Java Development
Kit
(JDK)
and from time to time one future JDK as a tech preview. This change
should
be
set of rules, which will enable community to maintain legacy JDKs.
Please
note, people are bugging main JDK maintainers pretty often with this,
and
to
allow them to maintain legacy JDKs is a step in right direction.
* This Change is announced after the Change Submission Deadline as an
exception to the process. May not be approved for proposed Fedora
release.
*
== Detailed Description ==
This is no real work proposal. The result of this proposal is set of
rules,
which will allow community maintainers to pack any legacy jdk and will
be
ensuring that this JDKs will not conflict by any other JDK and will
smoothly
integrate to system. The results are summarized here, and pledged for
discussion until final resolution is done.
=== Proposed rules ===
0. '''Main JDK maintainers are not never ever responsible for any
legacy
jdk.
This must remain clear'''
option one - introducing new packages - preferred
1. main jdk is proclaimed as dead as it was until now. The new jdk is
derived
as new package prviousName-legacy
1. so from killed java-1.7.0-openjdk will become new package
java-1.7.0-
openjdk-legacy
2. next main jdk do Obsolete previous one as usually
2. new package '''must''' not do any virtual provides (aka
java,java-devel)...
(protection against random pull by as dependence)
1. it provides only itself by name
3 its priority '''must''' be kept on less digits (right now it would
be
5)
then main jdk (protection against winning in alternatives after
update)
1. the automated check as
https://bugzilla.redhat.com/show_bug.cgi?id=1189084
are '''mandatory'''
4. at least one of the main-jdk's members '''must''' be set as
comaintainer
(to watch the commits and save the world if necessary)
5. new package '''should''' to follow both original jdk (ideally not
change
at all (except source updates and necessary)) and current main jdk as
close as
possibly
1. here it requires some common sense and a lot of testing if
integration
with system is as expected
6. as it is generally not new package, the review process '''should'''
be
only
formal - to know maintainer and to create cvs repo
1. this is quite important, otherwise the new maintainer can become
really
frustrated, and we are forcing the dead package overorpahned so
the
full
review (especially in alignment with rule 5) really should not be
forced.
2. on the contrary, rules agreed here '''must''' be checked. (even
the
number 5)
7. all depending packages '''must''' keep requiring java-headless or
java
(and
BuildRequires java-devel). Requirements on any exact jdk - or even
worse
on
any exact legacy jdk are forbidden and needs FESCO exception.
This option is forcing maintainers to fight with the name x current
setup
of
alternatives. However, the work should be minimal. But it makes the
update
path pretty clear and it keeps users well protected against legacy
jdk.
option two - orphaning legacy jdks and ensure update path
1. main JDK is only orphaned when new main JDK landed
1. it do '''not''' Obsolate previous jdk
2. other rules (2-7) are same
This is making life of legacy JDK maintainers a bit simpler. But I
don't
know,
how to ensure proper obsolete implementation in this case.
== Scope ==
* Proposal owners: are responsible for initial setup of those
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/27/2015 11:58 AM, Aleksandar Kurtakov wrote: - Original Message - From: Jiri Vanek jva...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, February 27, 2015 12:54:04 PM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/27/2015 11:47 AM, Aleksandar Kurtakov wrote: - Original Message - From: Jiri Vanek jva...@redhat.com To: devel@lists.fedoraproject.org Sent: Friday, February 27, 2015 11:43:53 AM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/26/2015 02:51 PM, Jiri Vanek wrote: On 02/24/2015 10:34 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora Change owner(s): Jiri Vanek jva...@redhat.com Currently Fedora supports one main Java runtime and Java Development Kit (JDK) and from time to time one future JDK as a tech preview. This change should be set of rules, which will enable community to maintain legacy JDKs. Please note, people are bugging main JDK maintainers pretty often with this, and to allow them to maintain legacy JDKs is a step in right direction. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This is no real work proposal. The result of this proposal is set of rules, which will allow community maintainers to pack any legacy jdk and will be ensuring that this JDKs will not conflict by any other JDK and will smoothly integrate to system. The results are summarized here, and pledged for discussion until final resolution is done. === Proposed rules === 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. This must remain clear''' option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy 1. so from killed java-1.7.0-openjdk will become new package java-1.7.0- openjdk-legacy 2. next main jdk do Obsolete previous one as usually 2. new package '''must''' not do any virtual provides (aka java,java-devel)... (protection against random pull by as dependence) 1. it provides only itself by name 3 its priority '''must''' be kept on less digits (right now it would be 5) then main jdk (protection against winning in alternatives after update) 1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 are '''mandatory''' 4. at least one of the main-jdk's members '''must''' be set as comaintainer (to watch the commits and save the world if necessary) 5. new package '''should''' to follow both original jdk (ideally not change at all (except source updates and necessary)) and current main jdk as close as possibly 1. here it requires some common sense and a lot of testing if integration with system is as expected 6. as it is generally not new package, the review process '''should''' be only formal - to know maintainer and to create cvs repo 1. this is quite important, otherwise the new maintainer can become really frustrated, and we are forcing the dead package overorpahned so the full review (especially in alignment with rule 5) really should not be forced. 2. on the contrary, rules agreed here '''must''' be checked. (even the number 5) 7. all depending packages '''must''' keep requiring java-headless or java (and BuildRequires java-devel). Requirements on any exact jdk - or even worse on any exact legacy jdk are forbidden and needs FESCO exception. This option is forcing maintainers to fight with the name x current setup of alternatives. However, the work should be minimal. But it makes the update path pretty clear and it keeps users well protected against legacy jdk. option two - orphaning legacy jdks and ensure update path 1. main JDK is only orphaned when new main JDK landed 1. it do '''not''' Obsolate previous jdk 2. other rules (2-7) are same This is making life of legacy JDK maintainers a bit simpler. But I don't know, how to ensure proper obsolete implementation in this case. == Scope == * Proposal owners: are responsible for initial setup of those guidelines. The FESCO, the owners and pssible legacy JDKs maintainers have to agree on those rules. New legacy JDK can be then added anytime in Fedora lifecycle. * Other developers: no developers * Release engineering: in ideal case, no release engineer needed * Policies and guidelines: The proposal may split to proposal and Legacy JDKs in Fedora guidelines pages ___ Small restart. Looking to the discussion, although many people claimed against any rules at the end it seems to me that everybody agree on some rules - even if it would be existence of
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/27/2015 10:47 AM, Aleksandar Kurtakov wrote: If we want to be sure that this legacy jdk will not interfere with the system JDK let it not provide anything via alternatives. That way people that want it can use it by playing with PATH/JAVA_HOME (just like they do with other JVMs). That's right. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/27/2015 10:58 AM, Aleksandar Kurtakov wrote: The problem with alternatives is they are system wide so if one changes the alternatives to point to the legacy JDK for their third party app this becomes the JDK system wide. Thus all Fedora packaged Java apps (Tomcat, Jetty, JBoss, Freemind, Azureus, Eclipse...) will start using this JDK but they will contain jars compiled for newer JDK thus will fail at runtime. Exactly. But it's worse than that: someone sets an alternative for some temporary purpose, then reboots their computer, then they get pwned via the vulnerable Java. I'm all for freedom, but we should not install traps for our users. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 106 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3989/cross-binutils-2.23.88.0.1-2.el7.1 22 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0626/perl-Gtk2-1.2495-1.el7 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0977/novnc-0.5.1-2.el7 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0952/qpid-cpp-0.30-12.el7 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0862/nodejs-0.10.36-3.el7,libuv-0.10.34-1.el7,v8-3.14.5.10-17.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing abduco-0.3-1.el7 botan-1.10.9-4.el7 collectd-5.4.2-1.el7 libpgf-6.14.12-1.el7 octave-netcdf-1.0.6-1.el7 perl-Monitoring-Plugin-0.38-1.el7.1 python-flask-whooshalchemy-0.6-6.el7 python-fudge-1.0.3-6.el7 qpid-qmf-0.28-27.el7 qt5-qtbase-5.4.1-2.el7 qt5-qtconnectivity-5.4.1-1.el7 qt5-qtdeclarative-5.4.1-1.el7 qt5-qtdoc-5.4.1-1.el7 qt5-qtgraphicaleffects-5.4.1-1.el7 qt5-qtimageformats-5.4.1-1.el7 qt5-qtlocation-5.4.1-1.el7 qt5-qtmultimedia-5.4.1-1.el7 qt5-qtquick1-5.4.1-1.el7 qt5-qtquickcontrols-5.4.1-1.el7 qt5-qtscript-5.4.1-1.el7 qt5-qtsensors-5.4.1-1.el7 qt5-qtsvg-5.4.1-1.el7 qt5-qttools-5.4.1-1.el7 qt5-qttranslations-5.4.1-1.el7 qt5-qtwebkit-5.4.1-1.el7 qt5-qtx11extras-5.4.1-1.el7 qt5-qtxmlpatterns-5.4.1-1.el7 spamass-milter-0.4.0-1.el7 waf-1.8.6-1.el7 Details about builds: abduco-0.3-1.el7 (FEDORA-EPEL-2015-1006) Session management in a clean and simple way Update Information: Update to 0.3 release ChangeLog: * Thu Feb 26 2015 Denis Fateyev de...@fateyev.com - 0.3-1 - Update to 0.3 release References: [ 1 ] Bug #1194491 - abduco-0.3 is available https://bugzilla.redhat.com/show_bug.cgi?id=1194491 botan-1.10.9-4.el7 (FEDORA-EPEL-2015-0993) Crypto library written in C++ Update Information: Update to Botan 1.10.9, with these changes: * Fixed EAX tag verification to run in constant time. * The default TLS policy now disables SSLv3. * A crash could occur when reading from a blocking random device if the device initially indicated that entropy was available but a concurrent process drained the entropy pool before the read was initiated. * Fix decoding indefinite length BER constructs that contain a context sensitive tag of zero. Github pull 26 from Janusz Chorko. * The botan-config script previously tried to guess its prefix from the location of the binary. However this was error prone, and now the script assumes the final installation prefix matches the value set during the build. Github issue 29. Additionally, these changes have been made to the Fedora package: * Re-enable cleared ECC. * Disable gmp engine. * Use _pkgdocdir. ChangeLog: * Thu Feb 26 2015 Thomas Moschny thomas.mosc...@gmx.de - 1.10.9-4 - Update to 1.10.9, based on the current rawhide spec file, also containing these changes: - Re-enable cleared ECC (s...@fedoraproject.org) - Disable gmp engine (rhbz#1116406) - Use _pkgdocdir References: [ 1 ] Bug #615372 - botan implements elliptic curve crypto https://bugzilla.redhat.com/show_bug.cgi?id=615372 [ 2 ] Bug #1116406 - botan overwrites gmp's default memory functions https://bugzilla.redhat.com/show_bug.cgi?id=1116406 [ 3 ] Bug #1149208 - botan-config-1.10 --cflags doesn't work https://bugzilla.redhat.com/show_bug.cgi?id=1149208 collectd-5.4.2-1.el7 (FEDORA-EPEL-2015-1009) Statistics collection daemon for filling RRD files Update Information: Upstream released new version See https://collectd.org/news.shtml for the release notes. ChangeLog: * Fri Feb 27 2015 ru...@rubenkerkhof.com 5.4.2-1 - Upstream released new version - Enable write_riemann plugin - Use collection.conf from upstream - Improve the systemd unit a bit
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 1042 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 106 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4008/cross-binutils-2.23.51.0.3-1.el6.1 95 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4242/facter-1.6.18-8.el6 83 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4485/python-tornado-2.2.1-7.el6 65 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4884/mapserver-6.0.4-1.el6 63 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4918/dokuwiki-0-0.23.20140929b.el6 45 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0232/chicken-4.9.0.1-2.el6 22 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0644/perl-Gtk2-1.2495-1.el6 19 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0696/drupal7-path_breadcrumbs-3.2-1.el6 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0701/unbound-1.5.1-1.el6 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0738/drupal6-views-2.18-1.el6 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0740/python-crypto2.6-2.6.1-2.el6 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0779/drupal7-views-3.10-1.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0942/novnc-0.5.1-2.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0864/nodejs-0.10.36-3.el6,libuv-0.10.34-1.el6,v8-3.14.5.10-17.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0992/libpng10-1.0.63-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0985/drupal7-entity-1.6-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing abduco-0.3-1.el6 drupal6-admin_menu-1.9-1.el6 drupal7-entity-1.6-1.el6 drupal7-migrate-2.7-1.el6 golang-github-beorn7-perks-0-0.1.gitb965b61.el6 golang-github-docker-spdystream-0-0.1.git29e1da2.el6 golang-github-golang-groupcache-0-0.1.git604ed57.el6 golang-github-gorilla-websocket-0-0.1.gitab5b3a6.el6 golang-github-prometheus-client_golang-0-0.2.git39e4bc8.el6 golang-github-shurcooL-sanitized_anchor_name-0-0.1.git8e87604.el6 ikiwiki-3.20150107-1.el6 libpng10-1.0.63-1.el6 mydns-1.2.8.31-2.el6 perl-Monitoring-Plugin-0.38-1.el6.1 python-fudge-1.0.3-6.el6 Details about builds: abduco-0.3-1.el6 (FEDORA-EPEL-2015-1003) Session management in a clean and simple way Update Information: Update to 0.3 release ChangeLog: * Thu Feb 26 2015 Denis Fateyev de...@fateyev.com - 0.3-1 - Update to 0.3 release References: [ 1 ] Bug #1194491 - abduco-0.3 is available https://bugzilla.redhat.com/show_bug.cgi?id=1194491 drupal6-admin_menu-1.9-1.el6 (FEDORA-EPEL-2015-0990) Provides a dropdown menu to most administrative tasks Update Information: ## 6.x-1.9 - Issue #2360249 by pvasili, konstantin.komelin, Eyal Shalev, ofry, Plazik, dalin, gngn, marcmueller: Fixed tertiary menu items not visible in Firefox 34. - Issue #927018 by DamienMcKenna, mikeytown2: Fixed PHP notice in admin_menu_link_build(). ChangeLog: * Fri Feb 27 2015 Shawn Iwinski shawn.iwin...@gmail.com - 1.9-1 - Updated to 1.9 (BZ #1195728) - Removed RPM README b/c it only explained common Drupal workflow - %license usage - Spec cleanup * Sat Jun 7 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.8-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild * Sat Aug 3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.8-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild * Wed Feb 13 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.8-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild * Wed Jul 18 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.8-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild * Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.8-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild References: [ 1 ] Bug #1195728 - drupal6-admin_menu-1.9 is available https://bugzilla.redhat.com/show_bug.cgi?id=1195728
[389-devel] Please review (take 2): [389 Project] #48048: Fix coverity issues - 2015/2/24
https://fedorahosted.org/389/ticket/48048 https://fedorahosted.org/389/attachment/ticket/48048/0006-Ticket-48048-Fix-coverity-issues-2015-2-24.2.patch https://fedorahosted.org/389/attachment/ticket/48048/0032-Ticket-48048-Fix-coverity-issues-2015-2-24.2.patch https://fedorahosted.org/389/attachment/ticket/48048/0041-Ticket-48048-Fix-coverity-issues-2015-2-24.patch git patch file (master) -- get rid of (long long unsigned int) cast -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Fedora 22 Alpha Freeze
On Fri, Feb 27, 2015 at 8:50 AM, Peter Robinson pbrobin...@gmail.com wrote: On Fri, Feb 27, 2015 at 3:23 PM, Dave Johansen davejohan...@gmail.com wrote: On Tue, Feb 24, 2015 at 11:24 AM, Dennis Gilmore den...@ausil.us wrote: Today is also the Alpha freeze[4]. This means that only packages which fix accepted blocker or freeze exception bugs[5][6] will be marked as 'stable' and included in the Alpha composes. Other builds will remain in updates-testing until the Alpha release is approved, at which point the Alpha freeze is lifted and packages can move to 'stable' as usual until the Beta freeze. I have a question on how I'm supposed to handle a new package. I was working on packaging iwyu [1] and it built for all of the target releases except for F22 because of some gcc 5.0 issues. It appears that the last one has been resolved [2], so how do I handle this situation? Do I just wait until the alpha freeze is over to build iwyu for F22? Or should I use a buildroot override? Build it as per normal, if it's a single package submit it to bodhi as an update for F-22, if you need to build other packages against it you'll need to do a build override as per normal stable releases. http://koji.fedoraproject.org/koji/taskinfo?taskID=9096041 The package doesn't build and needs the gcc update in order to build. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1197281] New: perl-Perl-Critic-1.124 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1197281 Bug ID: 1197281 Summary: perl-Perl-Critic-1.124 is available Product: Fedora Version: rawhide Component: perl-Perl-Critic Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Latest upstream release: 1.124 Current version/release in rawhide: 1.123-1.fc22 URL: http://search.cpan.org/dist/Perl-Critic/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=goXbSEG5ena=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 1197281] perl-Perl-Critic-1.124 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1197281 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Scratch build succeeded http://koji.fedoraproject.org/koji/taskinfo?taskID=9096308 -- 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=oncKTTInhWa=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-Net-DNS] 0.83 bump
commit 8c7495572369852c46523d99eec4968c7a621e5d
Author: Petr Šabata con...@redhat.com
Date: Fri Feb 27 10:59:42 2015 +0100
0.83 bump
- Correct the dependency list
- Modernize the spec a bit
.gitignore| 1 +
perl-Net-DNS.spec | 36 +---
sources | 2 +-
3 files changed, 27 insertions(+), 12 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 74ee0a8..4d9ae2c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -17,3 +17,4 @@ Net-DNS-0.65.tar.gz
/Net-DNS-0.80.tar.gz
/Net-DNS-0.81.tar.gz
/Net-DNS-0.82.tar.gz
+/Net-DNS-0.83.tar.gz
diff --git a/perl-Net-DNS.spec b/perl-Net-DNS.spec
index 89a0560..938a8b2 100644
--- a/perl-Net-DNS.spec
+++ b/perl-Net-DNS.spec
@@ -1,5 +1,5 @@
Name: perl-Net-DNS
-Version: 0.82
+Version: 0.83
Release: 1%{?dist}
Summary: DNS resolver modules for Perl
# lib/Net/DNS/RR/OPT.pm:MIT
@@ -12,7 +12,7 @@ Source0:
http://search.cpan.org/CPAN/authors/id/N/NL/NLNETLABS/Net-DNS-%{v
BuildRequires: %{_bindir}/iconv
BuildRequires: perl
BuildRequires: perl(Config)
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.76
BuildRequires: perl(Getopt::Long)
BuildRequires: perl(IO::Socket)
BuildRequires: perl(strict)
@@ -25,13 +25,16 @@ BuildRequires: perl(Data::Dumper)
# Digest::BubbleBabble is optional
BuildRequires: perl(Digest::BubbleBabble)
%endif
-BuildRequires: perl(Digest::HMAC_MD5) = 1
+BuildRequires: perl(Digest::HMAC) = 1.01
+BuildRequires: perl(Digest::MD5) = 2.13
+BuildRequires: perl(Digest::SHA) = 5.23
# Digest::SHA is not used
# DynaLoader not used
BuildRequires: perl(Encode)
BuildRequires: perl(Exporter)
BuildRequires: perl(FileHandle)
BuildRequires: perl(integer)
+BuildRequires: perl(IO::File)
BuildRequires: perl(IO::Select)
BuildRequires: perl(IO::Socket::INET)
# IO::Socket::INET6 is optional
@@ -46,23 +49,30 @@ BuildRequires: perl(vars)
# Win32::TieRegistry is not needed
BuildRequires: perl(XSLoader)
# Tests:
-BuildRequires: perl(diagnostics)
+BuildRequires: perl(File::Find)
BuildRequires: perl(File::Spec)
BuildRequires: perl(Test::Builder)
-BuildRequires: perl(Test::More) = 0.18
+BuildRequires: perl(Test::More) = 0.52
# Optional tests:
BuildRequires: perl(Test::Pod) = 0.95
-Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-Requires: perl(Digest::HMAC_MD5) = 1
+Requires: perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo $version))
+Requires: perl(Digest::HMAC) = 1.01
+Requires: perl(Digest::MD5) = 2.13
+Requires: perl(Digest::SHA) = 5.23
Requires: perl(Encode)
Requires: perl(Exporter)
+Requires: perl(FileHandle)
+Requires: perl(IO::File)
Requires: perl(MIME::Base64) = 2.11
Requires: perl(XSLoader)
%{?perl_default_filter}
# Do not export under-specified dependencies
-%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\((Digest::HMAC_MD5|MIME::Base64)\\)$
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(Digest::HMAC\\)$
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(Digest::MD5\\)$
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(Digest::SHA\\)$
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(MIME::Base64\\)$
# Do not export under-specified provides
%global __provides_exclude
%{?__provides_exclude:%__provides_exclude|}^perl\\((Net::DNS::Text)\\)$
%global __provides_exclude
%{?__provides_exclude:%__provides_exclude|}^perl\\((Net::DNS::RR::OPT)\\)$
@@ -95,13 +105,12 @@ done
%build
export PERL_MM_USE_DEFAULT=yes
-perl Makefile.PL INSTALLDIRS=vendor --no-online-tests
+perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1 --no-online-tests
make %{?_smp_mflags} OPTIMIZE=%{optflags}
%install
make pure_install DESTDIR=%{buildroot}
-find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
-find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
+find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} +
chmod -R u+w %{buildroot}/*
%check
@@ -125,6 +134,11 @@ make test
%{_mandir}/man3/Net::DNS::Nameserver*
%changelog
+* Fri Feb 27 2015 Petr Šabata con...@redhat.com - 0.83-1
+- 0.83 bump
+- Correct the dependency list
+- Modernize the spec a bit
+
* Tue Jan 20 2015 Paul Wouters pwout...@redhat.com - 0.82-1
- Updated to 0.82 Support for IPv6 link-local addresses with scope_id
diff --git a/sources b/sources
index fbb797b..cf7dc24 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-95660d1f81ddd087639a6ea132b8 Net-DNS-0.82.tar.gz
+f1d48107ff6b366479ad035783486d7a Net-DNS-0.83.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
File Net-DNS-0.83.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Net-DNS: f1d48107ff6b366479ad035783486d7a Net-DNS-0.83.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 1196916] perl-Net-DNS-0.83 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1196916 --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- psabata's perl-Net-DNS-0.83-1.fc23 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=615685 -- 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=K8wAxmEmnfa=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: koji is broken
Ralf Corsepius venit, vidit, dixit 26.02.2015 19:09: On 02/26/2015 06:44 PM, Matěj Cepl wrote: On 2015-02-26, 16:22 GMT, Ralf Corsepius wrote: That should be completely unrelated to the kojipkgs issue, as that is talking to the koji hub directly. And would you have the kindness to tell me what I can to about it? This is usually very clear and obvious way how Koji tells me that my certificates have expired. Haha. Great sense of humor, Matěj. Running fedora-packager-setup should take care of it. The koji message is far from being clear. My certificate definitely had not expired. From ~/.fedora.cert ... Validity Not Before: Feb 3 03:23:15 2015 GMT Not After : Aug 2 03:23:15 2015 GMT ... # fedora-cert -v Verifying Certificate cert expires: 2015-08-02 Ralf Yes Ralf, fedora-cert is the better way to deal with the certs (rather than re-running setup). We used to be able to download a new cert from FAS. That page seems to be MIA now without any reference to the cli tools. Doesn't help either. Have you tried getting a new cert (even though yours is supposed to be valid)? Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1196916] perl-Net-DNS-0.83 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1196916 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Net-DNS-0.83-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-Net-DNS-0.83-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=cA6wBQjQTCa=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 1196916] perl-Net-DNS-0.83 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1196916 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-Net-DNS-0.83-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/perl-Net-DNS-0.83-1.fc22 -- 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=JhxEEYfLY5a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 26/02/15 14:59, Mario Torre wrote: In this case, it's about giving users one thing they asked, which is easy access to a previous version of Java. We can't afford maintaining it as Java Team, but this doesn't mean we will refuse to help people doing it. In fact, the exact existence of this very same discussion is our attempt to pass the ball back to the Community. It's not just a matter of not being able to afford to continue maintenance, but the knowledge that unless an obsolete Java implementation is carefully locked down it may not be safe to use. This proposal is intended to prevent the accidental use of an obsolete implementation. Some of the proposed rules can reasonably be argued about, but the need to prevent an obsolete Java implementation from accidentally being used by any part of the Fedora stack isn't. Of course, if a user decides to override this that's fine, and we should not make it unduly difficult, but it shouldn't happen by default in any Fedora installation. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: polymake
polymake has broken dependencies in the F-22 tree: On x86_64: polymake-2.13-18.git20141013.fc22.x86_64 requires perl = 4:5.20.1 On i386: polymake-2.13-18.git20141013.fc22.i686 requires perl = 4:5.20.1 On armhfp: polymake-2.13-18.git20141013.fc22.armv7hl requires perl = 4:5.20.1 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-DNS/f22] 0.83 bump
Summary of changes: 8c74955... 0.83 bump (*) (*) 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/f21] 0.83 bump
Summary of changes: 8c74955... 0.83 bump (*) (*) 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
