Re: Apps using default Python in Fedora vs. EPEL
On 27 February 2015 at 11:02, Toshio Kuratomi a.bad...@gmail.com wrote: On Feb 25, 2015 3:14 PM, Nick Coghlan ncogh...@gmail.com 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 I came back to this question myself due to a couple of different ideas, discussed in https://fedorahosted.org/fpc/ticket/498#comment:19 * How does the situation in Fedora change if the upstream PEP 494 recommendation to downstream Linux distros was to change in conjunction with the Python 3.5 release currently scheduled for September? That release (https://www.python.org/dev/peps/pep-0478/) amongst other things, automatically handles EINTR errors for syscalls, restores binary interpolation support and adds matrix multiplication support and os.scandir(). I would be against making the switch to /usr/bin/python at this time but would do most of that fighting upstream. If the pep were updated then I'd at least want to see that the other major distros are committed to changing their /usr/bin/python at the same time. Changing the behavior of a well known program like this is a bad idea. As it breaks compatibility: with people's home grown scripts, with their self installed programs, and between os's and os releases. The pep is palatable because the arguments in favor of someday changing the value revolve around someday there not being a /usr/bin/python on most systems. At that point it becomes reasonable to reallocate /usr/bin/python and let the systems where /usr/bin/python be declared legacy and the behavior of /usr/bin/python on those legacy systems is the quirk, not ours. We could cut over sooner than this argument actually makes the case for but now is definitely not that day. Fedora, rhel, ubuntu, aren't yet at the point where /usr/bin/python isn't present on most of their installed systems in their latest version, let alone all of their versions.people are still pulling /usr/bin/python onto their systems through dependencies for common applications even if their os is advanced enough not to need it by default. We have quite a ways to go before /usr/bin/python can be switched. Yeah, that's fair - a staggered release with the distros switching first before end user scripts makes sense. That would make the likely target date for a PEP 394 update some time in early 2017 with Python 3.6. We could *potentially* switch the recommendation some time in 2016 if all goes well with the distro migrations and significant libraries start dropping Python 2.7 support, but switching in conjunction with Python 3.5 would still be too soon. * With the default interpreter change postponed to Fedora 23, would it make sense to patch the system Python in Fedora 22 to emit Python 3 warnings by default when it was run using the unqualified python reference rather than being run as the qualified python2? And then switch the symlink along with the RPM macros in Fedora 23? No to switching the value of /usr/bin/python and stated above. The test makes some sense. If your warning is restricted to warning not to use /usr/bin/python (use /usr/bin/python 2 instead) that sounds really good to me. (Your wording sounded like we should turn on warnings like python2 -3 does which I don't think is such a good idea for fedora 22 but might be good in the future... our perhaps, like the kernel does with extra kernel debugging, we should turn it on in rawhide and fedora.n+1 but turn it off before release.) I did mean the latter (turning on -3 warnings), but I like your idea of only doing that in Rawhide and the Alpha releases for F23, and then switching to a simple use a qualified Python reference warning in the Betas and the actual release. It's also worth noting that the change I am considering to the upstream recommendation would place a qualifier on the distro providing a C.UTF-8 locale, so the C.UTF-8 in upstream glibc RFE (https://sourceware.org/bugzilla/show_bug.cgi?id=17318) would become a key enabler for making the symlink switch in Fedora (associated Fedora RFE: https://bugzilla.redhat.com/show_bug.cgi?id=902094) Like tomspur I'm not sure I see the specific relevance of this to what /usr/bin/python invokes although I would welcome the change :-) Being able to type LANG=C.UTF-8 instead of LANG=C fixes some of the odd corner cases where the interpreter startup sequence gets confused. However, I remembered that subtle issues aren't the ones we're worried about here - it's the big noisy ones like legacy print and exec statements. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: [Base] Base Design WG agenda meeting 27 February 2015 15:00 UTC on #fedora-meeting
On Thu, Feb 26, 2015 at 01:02:59PM +0100, 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. Unfortunately I can't attend meeting today. Of course I am +1 on Harald being new chairman of the group. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why sysrq is limited to only sync command on official fedora kernel?
On 25 February 2015 at 16:43, Josh Boyer jwbo...@fedoraproject.org wrote: On Wed, Feb 25, 2015 at 9:35 AM, Ali AlipourR alipoo...@gmail.com wrote: 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, create your own in /etc/sysctrl.d/, or (as root) set it to whatever you would like via /proc/sys/kernel/sysrq. Of course it can be changed at runtime, but I mean why official fedora kernel shouldn't be configured to allow all (or at least a wider subset) of sysrq commands by default? Maybe we're getting hung up on a terminology issue, but this isn't a kernel configuration issue. It's something userspace is doing. This way official fedora live CDs are unsuitable for system recovery tasks; you have to change sysrq value every time you use live CDs or build your own live CD. That's a good point. Since the live images have a rescue mode, maybe there is a way to use a different value when booted into that. How that would look, I'm not sure. Maybe dracut would need to include an override file in the initramfs. josh AFAIK the live images don't have a rescue mode/boot option; that mode is only available on the non-live installation DVD and the network-install images. -- Ahmad Samir -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [EPEL-devel] Question about EPEL 7 python-ipython*
On 02/27/2015 05:32 AM, Rahul Sundaram wrote: Hi On Thu, Feb 26, 2015 at 10:05 PM, Nordgren, Bryce L -FS wrote: I notice that ipython has not been released in epel7, but has a release version for epel6 and Fedora 20-22. Was there a decision to exclude it from epel, or is this due to lack of resources/interest? __ __ https://apps.fedoraproject.org/packages/python-ipython-notebook 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. Rahul ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Package giveaway
On Thu, Feb 26, 2015 at 11:29 AM, Tomas Bzatek tbza...@redhat.com wrote: I've just made the packages listed below orphan due to my departure from my current employer. Unfortunately I won't be able to invest my personal free time either. fpc: epel7 el6 el5 lazarus: epel7 el6 el5 tuxcmd udisks2 Feel free to pick up any. I took udisks2 and also added the GNOME SIG as committers since it's essential for Fedora Workstation. 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
[389-devel] please review: Ticket 48108 - nunc-stans - replace fprintf() with ns_log()
https://fedorahosted.org/389/ticket/48108 https://fedorahosted.org/389/attachment/ticket/48108/0001-Ticket-48108-replace-fprintf-with-ns_log.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[Bug 1100706] perl-Glib-Object-Introspection-0.028 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1100706 --- Comment #6 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Scratch build succeeded http://koji.fedoraproject.org/koji/taskinfo?taskID=9081016 -- 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=IIOGyXcOBwa=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 1196648] New: perl-Net-Statsd-Server-0.19 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1196648 Bug ID: 1196648 Summary: perl-Net-Statsd-Server-0.19 is available Product: Fedora Version: rawhide Component: perl-Net-Statsd-Server Keywords: FutureFeature, Triaged Assignee: dd...@cpan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org Latest upstream release: 0.19 Current version/release in rawhide: 0.17-3.fc22 URL: http://search.cpan.org/dist/Net-Statsd-Server/ 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=3QR8IX9lU3a=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 1196444] perl-List-Compare-0.48 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1196444 --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- psabata's perl-List-Compare-0.48-1.fc23 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=615383 -- 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=CpK7N8Rj7Qa=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 1192377] perl-List-Compare-0.43 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1192377 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-List-Compare-0.48-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-List-Compare-0.48-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=tL8BTwRv0Ga=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 09:43 AM, Aleksandar Kurtakov wrote: - Original Message - From: Jiri Vanek jva...@redhat.com To: devel@lists.fedoraproject.org Sent: Thursday, February 26, 2015 10:39:35 AM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/26/2015 09:31 AM, Aleksandar Kurtakov wrote: - Original Message - From: Mikolaj Izdebski mizde...@redhat.com To: devel@lists.fedoraproject.org Sent: Thursday, February 26, 2015 10:16:26 AM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/25/2015 06:58 PM, Miloslav Trmač wrote: On 02/24/2015 06:41 PM, Miloslav Trmač wrote: Hello, java would be the preferred JRE in Fedora. The package would have no content, but it would have Requires on preferred Fedora JRE, currently java-1.8.0-openjdk. This could be easily changed as default JRE changes. The same is for other binary subpackages of java, respectively. All system packages would require subpackages of java as they do now (unless there is good reason not to). Users that install java would get latest JRE, which would be updated to new major versions as they become default. Older JDKs would not be removed during update (unless there is no maintainer and they are obsoleted as currently), AFAIK nothing obsoletes a package just because it is orphaned… If no volunteer shows up for maintenance of old JDK then it would be deprecated and obsoleted, as it's was done with previous JDK packages. How would that work _exactly_? 1) JDK maintainers announce deprecation in advance and call for volunteers to maintain old JDK 2) when the time of deprecation comes, JDK package is reassigned to new maintainer, if such showed up; no obsoletes are added We speak about people that are already Fedora packagers, right? Just sponsoring someone that showed up and let him/her maintain Still it is possible scenario. I can even guess that this person will be apckaging newbe - most of java developers do not care about packaged stuff below. They have theirs Java EE and are happy that packages are solving all the issues they dont like. On contrary, if such a person wonts to pack it then you cna expect him to learn quicly. legacy JDK in Fedora is recipe for disaster. Thats what this guidelines should prevent... No, no guidelines can prevent someone putting %post rm -fr /etc in a spec file. There is a reason for not having blank approval for anybody. Then we are discussing only one point of this proposal. And I guees formal review one. Level of the formalness have to be agreed. And somebody have look over pacakge. I would say the rm rf / in postun is protected by step 5. By formal review I was higlighting that no jdk package can actually pass general review. J. Alexander Kurtakov Red Hat Eclipse team For not-yet-packagers they would have to go through the full review-sponsoring process. Alexander Kurtakov Red Hat Eclipse team 3) if there is no new maintainer then old JDK is redired in pkgdb, blocked in koji and obsoleted by some other package 4) if maintainer shows up after old JDK was retired then he can just revive package (passing review if needed); package release is bumped to be higher that obsoletes -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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/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? 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. update, but that's expected behaviour of package management software, such as DNF, and JDK packages should not differ from other Fedora Really should not? We done pretty god work to have only one main jdk unlike python1, python2,python3 or glib2,glib3,glibN... We are settled in special directory and so on. So in what is JDK actually similar to other packages? packages in this aspect. Consider a detailed example below. Thank you for this. I understood it from yuor describtion and already had the same. However I consider the keeping of old jdk as no-go for this. J. Assume we start with Java 7: sh-4.3# rpm -qa | grep java java-1.7.0-openjdk-1.7.0-1.fc23.x86_64 java-1.7.0-1.fc23.x86_64 Then update to newer version of java metapackage, which brings Java 8: sh-4.3# dnf -y update Using metadata from Thu Feb 26 09:51:07 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.6 k 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/3 Upgrading : java-666:1.8.0-1.fc23.x86_642/3 Cleanup : java-666:1.7.0-1.fc23.x86_643/3 Verifying : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6 1/3 Verifying : java-666:1.8.0-1.fc23.x86_642/3 Verifying : java-666:1.7.0-1.fc23.x86_643/3 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! Now both Java 8 and legacy Java 7 are installed: sh-4.3# rpm -qa | grep java java-1.8.0-1.fc23.x86_64 java-1.7.0-openjdk-1.7.0-1.fc23.x86_64 java-1.8.0-openjdk-1.8.0-1.fc23.x86_64 But user can easily remove packages which were installed to satisfy dependency, but which are no longer needed using autoremove command: sh-4.3# dnf -y autoremove Using metadata from Thu Feb 26 09:51:07 2015 Dependencies resolved. Package ArchVersion Repository Size Removing: java-1.7.0-openjdk x86_64 666:1.7.0-1.fc23@System0 Transaction Summary Remove 1 Package Installed size: 0 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Erasing : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6 1/1 Verifying : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6 1/1 Removed: java-1.7.0-openjdk.x86_64 666:1.7.0-1.fc23 After autoremove Java 7 is no longer installed: Complete! sh-4.3# rpm -qa | grep java java-1.8.0-1.fc23.x86_64 java-1.8.0-openjdk-1.8.0-1.fc23.x86_64 -- 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 Thu, 2015-02-26 at 09:00 +0100, Jiri Vanek wrote: On 02/24/2015 08:36 PM, Sumit Bhardwaj wrote: Hi All, I have been reading this mail chain for some time and there is something I wanted to say. It's kind of a long mail, I apologize for taking so much of your time but request you to please bear with me. I work as a technical consultant on IBM WebSphere, IBM BPM, Java/J2EE and Python technology stacks, who has to code on Java/J2EEquite often as well and I use Fedora 21 Workstation as my primary OS. My field of work is such that I need to use JDK versions 1.4, 5, 6, 7 and 8, all from time to time. This is because as time passed, solutions delivered to customers were built using incremental versions of Java/J2EE specifications and were not frequently upgraded. In my role, the changes/fixes I do to these enterprise apps are usually small and require only a certain jar file to be recompiled, or in some cases only one class. In such cases, maintaining binary compatibility is a must and for that I need to recompile that one jar/class with the original version of JDK that was used to compile the rest of the project in the first place. I use Oracle java in most cases due to corporate policies (for personal use, I use the latest version of OpenJDK). Now as per Oracle's policy, which I am sure is similar for OpenJDK as well, a particular version of JDK/JRE is updated till and even some time after the next major version is released, and then at a certain Update level, Oracle stops supporting it. That update version becomes the final update for that particular major release, and is sent into archives, while updates keep on getting released for the current version. With Oracle JDK, there are two installation approaches available for RPM based systems. They provide an RPM package which installs java in /usr/java, i.e. in system area and the latest installed java version become default. However, they also provides tarballs of JDKs, that contain certain standard directory structure of JDK intact inside one folder. These tarballs can be extracted and placed in any place on file system and once JAVA_HOME is pointed towards these+PATH is locally updated to include it, user can basically use this JDK without any issues. What version of Java is installed in system as default, in system area (/usr/java) become irrelevant. With IDEs like Eclipse and NetBeans the process is even simpler, as you can define these individual folders as JDKs for particular API versions in IDE configuration permanently and while creating a project can choose to use any of these defined JDKs. This is the approach that I take. I have the last updated versions of all the JDKs from 1.4 to 8 in my /opt folder. I have these configured in Eclipse and NetBeans for each API version and I use them all as required by the project. So I guess if OpenJDK can follow the same approach and can give an option to download tarballs of older versions and use them in place, without requiring any installation, as a definite directory structure, then the problem is solved. There is no need to maintain old version per se in repositories, as these are not updated anymore and the user will be able to use multiple versions without conflict of any kind. As for the default JDK, it can be kept how it is now i.e. The latest available JDK can be maintained in Fedora repos as they are being maintained now and updates can be provided for the defined lifetime of that JDK. Let me know what you guys think about this approach. This is lying on openjdk table for long time to have at least source tarballs... As you can see, nothing,. However once you are able to build jdk on your own, nothing prevents you form mercurial clone of *any* version. So this is the way you should go. If you wont binary images to be supported by openjdk itself, its completely different and more complex story. Indeed, and for that you need to go to an OS that supports long term stability, like RHEL or Centos (playing in house, but you have other choices). Fedora is not really good for that, since it promotes bleeding edge code over long term stability. Cheers, Mario -- 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/26/2015 04:40 PM, Kevin Fenzi wrote:
On Thu, 26 Feb 2015 15:26:32 +0100
Dan Horák d...@danny.cz wrote:
On Thu, 26 Feb 2015 15:11:33 +0100
Ralf Corsepius rc040...@freenet.de wrote:
Hi,
seems to me as if koji has seized operation:
https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log
https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log
I guess this is the known squid doesn't respond issue. nirik will
restart it.
Rather it's the known 'squid starts being very slow and failing some
builds' so that was me restarting it.
Just resubmit for now.
# fedpkg build
...
Could not execute build: [('SSL routines', 'SSL3_WRITE_BYTES', 'ssl
handshake failure')]
...
I am working on tracking down the problem, but it's proving quite
elusive. ;(
BTW: Here's another variant of a break down:
https://kojipkgs.fedoraproject.org//work/tasks/1835/9081835/root.log
This time, yum/dnf (whatever currently is being used, I presume it's
yum) is demonstrating one of the yum/dnf issues we discussed yesterday:
Yum retries to download packages from a mirror it could have know to be
broken, because it failed to connect to it before.
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: koji is broken
On Thu, 26 Feb 2015 17:06:03 +0100
Ralf Corsepius rc040...@freenet.de wrote:
On 02/26/2015 04:40 PM, Kevin Fenzi wrote:
On Thu, 26 Feb 2015 15:26:32 +0100
Dan Horák d...@danny.cz wrote:
On Thu, 26 Feb 2015 15:11:33 +0100
Ralf Corsepius rc040...@freenet.de wrote:
Hi,
seems to me as if koji has seized operation:
https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log
https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log
I guess this is the known squid doesn't respond issue. nirik will
restart it.
Rather it's the known 'squid starts being very slow and failing some
builds' so that was me restarting it.
Just resubmit for now.
# fedpkg build
...
Could not execute build: [('SSL routines', 'SSL3_WRITE_BYTES', 'ssl
handshake failure')]
...
That should be completely unrelated to the kojipkgs issue, as that is
talking to the koji hub directly.
Can you do a:
koji list-tasks --mine
I am working on tracking down the problem, but it's proving quite
elusive. ;(
BTW: Here's another variant of a break down:
https://kojipkgs.fedoraproject.org//work/tasks/1835/9081835/root.log
This time, yum/dnf (whatever currently is being used, I presume it's
yum) is demonstrating one of the yum/dnf issues we discussed
yesterday:
Yum retries to download packages from a mirror it could have know to
be broken, because it failed to connect to it before.
Sure, but then it would have just failed faster as thats the only
mirror thats defined internally for builders.
This was caused by my restarting squid.
kevin
pgpCtE440p51r.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1196763] Review Request: perl-Tie-Cache - LRU Cache in Memory
https://bugzilla.redhat.com/show_bug.cgi?id=1196763 Denis Fateyev de...@fateyev.com changed: What|Removed |Added CC||perl-devel@lists.fedoraproj ||ect.org -- 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=hpE8I3UaWqa=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: Libinput now enabled as default xorg driver for F-22 workstation installs
On Thu, 26 Feb 2015 09:49:48 +0100 Hans de Goede hdego...@redhat.com wrote: Yes, we need to maintain both stacks for a while anyways for e.g. lxde users, etc. Given that XFCE now supports libinput too, we could reconsider this and make xorg-drv-libinput a hard dep of the X server so that everyone gets it, but officially we are past the end of the feature merge window. Peter, any thoughts on this ? Note that Xfce does have support commited to the 4.11.x branch, but thats not in Fedora currently. :) We could backport that patch to 4.10, but we are hoping there might actually be a 4.12 release this coming weekend, and if all looks good/stable in rawhide, we might push for a late f22 change to get it in f22. If all that happens, then yes, we would be fine with a libinput change. ;) kevin pgpQr_EJjkwXA.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1196763] Review Request: perl-Tie-Cache - LRU Cache in Memory
https://bugzilla.redhat.com/show_bug.cgi?id=1196763 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? -- 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=rUUyECf0xNa=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
[389-devel] please review: Ticket 48039 - nunc-stans malloc should be pluggable
https://fedorahosted.org/389/ticket/48039 DS Patch https://fedorahosted.org/389/attachment/ticket/48039/0001-Ticket-48039-nunc-stans-malloc-should-be-pluggable.patch nunc-stans patch https://fedorahosted.org/389/attachment/ticket/48039/0001-Ticket-48039-Allow-for-pluggable-malloc-calloc-etc.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: koji is broken
On 02/26/2015 05:12 PM, Kevin Fenzi wrote:
On Thu, 26 Feb 2015 17:06:03 +0100
Ralf Corsepius rc040...@freenet.de wrote:
On 02/26/2015 04:40 PM, Kevin Fenzi wrote:
On Thu, 26 Feb 2015 15:26:32 +0100
Dan Horák d...@danny.cz wrote:
On Thu, 26 Feb 2015 15:11:33 +0100
Ralf Corsepius rc040...@freenet.de wrote:
Hi,
seems to me as if koji has seized operation:
https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log
https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log
I guess this is the known squid doesn't respond issue. nirik will
restart it.
Rather it's the known 'squid starts being very slow and failing some
builds' so that was me restarting it.
Just resubmit for now.
# fedpkg build
...
Could not execute build: [('SSL routines', 'SSL3_WRITE_BYTES', 'ssl
handshake failure')]
...
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?
Can you do a:
koji list-tasks --mine
# koji list-tasks --mine
Error: [('SSL routines', 'SSL3_READ_BYTES', 'ssl handshake failure')]
I am working on tracking down the problem, but it's proving quite
elusive. ;(
BTW: Here's another variant of a break down:
https://kojipkgs.fedoraproject.org//work/tasks/1835/9081835/root.log
This time, yum/dnf (whatever currently is being used, I presume it's
yum) is demonstrating one of the yum/dnf issues we discussed
yesterday:
Yum retries to download packages from a mirror it could have know to
be broken, because it failed to connect to it before.
Sure, but then it would have just failed faster as thats the only
mirror thats defined internally for builders.
yum could have tried a different mirror instead of retrying the already
broken one again.
--
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 Petr Šabata psab...@redhat.com changed: What|Removed |Added Flags|fedora-review? |fedora-review+ --- Comment #1 from Petr Šabata psab...@redhat.com --- Drop the warnings BR, the pragma is not used anywhere. No blockers. 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=EMrtznke80a=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 Tue, 2015-02-24 at 18:22 +0100, Mikolaj Izdebski wrote: On 02/24/2015 05:21 PM, Mario Torre wrote: On Tue, 2015-02-24 at 15:37 +0100, Mikolaj Izdebski wrote: On 02/24/2015 02:15 PM, Jiri Vanek wrote: On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote: I am against official guidelines or policy for legacy JDK packages. I don't think that any such policy is needed and it would only encourage adoption of old packages for which there might be no security updates. Well thats the point - people are calling for them. And wont to maintain them with this risk. I thought that the point of this change proposal was enabling community to maintain legacy JDKs, not encouraging people to package them without good reason or without involvement to truly maintaining them. Packaging older JDKs is *already* possible, so IMHO this change accomplishes nothing but showing people how they can dump old, unmaintained software into Fedora. Well, in this case it would not be un-maintained, the Fedora package would *not* be maintained *by us* (the Red Hat Java Team) indeed, but we are still actively contributing to the upstream software in its various versions. While you as a packager cannot specifically count on that, there's still a level of confidence that the base software won't be abandoned any time soon. And even when we will stop supporting those older versions, the community will take over if there is a need for that, exactly like we have done ourselves before. Indeed, there's an overhead for the downstream maintainers, we may need to drop specific version of OpenJDK, or skip a release, or do other funny things and the Fedora maintainers will have to adapt, but this is no different than usual I believe. Realistically, we are so conservative with older JDKs that I doubt this will ever really be an issue. Correct me if I am wrong, but in my understanding maintaining JDK package requires a lot of ongoing work (including obtaining and applying patches, running TCK, pushing updates in timely manner and so on). JDK maintainers should know this and I'm assuming that the amount of required work is the main reason for them not wanting to maintain older JDKs. The work required to add old JDK package to Fedora is relatively small compared to ongoing maintenance work. Someone willing to truly maintain JDK in Fedora should have knowledge about JDK packaging and they shouldn't have problem finding time to come up with a working solution, proposing and discussing it. Indeed, but don't underestimate this relatively, which is the main reason why *we* won't do that. If you make the process of adding legacy JDKs to Fedora too easy then someone without enough time and required knowledge will surely do that and we may easily end with unmaintained package. I'd rather not have old JDK than have unmaintained JDK with security holes. I don't see how giving proper rules means making something like that easy. The fact is that making things artificially complicated just to scare off people from doing them doesn't really match with my view of Freedom. I think instead that rules, however complex for the matter at hand, should be crafted so that they impose the minimum possible overhead. 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. Package that doesn't pass review shouldn't be part of Fedora. Well, if your goal is to reduce the user base of Fedora, I'm sure we can talk about removing the JDK :) We can't sacrifice our basic principles (such as passing review) for the sake of increasing user base. If you put the mean before the end, yes. But I hope you will agree with me that one of those core principles *is* the Freedom of allowing users to use such a critical tool as Java for their own daily reasons *without* forcing them to switch distribution. While I see your point that this can be extended to anything (why don't we package an older Eclipse?) so we need to draw a line, I believe an important core component like the JDK falls in that category of things that should be allowed to coexist even a bit longer than originally intended. Now, the question is how to make this happens by preserving both quality and freedom. Cheers, Mario -- 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
Am 26.02.2015 um 16:37 schrieb Jóhann B. Guðmundsson: On 02/26/2015 02:10 PM, Reindl Harald wrote: really? why? how do you come to that weird conclusion? surely, one can say not my package, not my problem but that's ignorant and needs no guidelines and policies - sanity should be enough I guess you did not grasp I was referring to the ownership model of components in the distribution which are irrelevant to guidelines and policy's i did The fact is the distribution has been using the ownership model since it's interception which means one to one mapping from a component to an individual. As such the thought process of I take care of what I own has been breed into maintainers for the past ten years. and i doubt that this is true in general every maintainer with responsiblity is or should be aware that his piece is *part of a distribution* because otherwise he could just build his package outside for his own There have been several cases where the community has explode due to lack of communications as an result of that with the most notorious of those being the Gnome half of the Red Hat's desktop team where more often than not they have broken bits for other *DE's that have been sharing underlying components in the distribution. ( search this lists archives if you need proof of that ) and without the ownership model it would have been prevented what model would you use? you can't only say that model is wrong without any alternative having everybody mangle every package is also not a solution because you can't expect the needed knowledge for mangle around in a perl package from a java-user and so on On top of that there are around 15k components in the distribution and expecting all maintainers to be able to keep tabs on all packager relations ( to their own or in general ) is ignant or expect them to does so for a single fedora-release rpm after the distribution has been split up again into core ( products ) and extra ( the inferior rest ) where the inevitale outcome is for those products eventually start shipping their own fedora release package... If the PLL had thought though these thing thoroughly through he would have realized that. that's a completly different topic signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why sysrq is limited to only sync command on official fedora kernel?
On Thu, Feb 26, 2015 at 08:51:46AM -0700, Pete Travis wrote: The only time I've needed sysrq reboots in recent memory was while running rawhide and knowingly venturing into uncharted territory. If I'm not the only one, would it make sense to include appropriate sysctl snippets in fedora-release-rawhide ? We could ship /etc/sysctl.d/sysrq-enable.conf.disabled (name up for discussion), and interested users could enable it by renaming the file. Maybe even better to provide it the same in all versions. 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
Fedora 22 | Firefox 35 | Adwaita Dark Theme
Hi folks today i update to F22 Workstation ( fresh install ) and well when the adwaita dark theme is active, the textfield of Firefox 35 have as background color ( white) and the text have the same color. here a example of devel list page firefox + adwaita dark https://ipomoeba.fedorapeople.org/_shots/Scr1.png could be this a bug ? -- 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/26/2015 02:51 PM, Jiri Vanek wrote: 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? As always I'm happy to help improving state of Java in Fedora. Next week I'm on vacation [1], but after I come back I can work on this. Once we agree on requirements and other assumptions then finding optimal solution should be easy. [1] https://apps.fedoraproject.org/calendar/vacation/#m2268 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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
- Original Message - From: Mario Torre neug...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, February 26, 2015 4:59:35 PM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On Tue, 2015-02-24 at 18:22 +0100, Mikolaj Izdebski wrote: On 02/24/2015 05:21 PM, Mario Torre wrote: On Tue, 2015-02-24 at 15:37 +0100, Mikolaj Izdebski wrote: On 02/24/2015 02:15 PM, Jiri Vanek wrote: On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote: I am against official guidelines or policy for legacy JDK packages. I don't think that any such policy is needed and it would only encourage adoption of old packages for which there might be no security updates. Well thats the point - people are calling for them. And wont to maintain them with this risk. I thought that the point of this change proposal was enabling community to maintain legacy JDKs, not encouraging people to package them without good reason or without involvement to truly maintaining them. Packaging older JDKs is *already* possible, so IMHO this change accomplishes nothing but showing people how they can dump old, unmaintained software into Fedora. Well, in this case it would not be un-maintained, the Fedora package would *not* be maintained *by us* (the Red Hat Java Team) indeed, but we are still actively contributing to the upstream software in its various versions. While you as a packager cannot specifically count on that, there's still a level of confidence that the base software won't be abandoned any time soon. And even when we will stop supporting those older versions, the community will take over if there is a need for that, exactly like we have done ourselves before. Indeed, there's an overhead for the downstream maintainers, we may need to drop specific version of OpenJDK, or skip a release, or do other funny things and the Fedora maintainers will have to adapt, but this is no different than usual I believe. Realistically, we are so conservative with older JDKs that I doubt this will ever really be an issue. Correct me if I am wrong, but in my understanding maintaining JDK package requires a lot of ongoing work (including obtaining and applying patches, running TCK, pushing updates in timely manner and so on). JDK maintainers should know this and I'm assuming that the amount of required work is the main reason for them not wanting to maintain older JDKs. The work required to add old JDK package to Fedora is relatively small compared to ongoing maintenance work. Someone willing to truly maintain JDK in Fedora should have knowledge about JDK packaging and they shouldn't have problem finding time to come up with a working solution, proposing and discussing it. Indeed, but don't underestimate this relatively, which is the main reason why *we* won't do that. If you make the process of adding legacy JDKs to Fedora too easy then someone without enough time and required knowledge will surely do that and we may easily end with unmaintained package. I'd rather not have old JDK than have unmaintained JDK with security holes. I don't see how giving proper rules means making something like that easy. The fact is that making things artificially complicated just to scare off people from doing them doesn't really match with my view of Freedom. I think instead that rules, however complex for the matter at hand, should be crafted so that they impose the minimum possible overhead. 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. Package that doesn't pass review shouldn't be part of Fedora. Well, if your goal is to reduce the user base of Fedora, I'm sure we can talk about removing the JDK :) We can't sacrifice our basic principles (such as passing review) for the sake of increasing user base. If you put the mean before the end, yes. But I hope you will agree with me that one of those core principles *is* the Freedom of allowing users to use such a critical tool as Java for their own daily reasons *without* forcing them to switch distribution. While I see your point that this can be extended to anything (why don't we package an older Eclipse?) so we need to draw a line, I believe an important core component like the JDK falls in that category of things that should be allowed to coexist even a bit longer than originally intended. Now, the question is how to make this happens by preserving both quality and freedom. Adding exceptions for selected packages is definitively not the way to go. I
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
- 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. 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 main JDK landed 1. it do '''not''' Obsolate
Minutes from Env-and-Stacks WG meeting (2015-02-26)
==
#fedora-meeting-2: Env and Stacks (2015-02-26)
==
Meeting started by hhorak at 13:02:49 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-2/2015-02-26/env-and-stacks.2015-02-26-13.02.log.html
.
Meeting summary
---
* init process (hhorak, 13:03:21)
* Removing 'scls' from %{_sysconfdir} and %{_localstatedir} (hhorak,
13:07:05)
* LINK:
https://www.redhat.com/archives/sclorg/2015-February/msg00032.html
(hhorak, 13:07:30)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=105#c8
(hhorak, 13:10:27)
* HELP: (hhorak, 13:21:53)
* AGREED: The preferred way for collections in Fedora is to use a
directory under /opt/vendor, which allows to categorize content
from one vendor (e.g. /opt/fedora/scls) (hhorak, 13:30:18)
* AGREED: to use scls for directory for collections rather than scl
(hhorak, 13:40:09)
* Follow-ups: Dockerfiles recommended tips (hhorak, 13:40:52)
* having some docker.fedoraproject.org will be very beneficial
(hhorak, 13:55:01)
* IDEA: content should focus on docker in Fedora and developer
workflow for container based deployments, not that on what is
Docker? (hhorak, 13:55:01)
* IDEA: making DevAssistant fedora-dockerfiles aware would be quite
neat (hhorak, 13:55:30)
Meeting ended at 14:08:47 UTC.
Action Items
Action Items, by person
---
* **UNASSIGNED**
* (none)
People Present (lines said)
---
* phracek (62)
* ncoghlan (58)
* hhorak (46)
* bkabrda1 (30)
* ttomecek (24)
* juhp (22)
* zodbot (4)
* langdon (3)
* ttomecek1 (1)
* bkabrda (0)
* sicampbell (0)
* vpavlin (0)
* walters (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On 02/26/2015 02:10 PM, Reindl Harald wrote: really? why? how do you come to that weird conclusion? surely, one can say not my package, not my problem but that's ignorant and needs no guidelines and policies - sanity should be enough I guess you did not grasp I was referring to the ownership model of components in the distribution which are irrelevant to guidelines and policy's. The fact is the distribution has been using the ownership model since it's interception which means one to one mapping from a component to an individual. As such the thought process of I take care of what I own has been breed into maintainers for the past ten years. There have been several cases where the community has explode due to lack of communications as an result of that with the most notorious of those being the Gnome half of the Red Hat's desktop team where more often than not they have broken bits for other *DE's that have been sharing underlying components in the distribution. ( search this lists archives if you need proof of that ) On top of that there are around 15k components in the distribution and expecting all maintainers to be able to keep tabs on all packager relations ( to their own or in general ) is ignant or expect them to does so for a single fedora-release rpm after the distribution has been split up again into core ( products ) and extra ( the inferior rest ) where the inevitale outcome is for those products eventually start shipping their own fedora release package... If the PLL had thought though these thing thoroughly through he would have realized that. 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
[Bug 1196444] perl-List-Compare-0.48 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1196444 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-List-Compare-0.48-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/perl-List-Compare-0.48-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=ks94C0zhEYa=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 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 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org
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. === 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 ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct:
Re: Why sysrq is limited to only sync command on official fedora kernel?
On Feb 25, 2015 1:50 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 25.02.2015 um 21:38 schrieb Zdenek Kabelac: Dne 25.2.2015 v 18:44 Reindl Harald napsal(a): Am 25.02.2015 um 18:37 schrieb Paul Wouters: On Wed, 25 Feb 2015, Lennart Poettering wrote: Hmm? Syncing is allowed to my knowledge. C-a-d and gdm allow a clean reboot/poweroff. But sysrq does an abnormal reboot/poweroff, which we cannot allow. Similar, remounting read-only is also security senstive, which we cannot allow. Without being logged in there's very little you can do on a host right now, and sysrq should not open up more there by default. You must have forgotten your university days The alternative to not being able to sync-umount-boot using sysrq is to flip the switch. I'd rather have them use sysrq. I said it when they closed X ctrl-alt-backspace and I'll say it now. When you are on console with the power plug, preventing these actions is stupid when you are on a machine where you have pysical only keyboard and mouse it is not - not every PC stands in front of your face - think about kiosk mode and so on... When I read such answers - I always wonder myself - how many kiosk ever run Fedora... It's such a bad idea to optimize Fedora for one-in-milion users and those 999.999 has to suffer instead of require 1 guy to configure more secure version you can be sure that the need for sysrq is the one-in-milion users just because i am a *heavy user* with a lot of setups and used it 4 times in the past 12 years while restricted it to kernel.sysrq = 20 long before the systemd change it's such a bad idea to *not* optimize out-of-the box for security the ones which don't care can disable it, most won't care, nor have a need nor do they even know about a lot of things - this users are also not in the position to fix bad security defaults because they have no idea about it -- The only time I've needed sysrq reboots in recent memory was while running rawhide and knowingly venturing into uncharted territory. If I'm not the only one, would it make sense to include appropriate sysctl snippets in fedora-release-rawhide ? --Pete -- 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 Thu, 26 Feb 2015 15:26:32 +0100 Dan Horák d...@danny.cz wrote: On Thu, 26 Feb 2015 15:11:33 +0100 Ralf Corsepius rc040...@freenet.de wrote: Hi, seems to me as if koji has seized operation: https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log I guess this is the known squid doesn't respond issue. nirik will restart it. Rather it's the known 'squid starts being very slow and failing some builds' so that was me restarting it. Just resubmit for now. I am working on tracking down the problem, but it's proving quite elusive. ;( kevin pgpJS9kq3tI3_.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Geos rebuild needed with gcc5?
On 02/26/2015 04:21 AM, Marcin Juszkiewicz wrote: Hi But in f23 it still failed on geos linking... --- ./.libs/libosm2pgsql.a(geometry-builder.o): In function `geometry_builder::parse_wkt(char const*, osmNode***, int**, int*)': /builddir/build/BUILD/osm2pgsql-0.87.0/geometry-builder.cpp:295: undefined reference to `geos::io::WKTReader::read(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar co nst)' --- Rebuilt geos, updated it in mock and then osm2pgsql 0.87.2 built fine as well. I just kicked off a geos rebuild. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On 02/26/2015 03:49 PM, Reindl Harald wrote: and without the ownership model it would have been prevented what model would you use? you can't only say that model is wrong without any alternative I have already mentioned alternative before no need to repeat that proposal to you. Bottom line that model will not be change due to Red Hat requiring to keep components it ships under its own control. Why do you think the distribution has been split into cores and extra again now through products ? 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: systemd-219 issues with 22 and Rawhide composes
On 02/26/2015 03:58 PM, Reindl Harald wrote: Am 26.02.2015 um 16:54 schrieb Jóhann B. Guðmundsson: On 02/26/2015 03:49 PM, Reindl Harald wrote: and without the ownership model it would have been prevented what model would you use? you can't only say that model is wrong without any alternative I have already mentioned alternative before no need to repeat that proposal to you. Bottom line that model will not be change due to Red Hat requiring to keep components it ships under its own control. you typical Red Hat flame. s/flame/facts Why do you think the distribution has been split into cores and extra again now through products? that is nonsense and you know that! It is not. 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
[Bug 1195991] perl-Tangerine-0.13 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1195991 --- Comment #7 from Fedora Update System upda...@fedoraproject.org --- perl-Tangerine-0.13-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/perl-Tangerine-0.13-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=M4DKPEOuc3a=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:20 PM, Robert Marcano wrote: 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. The legacy jdk have not unvoulenteerly run this regular fedora-java stack code - never. Thats what those rules should achieve. The usage should be for third party development/usage only. J. === 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 ___ devel-announce mailing list
Re: systemd-219 issues with 22 and Rawhide composes
Am 26.02.2015 um 16:54 schrieb Jóhann B. Guðmundsson: On 02/26/2015 03:49 PM, Reindl Harald wrote: and without the ownership model it would have been prevented what model would you use? you can't only say that model is wrong without any alternative I have already mentioned alternative before no need to repeat that proposal to you. Bottom line that model will not be change due to Red Hat requiring to keep components it ships under its own control. you typical Red Hat flame. Why do you think the distribution has been split into cores and extra again now through products? that is nonsense and you know that! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ninja/ninja-build
Without consent from FPC such shift would be problematic. -- 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
[Bug 1196444] perl-List-Compare-0.48 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1196444 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-List-Compare-0.48-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-List-Compare-0.48-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=04F69MOloRa=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 1194265] perl-List-Compare-0.46 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1194265 --- Comment #7 from Fedora Update System upda...@fedoraproject.org --- perl-List-Compare-0.48-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-List-Compare-0.48-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=6Ck57peBvra=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 1195094] perl-List-Compare-0.47 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1195094 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-List-Compare-0.48-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-List-Compare-0.48-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=uJvj2V5Gj6a=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 1190421] perl-List-Compare-0.40 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1190421 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- perl-List-Compare-0.48-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-List-Compare-0.48-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=maHuG2V297a=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 1193419] perl-List-Compare-0.45 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1193419 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-List-Compare-0.48-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-List-Compare-0.48-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=Yvo44kSQ8Ra=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: systemd-219 issues with 22 and Rawhide composes
On Mon, Feb 23, 2015 at 05:13:53PM +0100, Lennart Poettering wrote: Sure I have a stake in systemd, but certainly none in fedora-release.rpm. But even for systemd, there are a number of people Sorry for the somewhat slow reply, but I've been thinking about all of this I guess, primarily, what I'd really hope for is for _all_ Fedora package maintainers to feel like they have a stake in fedora-release.rpm, at least in a symbolic and general sense. As Fedora contributors, we should not just think about individual ownership of the packages we are primarily responsible for, but also how it all fits together. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
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? 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
[perl-strictures] Created tag perl-strictures-2.000000-1.fc22
The lightweight tag 'perl-strictures-2.00-1.fc22' was created pointing to: 5cb191a... Update to 2.00 -- 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: systemd-219 issues with 22 and Rawhide composes
Am 26.02.2015 um 15:05 schrieb Jóhann B. Guðmundsson: On 02/26/2015 01:29 PM, Matthew Miller wrote: On Mon, Feb 23, 2015 at 05:13:53PM +0100, Lennart Poettering wrote: Sure I have a stake in systemd, but certainly none in fedora-release.rpm. But even for systemd, there are a number of people Sorry for the somewhat slow reply, but I've been thinking about all of this I guess, primarily, what I'd really hope for is for _all_ Fedora package maintainers to feel like they have a stake in fedora-release.rpm, at least in a symbolic and general sense. As Fedora contributors, we should not just think about individual ownership of the packages we are primarily responsible for, but also how it all fits together. You will need to change the ownership model of packages in the distribution if you want to change that and related expectations regarding individual ownership. Until you do you should expect others to expect relevant maintainer(s) be responsible for the component they maintain really? why? how do you come to that weird conclusion? surely, one can say not my package, not my problem but that's ignorant and needs no guidelines and policies - sanity should be enough 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
File List-Compare-0.48.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-List-Compare: 533457924eceadae61960a89c4cc6aea List-Compare-0.48.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 1196648] perl-Net-Statsd-Server-0.19 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1196648 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Scratch build succeeded http://koji.fedoraproject.org/koji/taskinfo?taskID=9081105 -- 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=Nvxo4F3IDRa=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
Intend to retire kde-plasma-daisy
Hi there
this is a heads up notice that I intend to retire kde-plasma-daisy, the
reasons being:
- no upstream updates in almost 3 years
- FTBFS in rawhide because there's no kde-workspace{-devel}
- I don't use it myself.
- Repackaging for Plasma 5 would probably require a new package
plasma-daisy (which should not pass review, given upstream is dead), or
a kde5-plasma-daisy subpackage (but then the spec would still FTBFS), or
who knows what. I certainly don't know and don't see any specs to follow.
If anyone would like to take over I'm happy to pass the package on
rather than retire it.
Retirement is planned for rawhide and, possibly also the F22 branch,
depending on what will remain in there kde-wise.
Michael
[1]https://admin.fedoraproject.org/pkgdb/package/kde-plasma-daisy/
--
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: Django 1.8
On Thu, Feb 26, 2015 at 03:15:22PM +0100, Matthias Runge wrote: On Thu, Feb 26, 2015 at 02:20:35PM +0100, Zbigniew Jędrzejewski-Szmek wrote: Strictly speaking[1], I don't need a permission to do so. Still, I would like to ask for opinions here. It will not be pushed until after alpha release unless it gets an exception. [1] https://fedoraproject.org/wiki/Updates_Policy#Pre_Beta See https://fedoraproject.org/wiki/Updates_Policy#Milestone_freezes :) Yeah, but that wouldn't really help in testing this. If I would build it now, and it get's submitted way later, it may be too late in the game to land this feature. It will help with testing. I'd suppose that most poeple who run F22 at this point run with updates-testing enabled. It will not land in the alpha iso, but you don't need that. So yeah, you should just biuld it. 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
GCC5 rebuilds required for sflphone: ccrtp, libzrtpcpp, dbus-c++
Hi, I need ccrtp, libzrtpcpp and dbus-c++ to be rebuilt against GCC5 to get sflphone building [1]. Thanks, Sandro [1] https://kojipkgs.fedoraproject.org//work/tasks/4328/9074328/build.log -- 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: GCC5 rebuilds required for sflphone: ccrtp, libzrtpcpp, dbus-c++
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 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
File strictures-2.000000.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-strictures: 272d98533003581f42cafebfd95bfc5b strictures-2.00.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: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
= 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 -- 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-strictures] Created tag perl-strictures-2.000000-1.fc23
The lightweight tag 'perl-strictures-2.00-1.fc23' was created pointing to: 5cb191a... Update to 2.00 -- 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 1100706] perl-Glib-Object-Introspection-0.028 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1100706 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Glib-Object-Introspect |perl-Glib-Object-Introspect |ion-0.027 is available |ion-0.028 is available --- Comment #5 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 0.028 Current version/release in rawhide: 0.025-1.el7 URL: http://search.cpan.org/dist/Glib-Object-Introspection/ 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=Z1sX5LbNroa=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: request for blockerbugs app to specify primary or secondary
On Wed, 11 Feb 2015 15:53:50 +0100 Tim Flink tfl...@redhat.com wrote: On Mon, 26 Jan 2015 12:27:09 +0100 Dan Horák d...@danny.cz wrote: Hi Tim, I'm replying to your questions from December. yes, the secondary arches follow the same process as primary, they have blocker bugs, etc. Also accepted blockers in secondary should be promoted to Exceptions in primary, it would be nice to have such button in the app for secondaries, but we can workaround it. It Also means that the AcceptedBlocker/... states should be prefixed (or suffixed) with the $arch to distinguish between primary/secondary states. Yeah, I think it's worth talking about what all we'd want to have in a PA/SA unified blocker tracking app (SA blockers showing up as PA FEs, etc.) but that's still going to take some non-trivial re-writing. I'm not against doing it, but it's going to take time. not a problem, the unified blocker app is a RFE and might be even considered as part of the koji 2.0 development For a start we could have own instances for arm/aarch64, ppc and s390, but having a multi-arch blocker app in the future would be nice I think. And if I see correctly, you will be on the DevConf so we can talk about the requirements and options in person there. I think we forgot to get this figured out while at DevConf. I still yeah, the breaks between the talks were too short for finding the needed people in the hallways :-) don't see having multiple arch trackers in the same app happening before F22 but I'm still game for having instances for aarch64, ppc and s390 if that'd be helpful to the secarch folks. We might want to add some visual distinction between the PA and SA instances so there aren't any complaints about secondary doesn't block primary! but that's pretty easy to do and roll up in a new package. have separate apps set for f22 will work well for us, what should be the next step? shall I open a ticket somewhere? Dan Tim Dan On Fri, 28 Nov 2014 10:44:24 +0100 Normand normand at linux.vnet.ibm.com wrote: Hi there, I used the blockerbugs application at https://qa.fedoraproject.org/blockerbugs/propose_bug but found that this is restricted to the primary arch releases. Yeah, it wasn't really designed to handle releases on multiple arches. Could it be possible to have it improved to support secondary arch releases (ppc64, s390, ...) ? I don't think that it could happen in time for F21 but I'm definitely game for figuring out what changes need to happen in order for secondary arches to use the blocker tracking app (either a new instance or supporting multiple arches in the app). Do the secondary arch releases use the same process as primary arch for blockers - tracker bzs for blocker/fe, AcceptedBlocker notation etc.? Tim ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
To Whomever: You Made My Day
Yesterday I was browsing the Fedora pkgdb/git/bohdi pages and this morning I returned to go backwards thru my web browser history when I stumbled upon a real hidden gem for a HTTP 500 response. Our hot dog armed with a ray gun against a nuclear panda... oh man that was great. Best 500 I've seen yet. -- John Florian -- 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: Django 1.8
On Thu, Feb 26, 2015 at 02:20:35PM +0100, Zbigniew Jędrzejewski-Szmek wrote: Strictly speaking[1], I don't need a permission to do so. Still, I would like to ask for opinions here. It will not be pushed until after alpha release unless it gets an exception. [1] https://fedoraproject.org/wiki/Updates_Policy#Pre_Beta See https://fedoraproject.org/wiki/Updates_Policy#Milestone_freezes :) Yeah, but that wouldn't really help in testing this. If I would build it now, and it get's submitted way later, it may be too late in the game to land this feature. Matthias -- Matthias Runge mru...@matthias-runge.de -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
koji is broken
Hi, seems to me as if koji has seized operation: https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log 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: i686 kernel bug priority plan
On Thu, Feb 26, 2015 at 5:43 AM, Jared K. Smith jsm...@fedoraproject.org wrote: On Thu, Feb 26, 2015 at 5:40 AM, drago01 drag...@gmail.com wrote: i686 has nothing to do with ARM. So when someone says i686 he/she means 32bit x86. Well yes -- that's what *I* take it to mean -- I just wanted to make sure that's what everyone else took it to mean as well. I just wanted to make sure that the conversation really was around 32-bit x86 and not 32-bit in general. i686 means i686, not all of 32-bit. I even gave the ARM and other architecture SIGs kudos and thank yous as examples of how I'd like to see i686 support grow earlier in the thread... 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
[perl-List-Compare/f21] 0.48 bump, yet even more performance improvements
Summary of changes: a656988... 0.48 bump, yet even more performance improvements (*) (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-List-Compare/f22] 0.48 bump, yet even more performance improvements
Summary of changes: a656988... 0.48 bump, yet even more performance improvements (*) (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-List-Compare] 0.48 bump, yet even more performance improvements
commit a656988c9cff73970332d6325c7968ff57932da7
Author: Petr Šabata con...@redhat.com
Date: Thu Feb 26 13:44:31 2015 +0100
0.48 bump, yet even more performance improvements
.gitignore | 1 +
perl-List-Compare.spec | 5 -
sources| 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index c317424..7e1e5d8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@ List-Compare-0.37.tar.gz
/List-Compare-0.45.tar.gz
/List-Compare-0.46.tar.gz
/List-Compare-0.47.tar.gz
+/List-Compare-0.48.tar.gz
diff --git a/perl-List-Compare.spec b/perl-List-Compare.spec
index 1512674..bb6847f 100644
--- a/perl-List-Compare.spec
+++ b/perl-List-Compare.spec
@@ -1,5 +1,5 @@
Name: perl-List-Compare
-Version:0.47
+Version:0.48
Release:1%{?dist}
Summary:Compare elements of two or more lists
Group: Development/Libraries
@@ -46,6 +46,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Thu Feb 26 2015 Petr Šabata con...@redhat.com - 0.48-1
+- 0.48 bump, yet even more performance improvements
+
* Mon Feb 23 2015 Petr Šabata con...@redhat.com - 0.47-1
- 0.47 bump, yet more performance improvements
diff --git a/sources b/sources
index f1527f4..00c8ec7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b0103c7d43bd668118dbb065679b1b48 List-Compare-0.47.tar.gz
+533457924eceadae61960a89c4cc6aea List-Compare-0.48.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: F22 System Wide Change: Django 1.8
On Thu, Feb 26, 2015 at 08:04:54AM +0100, Matthias Runge wrote: On Tue, Jan 27, 2015 at 01:33:57PM +0100, Matthias Runge wrote: On 27/01/15 11:51, Miloslav Trmač wrote: Hello, ** A build containing latest Django will be pushed to f22 branch late in dev cycle. If we decide not to push Django-1.8, nothing will be broken. ** Django 1.8 final release is expected around April 1st, 2015: [2] A bit late, yesterday Django-1.8 beta was released. A package is available for rawhide. I would like to push it to f22, too. Strictly speaking[1], I don't need a permission to do so. Still, I would like to ask for opinions here. It will not be pushed until after alpha release unless it gets an exception. [1] https://fedoraproject.org/wiki/Updates_Policy#Pre_Beta See https://fedoraproject.org/wiki/Updates_Policy#Milestone_freezes :) 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
[perl-strictures] Update to 2.000000
commit 5cb191a1c2e99048e41b208425dd19c93b5a8eb7
Author: Paul Howarth p...@city-fan.org
Date: Thu Feb 26 13:58:49 2015 +
Update to 2.00
- New upstream release 2.00
- INCOMPATIBLE CHANGE:
- strictures 2 fatalizes only a subset of warnings; some warning
categories
are not safe to catch, or just inappropriate to have fatal
- Existing code looking like 'use strictures 1;' will continue to get
the
old behavior of fatalizing all errors; the new behavior will take
effect
when no version or version 2 is specified
perl-strictures.spec | 22 +-
sources | 2 +-
2 files changed, 18 insertions(+), 6 deletions(-)
---
diff --git a/perl-strictures.spec b/perl-strictures.spec
index 1c857ae..505b80d 100644
--- a/perl-strictures.spec
+++ b/perl-strictures.spec
@@ -1,9 +1,8 @@
Name: perl-strictures
-Version:1.005006
+Version:2.00
Release:1%{?dist}
Summary:Turn on strict and make all warnings fatal
License:GPL+ or Artistic
-Group: Development/Libraries
URL:http://search.cpan.org/dist/strictures/
Source0:
http://search.cpan.org/CPAN/authors/id/H/HA/HAARG/strictures-%{version}.tar.gz
BuildArch: noarch
@@ -13,6 +12,7 @@ BuildRequires: perl(ExtUtils::CBuilder)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Text::ParseWords)
# Module Runtime
+BuildRequires: perl(Carp)
BuildRequires: perl(strict)
BuildRequires: perl(warnings)
# Test Suite
@@ -23,6 +23,7 @@ BuildRequires: perl(multidimensional)
BuildRequires: perl(bareword::filehandles)
# Runtime
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(Carp)
%description
This package turns on strict and makes all warnings fatal.
@@ -35,9 +36,9 @@ perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-make pure_install DESTDIR=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-%{_fixperms} $RPM_BUILD_ROOT
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+%{_fixperms} %{buildroot}
%check
make test
@@ -45,9 +46,20 @@ make test
%files
%doc Changes README
%{perl_vendorlib}/strictures.pm
+%{perl_vendorlib}/strictures/
%{_mandir}/man3/strictures.3*
+%{_mandir}/man3/strictures::extra.3*
%changelog
+* Thu Feb 26 2015 Paul Howarth p...@city-fan.org - 2.00-1
+- Update to 2.00
+ - INCOMPATIBLE CHANGE:
+- strictures 2 fatalizes only a subset of warnings; some warning categories
+ are not safe to catch, or just inappropriate to have fatal
+- Existing code looking like 'use strictures 1;' will continue to get the
+ old behavior of fatalizing all errors; the new behavior will take effect
+ when no version or version 2 is specified
+
* Sat Jan 31 2015 Paul Howarth p...@city-fan.org - 1.005006-1
- Update to 1.005006
- Fix extra checks triggering on paths starting with t, xt, lib, or blib
diff --git a/sources b/sources
index bbe62c5..cbc9445 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-fb99a23bbd746e9c9bdec9fadacfd882 strictures-1.005006.tar.gz
+272d98533003581f42cafebfd95bfc5b strictures-2.00.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-strictures/f22] Update to 2.000000
Summary of changes: 5cb191a... Update to 2.00 (*) (*) 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
Re: koji is broken
On Thu, 26 Feb 2015 15:11:33 +0100 Ralf Corsepius rc040...@freenet.de wrote: Hi, seems to me as if koji has seized operation: https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log I guess this is the known squid doesn't respond issue. nirik will restart it. Dan -- 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/26/2015 01:29 PM, Matthew Miller wrote: On Mon, Feb 23, 2015 at 05:13:53PM +0100, Lennart Poettering wrote: Sure I have a stake in systemd, but certainly none in fedora-release.rpm. But even for systemd, there are a number of people Sorry for the somewhat slow reply, but I've been thinking about all of this I guess, primarily, what I'd really hope for is for _all_ Fedora package maintainers to feel like they have a stake in fedora-release.rpm, at least in a symbolic and general sense. As Fedora contributors, we should not just think about individual ownership of the packages we are primarily responsible for, but also how it all fits together. You will need to change the ownership model of packages in the distribution if you want to change that and related expectations regarding individual ownership. Until you do you should expect others to expect relevant maintainer(s) be responsible for the component they maintain. 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: To Whomever: You Made My Day
On 02/26/2015 08:31 AM, John Florian wrote: Yesterday I was browsing the Fedora pkgdb/git/bohdi pages and this morning I returned to go backwards thru my web browser history when I stumbled upon a real hidden gem for a HTTP 500 response. Our hot dog armed with a ray gun against a nuclear panda… oh man that was great. Best 500 I’ve seen yet. For the curious :) https://apps.fedoraproject.org/packages/inkscape/sdfgsdgf ~m -- 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: Hardened builds
Jerry James wrote: On Wed, Feb 25, 2015 at 9:53 AM, Rex Dieter rdie...@math.unl.edu wrote: Mamoru TASAKA wrote: Does %undefine _hardened_build help? that version works for me Hmmm, am I doing something wrong? I've tried both: %undefine _hardened_build and: %undefine _hardened_build %global _hardened_build 0 at the top of the spec file, and in both cases, I still see the hardened specs in CFLAGS and LDFLAGS when %configure is invoked. I've got the right spec file inside the mock root. I don't understand why this worked for you and isn't working for me. which package is this again? I can try experimenting a bit. The one that worked for me was lightdm, fwiw. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Package giveaway
I've just made the packages listed below orphan due to my departure from my current employer. Unfortunately I won't be able to invest my personal free time either. fpc: epel7 el6 el5 lazarus: epel7 el6 el5 tuxcmd udisks2 Feel free to pick up any. -- Tomas Bzatek tbza...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: koji is broken
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. Running fedora-packager-setup should take care of it. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: koji is broken
On Thu, Feb 26, 2015 at 10:44 PM, Kevin Fenzi ke...@scrye.com wrote:
On Thu, 26 Feb 2015 17:22:01 +0100
Ralf Corsepius rc040...@freenet.de wrote:
And would you have the kindness to tell me what I can to about it?
I'm not sure. It's some issue with your communication to the koji
hub...
Can you do a:
koji list-tasks --mine
# koji list-tasks --mine
Error: [('SSL routines', 'SSL3_READ_BYTES', 'ssl handshake failure')]
Is your fedora koji cert up to date?
Do:
fedora-cert -v
and if it's expired it should offer to issue you a new one.
Usually however, it would say expired, not handshake failure.
Can you ping koji.fedoraproject.org? browse to it?
Is the time correct on your machine?
I also get the same error. I have update cert. I can ping and browse koji.
Time is correct in the system.
Kushal
--
Fedora Cloud Engineer
CPython Core Developer
Director Python Software Foundation
http://kushaldas.in
--
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 Denis Fateyev de...@fateyev.com changed: What|Removed |Added Flags||fedora-cvs? --- Comment #2 from Denis Fateyev de...@fateyev.com --- Thanks for the review, Petr. New Package SCM Request === Package Name: perl-Tie-Cache Short Description: LRU Cache in memory Owners: dfateyev Branches: f20 f21 f22 el5 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=VVzN7SzNCla=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 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=zmmqqAoCN4a=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
Packages
Hi I would like to give away as many packages as I can to others who are interested. My current job keeps me pretty busy and I have been hanging on to them in hopes of finding the elusive free time that I don't get much of anymore. So if you to be a comaintainer or want to take over anything that I am the point of contact, feel free to drop a request in pkgdb and send me a note off list as well. Thanks for those who have stepped in from time to time. The list of packages is at https://admin.fedoraproject.org/pkgdb/packager/sundaram/ Rahul -- 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/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. 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 -- 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 Thu, 26 Feb 2015 17:22:01 +0100
Ralf Corsepius rc040...@freenet.de wrote:
And would you have the kindness to tell me what I can to about it?
I'm not sure. It's some issue with your communication to the koji
hub...
Can you do a:
koji list-tasks --mine
# koji list-tasks --mine
Error: [('SSL routines', 'SSL3_READ_BYTES', 'ssl handshake failure')]
Is your fedora koji cert up to date?
Do:
fedora-cert -v
and if it's expired it should offer to issue you a new one.
Usually however, it would say expired, not handshake failure.
Can you ping koji.fedoraproject.org? browse to it?
Is the time correct on your machine?
I am working on tracking down the problem, but it's proving quite
elusive. ;(
BTW: Here's another variant of a break down:
https://kojipkgs.fedoraproject.org//work/tasks/1835/9081835/root.log
This time, yum/dnf (whatever currently is being used, I presume
it's yum) is demonstrating one of the yum/dnf issues we discussed
yesterday:
Yum retries to download packages from a mirror it could have know
to be broken, because it failed to connect to it before.
Sure, but then it would have just failed faster as thats the only
mirror thats defined internally for builders.
yum could have tried a different mirror instead of retrying the
already broken one again.
There's no other mirrors for internal builds. It's a baseurl to the
kojipkgs server.
I am considering making another kojipkgs server and making them round
robin in dns. At least with this restarting squid won't break a bunch
of builds.
kevin
pgpYlLr3ukA_X.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1196784] New: perl-CHI: epel7 branch
https://bugzilla.redhat.com/show_bug.cgi?id=1196784 Bug ID: 1196784 Summary: perl-CHI: epel7 branch Product: Fedora Version: rawhide Component: perl-CHI Severity: medium Assignee: rc040...@freenet.de Reporter: de...@fateyev.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, rc040...@freenet.de Please add epel7 branch for perl-CHI module. Thanks. -- 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=vRvmHEMcpma=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
On 02/26/2015 06:14 PM, Kevin Fenzi wrote:
On Thu, 26 Feb 2015 17:22:01 +0100
Ralf Corsepius rc040...@freenet.de wrote:
And would you have the kindness to tell me what I can to about it?
I'm not sure. It's some issue with your communication to the koji
hub...
Meanwhile I rebooted (for unrelated reasons), now the ssl-errors are
gone. So, it have been could be your or my end - No idea.
Can you do a:
koji list-tasks --mine
# koji list-tasks --mine
Error: [('SSL routines', 'SSL3_READ_BYTES', 'ssl handshake failure')]
Is your fedora koji cert up to date?
Yes it is.
Do:
fedora-cert -v
and if it's expired it should offer to issue you a new one.
Usually however, it would say expired, not handshake failure.
Can you ping koji.fedoraproject.org? browse to it?
Is the time correct on your machine?
Yes, yes and yes ... BTW: koji/fedpkg now seems to work again.
I am working on tracking down the problem, but it's proving quite
elusive. ;(
BTW: Here's another variant of a break down:
https://kojipkgs.fedoraproject.org//work/tasks/1835/9081835/root.log
This time, yum/dnf (whatever currently is being used, I presume
it's yum) is demonstrating one of the yum/dnf issues we discussed
yesterday:
Yum retries to download packages from a mirror it could have know
to be broken, because it failed to connect to it before.
Sure, but then it would have just failed faster as thats the only
mirror thats defined internally for builders.
yum could have tried a different mirror instead of retrying the
already broken one again.
There's no other mirrors for internal builds. It's a baseurl to the
kojipkgs server.
Yes, my point is it is X times trying in vain to access a host to
download X packages. Not sure what happens when this happens with a real
mirrorlist/metalink-list, whose top 5 are unreachable/flakey/dead or broken.
I am sure I've seen, yum iterating X times over the same list of broken
mirrors.
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 1196763] Review Request: perl-Tie-Cache - LRU Cache in Memory
https://bugzilla.redhat.com/show_bug.cgi?id=1196763 --- Comment #3 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=sEtACTzEQDa=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: To Whomever: You Made My Day
Sweetness! On Thu, Feb 26, 2015 at 12:37 PM, Máirín Duffy du...@fedoraproject.org wrote: On 02/26/2015 08:31 AM, John Florian wrote: Yesterday I was browsing the Fedora pkgdb/git/bohdi pages and this morning I returned to go backwards thru my web browser history when I stumbled upon a real hidden gem for a HTTP 500 response. Our hot dog armed with a ray gun against a nuclear panda… oh man that was great. Best 500 I’ve seen yet. For the curious :) https://apps.fedoraproject.org/packages/inkscape/sdfgsdgf ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 真実はいつも一つ！/ Always, there's only one truth! -- 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: Packages
Hi Rahul, I wish you all the best in your new job :) I suggest that you add the python-sig as co-maintainers for your python packages. https://admin.fedoraproject.org/pkgdb/packager/group::python-sig/ Regards, H. -- 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 1196784] perl-CHI: epel7 branch
https://bugzilla.redhat.com/show_bug.cgi?id=1196784 --- Comment #1 from Ralf Corsepius rc040...@freenet.de --- (In reply to Denis Fateyev from comment #0) Please add epel7 branch for perl-CHI module. 1. I do not support epel. Feel free to package it for epel7 yourself. 2. Adding perl-CHI to epel will be a challenging task, because perl-CHI has plenty of deps which are not included in EPEL and likely be pretty hard to maintain over the long life time of CentOS/EPEL, because many of the perl dists involved do not care much about backward compatibility. -- 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=5Exi2k35T1a=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
Nick Coghlan ncogh...@gmail.com schrieb am Do., 26. Feb. 2015 um 00:14 Uhr: On 5 February 2015 at 17:48, Nick Coghlan ncogh...@gmail.com wrote: On 4 February 2015 at 21:01, Bohuslav Kabrda bkab...@redhat.com wrote: - Original Message - I don't really feel strongly about this, I agree that your solution has a merit (and syspython *is* better than default_python :)). I think I'll open an FPC ticket to ask FPC for their opinions on this and then I'll start taking concrete steps [1] ;) to get this done. Here's the FPC ticket: https://fedorahosted.org/fpc/ticket/498 In commenting on the ticket, I realised something fundamental: we really do need to keep the RPM macro and the binary symlink in sync. That way the unversioned shebang lines in any packaged scripts can match up with the unversioned macros in the spec file. Which seems to bring the viable options down to just two: * switch the symlink to Python 3 as well (I don't like this due to the impact on end users with custom scripts) * hold off on switching the default for the time being and instead focus on enabling explicitly opting in to Python 3 in EPEL 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 I came back to this question myself due to a couple of different ideas, discussed in https://fedorahosted.org/fpc/ticket/498#comment:19 * How does the situation in Fedora change if the upstream PEP 494 recommendation to downstream Linux distros was to change in conjunction with the Python 3.5 release currently scheduled for September? That release (https://www.python.org/dev/peps/pep-0478/) amongst other things, automatically handles EINTR errors for syscalls, restores binary interpolation support and adds matrix multiplication support and os.scandir(). * With the default interpreter change postponed to Fedora 23, would it make sense to patch the system Python in Fedora 22 to emit Python 3 warnings by default when it was run using the unqualified python reference rather than being run as the qualified python2? And then switch the symlink along with the RPM macros in Fedora 23? Isn't it to late for Fedora 22 to emit such warnings by default? Iiuc, the screen output would change, when using /usr/bin/python, which could possibly break quite some things. So instead of a really badly impact on end users with custom scripts, it might be one? This would ease the transition at least a little, so it _could_ be done... Do you think those warning could be harmfull in Fedora 22? I'm undecided if these warnings could break more things than ease the Python 3 transition. Is changing the recommendation without the warnings an option? Nevertheless, it would be great for Fedora, if the upstream recommendation changes with Python 3.5. This would confirm that the unversioned python can be assumed to be python3 everywhere and Fedora could more easily follow that route. It's also worth noting that the change I am considering to the upstream recommendation would place a qualifier on the distro providing a C.UTF-8 locale, so the C.UTF-8 in upstream glibc RFE (https://sourceware.org/bugzilla/show_bug.cgi?id=17318) would become a key enabler for making the symlink switch in Fedora (associated Fedora RFE: https://bugzilla.redhat.com/show_bug.cgi?id=902094) How does this impact the symlink switch? Unfortunately, that's not clear to me... Am I overlooking something? Regards, Thomas ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Packages
Hi On Thu, Feb 26, 2015 at 2:22 PM, Michael Cronenworth wrote: I will take deluge. FAS: mooninite Done Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[389-devel] Please review ticket 47936: Create a global lock to serialize write operations over several backends
Hello, This fix allows to protect several backends with a global lock during update operations. It is configurable and by default the global lock is not enabled. Under rare condition some plugin may lead to deadlocks. Global lock would be enabled to prevent those deadlocks during critical phases or to limit production impact during investigations. I will do some performance measurement with this fix. https://fedorahosted.org/389/ticket/47936 https://fedorahosted.org/389/attachment/ticket/47936/0001-Ticket-47936-Create-a-global-lock-to-serialize-write.patch thanks thierry -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Packages
On 02/26/2015 01:43 PM, Dave Melia wrote: Are you interested in being a mentor and allow me to assist with Deluge? :) Sure. Apply for commit access. Regards, 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
Re: Packages
Hi On Thu, Feb 26, 2015 at 2:25 PM, Matthias Runge wrote: Congrats to the new job! I'd take * python-kombu * python-gdata * python-billiard Thanks and done. * django-* packages should be all become retired. I have orphaned them since they have EPEL branches. Rahul -- 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: Packages
Hi Michael, Are you interested in being a mentor and allow me to assist with Deluge? :) Regards, Dave On 2015-02-26 19:22, Michael Cronenworth wrote: On 02/26/2015 12:06 PM, Rahul Sundaram wrote: Hi I would like to give away as many packages as I can to others who are interested. My current job keeps me pretty busy and I have been hanging on to them in hopes of finding the elusive free time that I don't get much of anymore. So if you to be a comaintainer or want to take over anything that I am the point of contact, feel free to drop a request in pkgdb and send me a note off list as well. Thanks for those who have stepped in from time to time. I will take deluge. FAS: mooninite Thanks, Michael -- Dave Melia Site : http://www.thinklinux.co.uk Email: d...@thinklinux.co.uk Linkedin : http://uk.linkedin.com/in/davemelia -- 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 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 1040 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 495 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 259 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1626/puppet-2.7.26-1.el5 113 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3784/mantis-1.2.17-3.el5 109 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3849/sblim-sfcb-1.3.8-2.el5 75 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4430/phpMyAdmin4-4.0.10.7-2.el5 61 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4917/dokuwiki-0-0.23.20140929b.el5 17 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0695/drupal7-path_breadcrumbs-3.2-1.el5 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-0717/drupal6-views-2.18-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing dkms-2.2.0.3-30.el5 Details about builds: dkms-2.2.0.3-30.el5 (FEDORA-EPEL-2015-0964) Dynamic Kernel Module Support Framework Update Information: Add which and file requirements. ChangeLog: * Tue Feb 24 2015 Simone Caronni negativ...@gmail.com - 2.2.0.3-30 - Add which and file requirements (#1194652). References: [ 1 ] Bug #1194652 - Missing which and file requirements in dkms package spec file https://bugzilla.redhat.com/show_bug.cgi?id=1194652 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Packages
On 02/26/2015 12:06 PM, Rahul Sundaram wrote: Hi I would like to give away as many packages as I can to others who are interested. My current job keeps me pretty busy and I have been hanging on to them in hopes of finding the elusive free time that I don't get much of anymore. So if you to be a comaintainer or want to take over anything that I am the point of contact, feel free to drop a request in pkgdb and send me a note off list as well. Thanks for those who have stepped in from time to time. I will take deluge. FAS: mooninite Thanks, 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
Re: Packages
On 26/02/15 19:06, Rahul Sundaram wrote: Hi I would like to give away as many packages as I can to others who are interested. My current job keeps me pretty busy and I have been hanging on to them in hopes of finding the elusive free time that I don't get much of anymore. So if you to be a comaintainer or want to take over anything that I am the point of contact, feel free to drop a request in pkgdb and send me a note off list as well. Thanks for those who have stepped in from time to time. The list of packages is at https://admin.fedoraproject.org/pkgdb/packager/sundaram/ Rahul Congrats to the new job! I'd take * python-kombu - which I maintained for the past years * python-gdata - which is a dependency on one or the other of my packages * python-billiard - I looked after that for a longer time * django-* packages should be all become retired. Matthias -- 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 --- Comment #2 from Denis Fateyev de...@fateyev.com --- The author (Michael G Schwern) wrote: Yes, 'same as Perl' means dual Artistic + GPL. This is the text it should have. So we're fine with the existing version. -- 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=PdZ0IRebAxa=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
