Re: aarch64 support bugs obsolete?
On 2013-10-17 04:30, Brendan Conoboy wrote: On 10/16/2013 07:15 PM, Orion Poplawski wrote: If your package uses the %configure macro, I would feel free to close them as either invalid or fixed as that macro handles it. If your package doesn't, you have more checking/work to do. Thanks for replying- this slipped through my inbox. You can also see if your package was built successfully by visiting http://arm-temp.ausil.us/pub/fedora-arm/stage4/http://arm-temp.ausil.us/pub/fedora-arm/stage4/ - If the are rpms in the subdir of your package name, it probably means your package is good to go. The only exception is if there is a .x1 (or x2, x3, x4) in the NVR- in which case we added some patches to make it build. Hm, I get 404 on that URL?! --alec -- 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: aarch64 support bugs obsolete?
On Thu, 17 Oct 2013 08:16:40 +0200 Alec Leamas leamas.a...@gmail.com wrote: Thanks for replying- this slipped through my inbox. You can also see if your package was built successfully by visiting http://arm-temp.ausil.us/pub/fedora-arm/stage4/http://arm-temp.ausil.us/pub/fedora-arm/stage4/ Hm, I get 404 on that URL?! --alec Half it? -- Regards, Frank www.frankly3d.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: aarch64 support bugs obsolete?
On Thu, Oct 17, 2013 at 2:16 PM, Alec Leamas leamas.a...@gmail.com wrote: Hm, I get 404 on that URL?! http://arm-temp.ausil.us/pub/fedora-arm/stage4/ Yours sincerely, Christopher Meng Always playing in Fedora Project 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
Re: F21/F22 System Wide Change: Python 3 as the Default Implementation
- Original Message - On Mon, Oct 14, 2013 at 11:05:52PM -0500, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Mon, 14 Oct 2013 02:19:15 -0400 (EDT) Bohuslav Kabrda bkab...@redhat.com escribió: - Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Thu, 10 Oct 2013 05:35:18 -0400 (EDT) Bohuslav Kabrda bkab...@redhat.com escribió: - Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 09 Oct 2013 14:07:12 +0200 Jaroslav Reznik jrez...@redhat.com wrote: ** Request Koji side tag and encourage packagers to rebuilt their packages with Python 3 there python is not in the minimal build root python-libs is pulled in by deps. So all the koji parts of the change proposal are irrelevant Sorry, I don't see how they're irrelevant. I want the Koji tag so that we can push F22 out with Python 2 in case the switch to Python 3 isn't ready in time - so it's more of a safety mechanism than anything else. you would still need to go undo everything in git and rebuild to make sure that the newest builds got out. the builds separate in koji is the least of the worries. side tags cause many issues, since python is not part of the minimal buildroot and since undoing it all would be a massive amount of work. its not going to be easily undone. there is no reason today that you can build everything with python3 along with python2. I do not see what it would give and i see many problems with a side tag especially if it is long lived. Dennis Maintainer can create private branches in dist-git and not touch master, can't you? I guess it should be up to every maintainer whether he wants to revert dist-git changes in case of no success or he wants to merge to master in case of success. Could you be more specific about the many problems that side tags cause? I'm not Koji expert, so I don't see them. Thanks. you can, but you are not allowed to do offical builds from private branches. you get many issues when you build foo-1.1-3 in the side tag, then the maintainer goes and builds foo-2.0-1 in the main tag, when we merge thinsg back in you end up with all sorts of broken dependencies because you get a mixture of things build against different libraries. you then need to clean up by rebuilding a bunch of things again to clean up dependency issues. I am not saying we shouldn't change here, just saying that if we are going to do it it is one of those things we should just do and deal with the fallout. I for one actually have no plans to port any of my code to python3, and many of the things that I look after need to work on RHEL 5 up. some things will just take longer to get done because the lowest common denominator doesn't have the new shiny. At today's fesco meeting we decided to defer a vote on this until next week. Generally, fesco seemed positively inclined towards the feature but had some concerns that needed to be addressed: * The Change plan should be updated to take into account Dennis's Feedback * I suggeested that perhaps a better contingency plan would be to simply ship with some applications using python2 and others using python3. Personally I don't have problem with this, but: - Side tag is a good contingency plan. If we have to revert for whatever reason, then without sidetag we will have to rebuild everything with Python 2 again. - I recall that someone (I believe it was matthew) pointed out that shipping both Python's would significantly grow cloud images (significantly from cloud POV, I guess). I can't find the email right now, though. * Need to clarify if the DNF bindings will exist for both python2 and python3 or just python3. This could affect releng, mock maintainer, etc. I'll discuss with Ales. -Toshio -- Regards, Bohuslav Slavek Kabrda. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Software management: Call for RFEs results!
Dne 17.10.2013 01:15, Kevin Kofler napsal(a): Vít Ondruch wrote: Sorry, this has nothing to do with FPC yet. RPM/YUM/DNF should first provide reasonable support. For example this issue [1] could take us closer as a first approximation. Vít [1] https://bugzilla.redhat.com/show_bug.cgi?id=845247 Parallel-installing multiple versions of the same package is a flawed idea from the onset, the only package we support it for is the kernel (and that's a hack). I don't think it makes sense to try to support it elsewhere. It would be much more productive to just package the latest version of the library in Fedora (if necessary as an update) and make the client packages work with that (if necessary in a grouped update). Kevin Kofler It is interesting to see such response from somebody who appears to be maintainer of Qt. Don't we ship 3 parallel installable version of Qt? To be honest, the Kernel is the last package, which should be paraller installable, since you can run just one kernel at time. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?
On 10/14/2013 10:27 AM, Michael J Gruber wrote: I'm in rpmfusion's fas, bz and devel-ml now, applied for cvs. [BTW: self-signed cert on fas makes me feel a bit uneasy.] Thanks Michael (and Kevin, who replied off-list, too). Every current (co-)maintainer but Martin have an RPM Fusion account now. Martin, I'm waiting on your account creation in RPM Fusion to request CVS modules for gxine and xine-plugin, all others modules are created. I'll be more than happy to leave the lead to you in all things xine-ui, whether on the fedora or the rpmfusion side. I've the feeling that together with moving xine-lib back to RPM Fusion, I'm somewhat signing to be the maintainer for all the dependant packages as well. I'm not sure I'll be able to give them all the love they need, especially as I'm not using all of them, thus I'm more than happy to have co-maintainers. Also, I've requested commit rights to all the Fedora packages to be able to retire them, so if you want me to handle that, please make sure to grant me permission on them. So far I have only xine-lib, kaffeine and oxine. Missing are xine-ui, gxine and xine-plugin. Regards, Xavier -- 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: Software management: Call for RFEs results!
On 10/17/2013 09:15 AM, Vít Ondruch wrote: Dne 17.10.2013 01:15, Kevin Kofler napsal(a): Vít Ondruch wrote: Sorry, this has nothing to do with FPC yet. RPM/YUM/DNF should first provide reasonable support. For example this issue [1] could take us closer as a first approximation. Vít [1] https://bugzilla.redhat.com/show_bug.cgi?id=845247 Parallel-installing multiple versions of the same package is a flawed idea from the onset, the only package we support it for is the kernel (and that's a hack). I don't think it makes sense to try to support it elsewhere. It would be much more productive to just package the latest version of the library in Fedora (if necessary as an update) and make the client packages work with that (if necessary in a grouped update). Kevin Kofler It is interesting to see such response from somebody who appears to be maintainer of Qt. Don't we ship 3 parallel installable version of Qt? To be honest, the Kernel is the last package, which should be paraller installable, since you can run just one kernel at time. Yeah, admins will love that, when after updating the kernel the machine won't boot with the new one and there is no easy way to switch to the old one... --J. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Automounting of the root partition in the initramfs
All, The (admittedly hacky) dracut-modules-growroot package installs a dracut script that runs in the pre-pivot stage. It unmounts the root partition, extends it to the maximum possible size and then tries to remount it. What I noticed in F20 is that as soon as the repartitioning finishes (its an sfdisk command), something automatically remounts the root partition and the growroot script fails when it tries to mount the already mounted partition. Can somebody shed some light on what is happening and why the root partition is automatically remounted and if I can rely on that and not have the growroot script try to remount it? Thanks ...Juerg Oh, that is systemd, because it generates a unit file from the kernel command line called sysroot.mount, which is required by the following systemd targets. Is there an easy way to wait until this (remounting of root) has happened or do I need to poll and time out? Yes. A unit with Requires=sysroot.mount, After=sysroot.mount will be started only after /sysroot has been mounted. But it looks like the resize script should run *before* the automatic mounting. If the script is made into a Type=oneshot unit, adding Before=sysroot.mount will delay mounting until the unit has finished. I'm not sure though, what's the best way to make sure that it is run after the root device has been detected, unless the root device name is known in advance. If it is, Requires=device.device, After=device.device should be added. Agreed, the script should probably run prior to root being mounted. I'm not familiar with systemd and this is too drastic of a change I want to make at this point. So is it possible for a script to wait until a systemd event has happened? ...Juerg 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 -- 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: LVM thin provisioning and virt-manager
On Wed, Oct 16, 2013 at 03:15:30PM -0600, Chris Murphy wrote: On Oct 16, 2013, at 1:09 PM, Chris Murphy li...@colorremedies.com wrote: I made the suggested cache change for both LVM and qcow2; and created the qcow2 file as suggested (adding lazy_refcount): Fedora 20 default standard partition guided install (ext4) to an LV takes 18m02s. Firstboot systemd-analyze: Reboot, first boot systemd-analyze results: 852ms (kernel) + 1.425s (initrd) + 10.417s (userspace) = 12.695s The same install parameters to qcow2 on XFS takes 17m52s. Firstboot systemd-analyze: 829ms (kernel) + 1.475s (initrd) + 11.693s (userspace) = 13.998s Same unsafe caching and qcow2 '-o preallocation=metadata,compat=1.1,lazy_refcounts=on' as above Fedora 20 default BTRFS guided install to qcow2 on XFS, install time 17m21s. Firstboot systemd-analyze: 874ms (kernel) + 1.558s (initrd) + 12.866s (userspace) = 15.300s The install is a tiny bit faster than the ext4 standard partitions (no LVM) result above, only difference is ext4 vs btrfs. But it's a ton faster than the originally reported btrfs to qcow2 on XFS result of 1h11m. Clearly it wasn't the file system that slowed it down. FWIW this is still /boot on ext4 not on btrfs, so kernel and initrd results are ext4 and userspace is primarily btrfs. It'd be great if virt-manager defaults to using these qcow2 options, short of them causing some sort of problem. I can't tell from the qemu-img info command what options were used to create the file. ^ Cole: Chris reports (and it matches my experience) that using the qemu-img / qcow2 options preallocation=metadata,compat=1.1,lazy_refcounts=on greatly improves write performance of qcow2 disks. This of course requires qemu = 1.1 (and = 1.5 for lazy_refcounts). Is this something which virt-manager should use? I don't see it in the current code, but libvirt supports at least preallocation=metadata lazy_refcounts. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- 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: Software management: Call for RFEs results!
Dne 17.10.2013 10:05, Jiri Moskovcak napsal(a): On 10/17/2013 09:15 AM, Vít Ondruch wrote: To be honest, the Kernel is the last package, which should be paraller installable, since you can run just one kernel at time. Yeah, admins will love that, when after updating the kernel the machine won't boot with the new one and there is no easy way to switch to the old one... --J. This is OT and that was definitely not the point. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: aarch64 support bugs obsolete?
On 2013-10-17 08:18, Frank Murphy wrote: On Thu, 17 Oct 2013 08:16:40 +0200 Alec Leamas leamas.a...@gmail.com wrote: Thanks for replying- this slipped through my inbox. You can also see if your package was built successfully by visiting http://arm-temp.ausil.us/pub/fedora-arm/stage4/http://arm-temp.ausil.us/pub/fedora-arm/stage4/ Hm, I get 404 on that URL?! --alec Half it? blushes --alec -- 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: F21/F22 System Wide Change: Python 3 as the Default Implementation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/17/2013 03:13 AM, Bohuslav Kabrda wrote: Personally I don't have problem with this, but: - Side tag is a good contingency plan. If we have to revert for whatever reason, then without sidetag we will have to rebuild everything with Python 2 again. - I recall that someone (I believe it was matthew) pointed out that shipping both Python's would significantly grow cloud images (significantly from cloud POV, I guess). I can't find the email right now, though. This is a valid point, and it would seem to me that we should then prioritize those components that would end up on the cloud image and try to clear those first. As far as I know, the only thing using python on the cloud image today is yum (please correct me if I'm wrong). * Need to clarify if the DNF bindings will exist for both python2 and python3 or just python3. This could affect releng, mock maintainer, etc. I'll discuss with Ales. -Toshio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJfzFQACgkQeiVVYja6o6PqJgCgoZKv/ZIs3WtitSq1CGT0HZIr jaIAnibwedhW3brfwTgF2PMyrNveGswY =RIXO -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-20 Branched report: 20131017 changes
Compose started at Thu Oct 17 09:15:03 UTC 2013 Broken deps for armhfp -- [blueman] blueman-1.23-7.fc20.armv7hl requires obex-data-server = 0:0.4.3 blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp [bwm-ng] bwm-ng-0.6-11.1.fc20.armv7hl requires libstatgrab.so.9 [cloud-init] cloud-init-0.7.2-7.fc20.noarch requires dmidecode [cobbler] cobbler-2.4.0-2.fc20.noarch requires syslinux [condor-wallaby] condor-wallaby-client-5.0.3-4.fc20.noarch requires python-qmf = 0:0.9.1073306 [fts] fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14 [glpi] glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Version glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Stdlib glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-ServiceManager glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Loader glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-I18n glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache-apc glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache [gnome-do-plugins] gnome-do-plugins-thunderbird-0.8.4-14.fc20.armv7hl requires thunderbird [gofer] ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) = 0:0.16.0 [gradle] gradle-1.0-18.fc20.noarch requires plexus-container-default [grass] grass-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so grass-libs-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so [gtkd] gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 0:2.0.0-29.20120815git9ae9181.fc18 [kawa] 1:kawa-1.11-5.fc19.armv7hl requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0 [monotone] monotone-1.0-11.fc19.armv7hl requires libbotan-1.8.2.so perl-Monotone-1.0-11.fc19.armv7hl requires perl(:MODULE_COMPAT_5.16.2) [mozilla-firetray] mozilla-firetray-thunderbird-0.3.6-0.5.143svn.fc18.1.armv7hl requires thunderbird = 0:11 [msp430-libc] msp430-libc-20120224-2.fc19.noarch requires msp430-gcc = 0:4.6.3 [nifti2dicom] nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10 [nocpulse-common] nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI) [openbox] gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel [openpts] openpts-0.2.6-7.fc20.armv7hl requires tboot [osm2pgsql] osm2pgsql-0.82.0-1.fc20.armv7hl requires libgeos-3.3.8.so [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [oyranos] oyranos-libs-0.4.0-7.fc19.armv7hl requires libraw.so.5 [perl-BerkeleyDB] perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21 [perl-Language-Expr] perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [perl-MIME-Lite-HTML] perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [perl-Padre] perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [pure] pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20 [python-tag] python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0 [rootplot] rootplot-2.2.1-7.fc19.noarch requires root-python [ruby-spqr] ruby-spqr-0.3.6-7.fc20.noarch requires ruby-qpid-qmf [rubygem-audited-activerecord] rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires rubygem(activerecord) 0:4 [rubygem-fog]
Re: Lack of response about sponsorship
On Wed, Oct 16, 2013 at 08:19:11PM -0700, Luya Tshimbalanga wrote: Considering the reporter is also a entrepreneur who took the time to port some of upstream packages to Fedora, I am utterly disappointed by the lack of communication from the sponsors for a simple task. The fact the reporter vainly tried to ask for sponsorship leaves a negative impression as if the communication are uninterested to bring more contributors outside Fedora. I agree; this is a problem. (In general, I think the beg-for-review-swaps system is not friendly to new contributors.) I see that you applied for sponsorship https://fedorahosted.org/packager-sponsors/ticket/90 but there wasn't enough activity on the ticket to make the approval threshold. Maybe something which attracts more activity from sponsors in reviewing new sponsors would help? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21/F22 System Wide Change: Python 3 as the Default Implementation
On Thu, Oct 17, 2013 at 07:39:00AM -0400, Stephen Gallagher wrote: This is a valid point, and it would seem to me that we should then prioritize those components that would end up on the cloud image and try to clear those first. As far as I know, the only thing using python on the cloud image today is yum (please correct me if I'm wrong). cloud-init, as well. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] Fedora 20 Beta Test Compose 5 (TC5) Available Now!
NOTE: The 32- and 64-bit DVDs, the 64-bit LXDE Live, and the 32- and 64-bit Security Spins are over their respective size targets. As per the Fedora 20 schedule [1], Fedora 20 Beta Test Compose 5 (TC5) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5787#comment:8 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha and Beta priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Beta Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. Create Fedora 20 Beta test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/5787 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-20/f-20-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Lack of response about sponsorship
Matthew Miller wrote: On Wed, Oct 16, 2013 at 08:19:11PM -0700, Luya Tshimbalanga wrote: Considering the reporter is also a entrepreneur who took the time to port some of upstream packages to Fedora, I am utterly disappointed by the lack of communication from the sponsors for a simple task. The fact the reporter vainly tried to ask for sponsorship leaves a negative impression as if the communication are uninterested to bring more contributors outside Fedora. I agree; this is a problem. (In general, I think the beg-for-review-swaps system is not friendly to new contributors.) I see that you applied for sponsorship https://fedorahosted.org/packager-sponsors/ticket/90 but there wasn't enough activity on the ticket to make the approval threshold. Indeed, maybe worth pinging some of the folks that didn't vote +1 in that ticket, to help out. karma. :) I could possibly look it over and help with sponsorship, but my free time will be limited at least until this weekend. -- 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
Re: Automounting of the root partition in the initramfs
On Thu, Oct 17, 2013 at 10:32:11AM +0200, Juerg Haefliger wrote: All, The (admittedly hacky) dracut-modules-growroot package installs a dracut script that runs in the pre-pivot stage. It unmounts the root partition, extends it to the maximum possible size and then tries to remount it. What I noticed in F20 is that as soon as the repartitioning finishes (its an sfdisk command), something automatically remounts the root partition and the growroot script fails when it tries to mount the already mounted partition. Can somebody shed some light on what is happening and why the root partition is automatically remounted and if I can rely on that and not have the growroot script try to remount it? Thanks ...Juerg Oh, that is systemd, because it generates a unit file from the kernel command line called sysroot.mount, which is required by the following systemd targets. Is there an easy way to wait until this (remounting of root) has happened or do I need to poll and time out? Yes. A unit with Requires=sysroot.mount, After=sysroot.mount will be started only after /sysroot has been mounted. But it looks like the resize script should run *before* the automatic mounting. If the script is made into a Type=oneshot unit, adding Before=sysroot.mount will delay mounting until the unit has finished. I'm not sure though, what's the best way to make sure that it is run after the root device has been detected, unless the root device name is known in advance. If it is, Requires=device.device, After=device.device should be added. Agreed, the script should probably run prior to root being mounted. I'm not familiar with systemd and this is too drastic of a change I want to make at this point. So is it possible for a script to wait until a systemd event has happened? Well, ordering using Before= and After= is how systemd services are scheduled. There's no fixed order, things that are on the list of things to start are fired as soon as possible, i.e. after dependencies are satisfied. Since dracut uses systemd, I don't think you have a different choice, then to use a unit. I still think that resizing before mounting seems cleaner, but if you want the unit to run after root has been mounted, it is actually simpler to write... Something like that should work: [Unit] Requires=sysroot.mount After=sysroot.mount [Service] ExecStart=... [Install] WantedBy=initrd.target See http://www.freedesktop.org/software/systemd/man/bootup.html for a nice explanation of how this all ties together. 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
systemd no longer creating /var/log/journal?
Back in May, the systemd package was changed to enable journal persistancy by default, by creating /var/log/journal. It appears to no longer do this; at least, it isn't in the cloud images and I don't see anything in the specfile (although there are some commands dealing with the _permissions_ of that file). Since we still have rsyslog as a cloud-init dependency (it's complicated) and are basically planning to resolve that issue as we figure out the separate cloud product, I don't _mind_ not double-logging (even if I think the journal is the better long-term approach, for now I do prefer one or the other), but I wanted to know what's going on here and whether it's intentional. Thanks. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: prelink performance gains
On 10/15/13 at 03:21pm, Daniel P. Berrange wrote: On Tue, Oct 15, 2013 at 10:14:13AM -0400, Paul Wouters wrote: Please take prelink behind the barn and shoot it. Thanks. ... How can we have this discussion? We have had reports of numbers showing no real gain. We know it affects ASLR negatively and complicates FIPS engineering. Why haven't we at least reached a compromise where prelink is _optional_ and not installed per default? It seems currently to be part of the fedora live install (and the rhel workstation installs) This mail is just a pre-cursor to proposing it be removed. When prelink was added by default, the justification was the performance benefits to startup. To justify removing it, we just need to collect data to show that those performance benefits no longer exist, with current hardware and software combination in Fedora. That is what this email thread is seeking to confirm. So assuming no one comes forward to show some incredible benefit(s) of prelink, a proposal to kill it by default will surely follow. I have created a FESCo ticket titled Don't enable prelink by default in Fedora. Please see https://fedorahosted.org/fesco/ticket/1183 URL. -- Dhiru -- 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: Lack of response about sponsorship
On Wed, 16 Oct 2013 20:19:11 -0700, Luya Tshimbalanga wrote: Hello developers and packagers, I recently received an email from the reporter[1] from rhbz #913289. https://bugzilla.redhat.com/show_bug.cgi?id=913289 related to the sponsorship. The review was done. One of sponsors promised to take care of that step which never came to fruition. I cannot find such a promise in the ticket. However, activity log shows that you've assigned the ticket to yourself on 2013-03-14 without being a sponsor. The first submitted package of a new packager must be reviewed and approved by a sponsor. Assigning the ticket could result in other sponsors ignoring the ticket and assuming that somebody _is working_ on it already. The review hasn't been too simple either so far, judging by the number of delays and comments by _several_ people over a period of several months. It has been more than two months the original reporter asked if there is a sponsored packager willing to take over the package. Not too good, because we need more packagers rather than fewer who try to handle a growing number of packages. The way to get sponsored seemed harder because not everybody has the luxury to wait on IRC channel[2]. New contributors have tendency to use mail list so better clarifications are needed. And again, the system doesn't scale if adding packagers doesn't result in more people doing reviews. There are submitters in the needsponsor queue, who wait for a dozen packages without spending any time at all on trying to review them or contributing a few reviews on similar packages in the queue. [2] https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group There are various ways how to get sponsored. Using IRC is not mandatory. Contributing a few reviews is not mandatory either. Performing a self-review of an own package can be helpful, though. Especially if a review request for the package has been opened several weeks/months ago. So, if a reviewer or a sponsor runs into the review request, the package is ready and passes essential tests, such as with rpmlint, mock, fedora-review. I don't think that is too much of a requirement. -- 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: prelink performance gains
On Thu, 17 Oct 2013 00:16:35 +0200, Robert Relyea wrote: prelink throws rocks at a lot of packages that have to check the integrity of the shared libraries they are using. It provides no real useful way of assisting in those tasks, It provides 'prelink -y' only for exactly that purpose. There is a bug in -y; but it does not work in some (rare) cases. https://bugzilla.redhat.com/show_bug.cgi?id=666143 Workaround of that bug is one line of code, it just has not been accepted yet. and we can't meaningfully measure or observe the performance gains. You will need to strongly show the latter, because the cost it forces on other packages is unbearable. Here is another measurement. I do not agree with the initial post's approach as (1) It flushes disk cache. That has no meaning for prelink measurement, it just adds more fuzziness to the results and it is even unreal representation of real world use cases. (2) It runs big end-user GUI application. This adds various interactions with X and the applications has its own heavy startup cost, it all also adds fuzziness to the results. (3) When we look at global GNU/Linux market its end user deployment (*Office) is not relevant, server side execution matters. = It all seems to me as intentionally chosen just to prove prelink gain is not measurable. Therefore I made IMO a more real world measurement with: time gdb/configure Particularly: for i in `seq 1 20`;do git clean -dfx /dev/null;sync;sleep 6;(time ./configure /dev/null) 21|grep ^real|tee -a /tmp/times;done To make clear why such test matters. Running configure scripts has become the major builds bottleneck in recent days as it cannot be parallelized on multicore and multinode machines. For GDB it takes now 56% (of 1m37.380s) of the whole compilation time. And be sure developers are running configure by orders of magnitude more times than *Office (or even LaTeX). without prelink (in seconds): 54.832 54.099 55.122 54.704 54.228 54.728 54.240 53.914 54.878 54.308 54.461 53.859 54.311 53.964 53.958 54.712 54.498 53.924 54.988 54.502 mean 54.4115 | standard deviation 0.39093 with prelink (in seconds): 53.392 52.569 52.549 53.005 52.452 52.719 53.278 52.534 52.439 52.737 52.571 52.656 53.142 52.671 52.555 52.973 52.483 52.369 53.246 53.128 mean 52.7734 | standard deviation 0.31998 mean gain 1.6381 == 3.01% Unfortunately I have to admit that does not mean much. According to Observer Effect and Measurement Bias in Performance Analysis http://www.inf.usi.ch/faculty/hauswirth/publications/CU-CS-1042-08.pdf completely unrelated environment conditions (like object files reorder) cause up to 5% performance measurement bias; please read the PDF for the reasons. - FIPS foot-bullets [..] 1. Some packages supports FIPS on the fly. I do not know the FIPS prelink issues to be able to talk more about it. 2. FIPS isn't the only place you need to do sofware integrity checks. (see rpm). rpm uses prelink -y so it already works in most cases and the rare cases can be fixed in prelink. The problem is its maintainer Jakub has more significant work to do nowadays. If prelink provided noticeable improvement, It depends whether 3% (of configure time); or rather 1.69% of total build time matters or not. If it is relevant for example more expensive i7-4771 is just 3% faster than i7-4770. I would say we put the resources into prelink to make it play more nicely with these integrity systems, but since it doesn't, the more rational approach is have it go away. According to the numbers above my conclusion is different. I agree there remains some work on prelink itself and some packages around to make prelink relevant again for the predominant notebook market nowadays. prelink performance gains [summary] https://lists.fedoraproject.org/pipermail/devel/2013-October/190309.html Thanks, Jan -- 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: Lack of response about sponsorship
On Thu, 17 Oct 2013 15:45:01 +0200 Michael Schwendt mschwe...@gmail.com wrote: On Wed, 16 Oct 2013 20:19:11 -0700, Luya Tshimbalanga wrote: Hello developers and packagers, I recently received an email from the reporter[1] from rhbz #913289. https://bugzilla.redhat.com/show_bug.cgi?id=913289 related to the sponsorship. The review was done. One of sponsors promised to take care of that step which never came to fruition. I cannot find such a promise in the ticket. I think it was me who promised to sponsor Peter. Being fully loaded with other work I waited for seeing the plus set for the review flag. Dan However, activity log shows that you've assigned the ticket to yourself on 2013-03-14 without being a sponsor. The first submitted package of a new packager must be reviewed and approved by a sponsor. Assigning the ticket could result in other sponsors ignoring the ticket and assuming that somebody _is working_ on it already. The review hasn't been too simple either so far, judging by the number of delays and comments by _several_ people over a period of several months. It has been more than two months the original reporter asked if there is a sponsored packager willing to take over the package. Not too good, because we need more packagers rather than fewer who try to handle a growing number of packages. The way to get sponsored seemed harder because not everybody has the luxury to wait on IRC channel[2]. New contributors have tendency to use mail list so better clarifications are needed. And again, the system doesn't scale if adding packagers doesn't result in more people doing reviews. There are submitters in the needsponsor queue, who wait for a dozen packages without spending any time at all on trying to review them or contributing a few reviews on similar packages in the queue. [2] https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group There are various ways how to get sponsored. Using IRC is not mandatory. Contributing a few reviews is not mandatory either. Performing a self-review of an own package can be helpful, though. Especially if a review request for the package has been opened several weeks/months ago. So, if a reviewer or a sponsor runs into the review request, the package is ready and passes essential tests, such as with rpmlint, mock, fedora-review. I don't think that is too much of a requirement. -- 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: some people let packages in f20-updates-candidate
On Thu, 17 Oct 2013 01:50:34 +0100, Sérgio Basto wrote: I know that, but I haven't permissions sergiomb does not have commit access to azureus we need o provenpackager and the question is more how request a Bodhi update to a provenpackager ? First find out _why_ those builds have not been submitted as test-updates. Yes, this is the question. I think people thinks that works like rawhide and don't need to submit the package, it is not the first time that I see packages that are not submitted . Yesterday I found 2 . And this might be a problem . Communicate! Talk to the package owner. At least try to. Negotiate whether you could help with preparing updates in bodhi. There are packagers who enjoy team-work actually. I know that some packagers do scratch-builds before branching something and submitting a normal build job. Based on the existance of a successful build in koji, one cannot assume anything about whether it is ready to become a test-update. -- 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 no longer creating /var/log/journal?
Matthew Miller wrote:
Back in May, the systemd package was changed to enable journal persistancy
by default, by creating /var/log/journal.
that dir should be owned by systemd:
repoquery --whatprovides /var/log/journal
systemd-0:208-2.fc20.x86_64
it is on my f20 box, systemd.spec in master/ branch has proper
creation/ownership too:
%dir %{_localstatedir}/log/journal
Is that folder getting deleted for you somehow?
-- 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
RE: Lack of response about sponsorship
LOL ^_^ I have 7 review requests , 5 of them ready , but no sponsors !!! Date: Wed, 16 Oct 2013 20:19:11 -0700 From: l...@fedoraproject.org To: devel@lists.fedoraproject.org Subject: Lack of response about sponsorship Hello developers and packagers, I recently received an email from the reporter[1] from rhbz #913289. related to the sponsorship. The review was done. One of sponsors promised to take care of that step which never came to fruition. It has been more than two months the original reporter asked if there is a sponsored packager willing to take over the package. Considering the reporter is also a entrepreneur who took the time to port some of upstream packages to Fedora, I am utterly disappointed by the lack of communication from the sponsors for a simple task. The fact the reporter vainly tried to ask for sponsorship leaves a negative impression as if the communication are uninterested to bring more contributors outside Fedora. The way to get sponsored seemed harder because not everybody has the luxury to wait on IRC channel[2]. New contributors have tendency to use mail list so better clarifications are needed. I understand each one of us is busy with their life but a simple message would suffice to let know about the status. Is there a better way to address this concern to avoid repeating it in the future? Ref: [1] https://lists.fedoraproject.org/pipermail/devel/2013-August/187357.html [2] https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group -- Luya Tshimbalanga Graphic Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: prelink performance gains
On 10/17/13 at 03:48pm, Jan Kratochvil wrote: Here is another measurement. I do not agree with the initial post's approach as (1) It flushes disk cache. That has no meaning for prelink measurement, it just adds more fuzziness to the results and it is even unreal representation of real world use cases. (2) It runs big end-user GUI application. This adds various interactions with X and the applications has its own heavy startup cost, it all also adds fuzziness to the results. (3) When we look at global GNU/Linux market its end user deployment (*Office) is not relevant, server side execution matters. = It all seems to me as intentionally chosen just to prove prelink gain is not measurable. Therefore I made IMO a more real world measurement with: time gdb/configure ... kidding Hopefully, you are not building fresh GCC (and other big applications) on your *production* servers. If yes, we need to have a private talk ;) /kidding To make clear why such test matters. Running configure scripts has become the major builds bottleneck in recent days as it cannot be parallelized on multicore and multinode machines. For GDB it takes now 56% (of 1m37.380s) of the whole compilation time. And be sure developers are running configure by orders of magnitude more times than *Office (or even LaTeX). I too face this problem on a regular basis. I guess that a lot of folks will agree that configure just sucks in modern times. Here is my workaround, yum install ccache. It works great for the projects I work on. -- Dhiru -- 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: Software management: Call for RFEs results!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/16/2013 07:15 PM, Kevin Kofler wrote: Vít Ondruch wrote: Sorry, this has nothing to do with FPC yet. RPM/YUM/DNF should first provide reasonable support. For example this issue [1] could take us closer as a first approximation. Vít [1] https://bugzilla.redhat.com/show_bug.cgi?id=845247 Parallel-installing multiple versions of the same package is a flawed idea from the onset, the only package we support it for is the kernel (and that's a hack). I don't think it makes sense to try to support it elsewhere. It would be much more productive to just package the latest version of the library in Fedora (if necessary as an update) and make the client packages work with that (if necessary in a grouped update). This would be nice in a perfect world where all upstreams understand backwards-compatibility and proper API/ABI versioning. Unfortunately, we live in a world where even major players (like Google with v8 or anyone in the Ruby community) break compatibility constantly. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJf8RgACgkQeiVVYja6o6PuaQCfYRWcTHhPAq8Zny4pO1emDg3a f30AoIdIUBJaJ94atD08M38w0vMpvufy =8RDh -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: prelink performance gains
On Thu, 17 Oct 2013, Jan Kratochvil wrote: Workaround of that bug is one line of code, it just has not been accepted yet. And this is the core of the problem. No one has been spending 5 minutes on fixing prelink, yet people have described hours and days of effort wasted because of prelink. If the people who deem prelink useful can't ensure prelink does not cause damage to people with no interest in prelink, the package should go. Therefore I made IMO a more real world measurement with: time gdb/configure Unfortunately I have to admit that does not mean much. I do not know the FIPS prelink issues to be able to talk more about it. rpm uses prelink -y so it already works in most cases and the rare cases can be fixed in prelink. The problem is its maintainer Jakub has more significant work to do nowadays. I agree there remains some work on prelink itself and some packages around to make prelink relevant again I don't mean to pick a fight with you Jan, but you are the only person actively defending prelink right now. When even you reach the above conclusions and cannot put in the time, and the maintainer isn't looking at filed bugs for over a year, the only real answer is to turn prelink into a dead.package for now. Paul -- 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: prelink performance gains
On Thu, Oct 17, 2013 at 7:22 AM, Paul Wouters pwout...@redhat.com wrote: On Thu, 17 Oct 2013, Jan Kratochvil wrote: I agree there remains some work on prelink itself and some packages around to make prelink relevant again I don't mean to pick a fight with you Jan, but you are the only person actively defending prelink right now. When even you reach the above conclusions and cannot put in the time, and the maintainer isn't looking at filed bugs for over a year, the only real answer is to turn prelink into a dead.package for now. There's no reason to kill the package entirely. Some people still want to use it despite the current issues. So just don't install it by default. Reducing everything down to absolutes isn't helpful. 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
File Term-Clui-1.68.tar.gz uploaded to lookaside cache by georgiou
A file has been added to the lookaside cache for perl-Term-Clui: 141541f3cb3167059a064813a3c0dd08 Term-Clui-1.68.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: prelink performance gains
On Thu, 17 Oct 2013 16:28:07 +0200, Josh Boyer wrote: On Thu, Oct 17, 2013 at 7:22 AM, Paul Wouters pwout...@redhat.com wrote: On Thu, 17 Oct 2013, Jan Kratochvil wrote: I agree there remains some work on prelink itself and some packages around to make prelink relevant again I don't mean to pick a fight with you Jan, but you are the only person actively defending prelink right now. When even you reach the above conclusions and cannot put in the time, and the maintainer isn't looking at filed bugs for over a year, the only real answer is to turn prelink into a dead.package for now. There's no reason to kill the package entirely. Some people still want to use it despite the current issues. So just don't install it by default. Reducing everything down to absolutes isn't helpful. This is exactly my opinion which I have already expressed several times in this thread. prelink is useful on some systems (including mine) but I agree it currently does more harm than good for average/default Fedora user. Jan -- 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: prelink performance gains
On Thu, Oct 17, 2013 at 07:28:07AM -0700, Josh Boyer wrote: On Thu, Oct 17, 2013 at 7:22 AM, Paul Wouters pwout...@redhat.com wrote: On Thu, 17 Oct 2013, Jan Kratochvil wrote: I agree there remains some work on prelink itself and some packages around to make prelink relevant again I don't mean to pick a fight with you Jan, but you are the only person actively defending prelink right now. When even you reach the above conclusions and cannot put in the time, and the maintainer isn't looking at filed bugs for over a year, the only real answer is to turn prelink into a dead.package for now. There's no reason to kill the package entirely. Some people still want to use it despite the current issues. So just don't install it by default. Reducing everything down to absolutes isn't helpful. Agreed, there's no reason to kill it entirely. Let people opt-in if they wish to install it later understand the cost/benefit tradeoff. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- 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-Term-Clui] Import spec file
commit 08b167b0c33d6487c0343fb9bb3d2ec7a7bd3caf
Author: Kostas Georgiou georg...@opengamma.com
Date: Thu Oct 17 15:43:56 2013 +0100
Import spec file
.gitignore |1 +
perl-Term-Clui.spec | 67 +++
sources |1 +
3 files changed, 69 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..3e64b4f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Term-Clui-1.68.tar.gz
diff --git a/perl-Term-Clui.spec b/perl-Term-Clui.spec
new file mode 100644
index 000..4d538c9
--- /dev/null
+++ b/perl-Term-Clui.spec
@@ -0,0 +1,67 @@
+Name: perl-Term-Clui
+Version:1.68
+Release:3%{?dist}
+Summary:Perl module offering a Command-Line User Interface
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Term-Clui/
+Source0:
http://www.cpan.org/authors/id/P/PJ/PJB/Term-Clui-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Term::ReadKey)
+BuildRequires: perl(Term::ReadLine::Gnu)
+BuildRequires: perl(Term::Size)
+BuildRequires: perl(Test::Simple)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+Requires: perl(Term::ReadKey)
+Requires: perl(Term::ReadLine::Gnu)
+Requires: perl(Term::Size)
+Requires: perl(strict)
+Requires: perl(warnings)
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+
+%description
+Term::Clui offers a high-level user interface to give the user of command-
+line applications a consistent look and feel. Its metaphor for the
+computer is as a human-like conversation-partner, and as each
+question/response is completed it is summarised onto one line, and remains
+on screen, so that the history of the session gradually accumulates on the
+screen and is available for review, or for cut/paste. This user interface
+can therefore be intermixed with standard applications which write to
+STDOUT or STDERR, such as make, pgp, rcs etc.
+
+%prep
+%setup -q -n Term-Clui-%{version}
+#Don't pull in the examples dependencies
+chmod -x examples/*
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{buildroot}
+
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+
+%{_fixperms} %{buildroot}/*
+
+%check
+make test
+
+%files
+%doc Changes README examples
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Wed Oct 16 2013 Kostas Georgiou georg...@opengamma.com 1.68-3
+- use DESTDIR instead of PERL_INSTALL_ROOT at install
+
+* Wed Oct 16 2013 Kostas Georgiou georg...@opengamma.com 1.68-2
+- Review changes/fixes #1018859.
+
+* Wed Oct 02 2013 Kostas Georgiou georg...@opengamma.com 1.68-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..8814755 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+141541f3cb3167059a064813a3c0dd08 Term-Clui-1.68.tar.gz
--
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-Term-Clui/f20] Import spec file
Summary of changes: 08b167b... Import spec file (*) (*) 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-Term-Clui/f19] Import spec file
Summary of changes: 08b167b... Import spec file (*) (*) 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
Re: prelink performance gains
2013/10/17 Josh Boyer jwbo...@fedoraproject.org On Thu, Oct 17, 2013 at 7:22 AM, Paul Wouters pwout...@redhat.com wrote: On Thu, 17 Oct 2013, Jan Kratochvil wrote: I agree there remains some work on prelink itself and some packages around to make prelink relevant again I don't mean to pick a fight with you Jan, but you are the only person actively defending prelink right now. When even you reach the above conclusions and cannot put in the time, and the maintainer isn't looking at filed bugs for over a year, the only real answer is to turn prelink into a dead.package for now. There's no reason to kill the package entirely. Some people still want to use it despite the current issues. So just don't install it by default. Reducing everything down to absolutes isn't helpful. And if we get this fixed https://bugzilla.redhat.com/show_bug.cgi?id=841434 those who are using prelink can remove it and end up with a sane system -- 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-Term-Clui/f18] Import spec file
Summary of changes: 08b167b... Import spec file (*) (*) 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-Term-Clui/el6] Import spec file
Summary of changes: 08b167b... Import spec file (*) (*) 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
Re: prelink performance gains
On Thu, 17 Oct 2013, Daniel P. Berrange wrote: There's no reason to kill the package entirely. Some people still want to use it despite the current issues. So just don't install it by default. Reducing everything down to absolutes isn't helpful. Agreed, there's no reason to kill it entirely. Let people opt-in if they wish to install it later understand the cost/benefit tradeoff. How do we make it go away on the installs it currently affects badly? Do we add Conflict: to some packages (eg FIPS capable ones) ? Paul -- 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: prelink performance gains
On Thu, Oct 17, 2013 at 10:54:44AM -0400, Paul Wouters wrote: On Thu, 17 Oct 2013, Daniel P. Berrange wrote: There's no reason to kill the package entirely. Some people still want to use it despite the current issues. So just don't install it by default. Reducing everything down to absolutes isn't helpful. Agreed, there's no reason to kill it entirely. Let people opt-in if they wish to install it later understand the cost/benefit tradeoff. How do we make it go away on the installs it currently affects badly? Do we add Conflict: to some packages (eg FIPS capable ones) ? I don't think the downsides are critical enough to play games to force its removal on existing installs being upgraded. Suffice to just not install it on newly provisioned installs. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- 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: prelink performance gains
Hi, On 10/17/2013 04:54 PM, Paul Wouters wrote: On Thu, 17 Oct 2013, Daniel P. Berrange wrote: There's no reason to kill the package entirely. Some people still want to use it despite the current issues. So just don't install it by default. Reducing everything down to absolutes isn't helpful. Agreed, there's no reason to kill it entirely. Let people opt-in if they wish to install it later understand the cost/benefit tradeoff. How do we make it go away on the installs it currently affects badly? Do we add Conflict: to some packages (eg FIPS capable ones) ? We could change the default /etc/sysconfig/prelink to default to no prelinking, then for people with an unmodified /etc/sysconfig/prelink, this will become the new /etc/sysconfig/prelink and the first time the cronjob runs after the update it will unprelink all binaries (and I hope it is smart enough to not run any more after that). Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: prelink performance gains
On Thu, 17 Oct 2013, Hans de Goede wrote: We could change the default /etc/sysconfig/prelink to default to no prelinking, then for people with an unmodified /etc/sysconfig/prelink, this will become the new /etc/sysconfig/prelink and the first time the cronjob runs after the update it will unprelink all binaries (and I hope it is smart enough to not run any more after that). Ah yes. that works. Paul -- 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: prelink performance gains
On Thu, Oct 17, 2013 at 10:54:44AM -0400, Paul Wouters wrote: There's no reason to kill the package entirely. Some people still want to use it despite the current issues. So just don't install it by default. Reducing everything down to absolutes isn't helpful. Agreed, there's no reason to kill it entirely. Let people opt-in if they wish to install it later understand the cost/benefit tradeoff. How do we make it go away on the installs it currently affects badly? Do we add Conflict: to some packages (eg FIPS capable ones) ? If we wanted to do this, changing 'PRELINKING=no' in /etc/sysconfig/prelink in a package update would do it -- the config file is marked as 'noreplace', but if the file hasn't been edited locally, it would be overwritten with the updated one. Then, at the next cron run, prelink would undo the prelinking. I'm not sure if this is the route we should take, or if installation of the package should default to it being active; just putting this out there as an option. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: prelink performance gains
Once upon a time, Josh Boyer jwbo...@fedoraproject.org said: There's no reason to kill the package entirely. Some people still want to use it despite the current issues. So just don't install it by default. Reducing everything down to absolutes isn't helpful. Well, in this case, I think it should be killed. Having prelink in the distribution implies that it is expected that it should, which means that all the other packages that have to support/work-around/etc. prelink still have to have all those hacks. Maintainers would still be expected to fix problems and such. It creates a burden on other packages, just by being in the distribution. If it doesn't appear to provide a significant benefit, and there's no expectation of support (for some meaning of support), it should go away. IMHO this is one of the differences between a distribution and a random collection of packages. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Lack of response about sponsorship
On Thu, 17 Oct 2013 15:56:00 +0200, مصعب الزعبي wrote: LOL ^_^ I have 7 review requests , 5 of them ready , but no sponsors !!! Not true. You've had feedback from a sponsor already, but they are not marked as such in bugzilla, so you don't know that it is a potential sponsor for you. Further, you've submitted the requests no earlier than October. -- 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: F21/F22 System Wide Change: Python 3 as the Default Implementation
On Thu, Oct 17, 2013 at 9:13 AM, Bohuslav Kabrda bkab...@redhat.com wrote: * The Change plan should be updated to take into account Dennis's Feedback * I suggeested that perhaps a better contingency plan would be to simply ship with some applications using python2 and others using python3. Personally I don't have problem with this, but: - Side tag is a good contingency plan. If we have to revert for whatever reason, then without sidetag we will have to rebuild everything with Python 2 again. Yes. In general it would be great to start frequently making disruptive changes on branches to not disrupt other people, and this is a very big change where at least having the option is very much warranted Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: prelink performance gains
On Thu, Oct 17, 2013 at 10:36:42AM -0500, Chris Adams wrote: Well, in this case, I think it should be killed. Having prelink in the distribution implies that it is expected that it should, which means that all the other packages that have to support/work-around/etc. prelink still have to have all those hacks. Maintainers would still be expected to fix problems and such. It creates a burden on other packages, just by being in the distribution. I don't think that is necessarily the case. Or, at least, I think that it shouldn't be the case even if it is currently. We've got thousands of packages in the distribution, and requiring this level of burden for other packages from any package which passes review is a path to madness. If it doesn't appear to provide a significant benefit, and there's no expectation of support (for some meaning of support), it should go away. IMHO this is one of the differences between a distribution and a random collection of packages. We need both (although I'd chose a more positive adjective than 'random'), and a way to draw the line. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [389-devel] fractional replication monitoring proposal
Thanks everyone for your feedback!
Ok I have written an initial fix, and here is how it works and what I am
seeing...
[1] An update comes it and we update the local RUV.
[2] We check this update against the fractional/stripped attrs in each
agmt.
[3] If this update does replicate to at least one agmt, we write a new
attribute to the local ruv (currently call nsds50replruv - we can
improve the names later). If it doesn't replicate to any replicas then
we don't update the new ruv attribute. This all happens at the same
time in write_changelog_and_ruv(). So there is no delay or copying of
useless ruv info, and we write to the local RUV instead of a new RUV in
cn=config(which I had originally proposed).
[4] Here we made an update that is stripped by fractional replication:
Master A:
ldapsearch -h localhost -D cn=dm -w password -b dc=example,dc=com
-xLLL
'((nsuniqueid=---)(objectclass=nstombstone))'
nsds50ruv nsds50replruv
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
nsds50ruv: {replica 1 ldap://localhost.localdomain:389}
52583d81 526003390001
nsds50replruv: {replica 1 ldap://localhost.localdomain:389}
52583d81 5260030d0001
...
Master B
ldapsearch -h localhost -D cn=dm -w password -b dc=example,dc=com
-xLLL -p 2
'((nsuniqueid=---)(objectclass=nstombstone))'
nsds50ruv nsds50replruv
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
nsds50ruv: {replica 1 ldap://localhost.localdomain:389}
52583d81 5260030d0001
nsds50replruv: {replica 1 ldap://localhost.localdomain:389}
52583d81 5260030d0001
...
[5] If we look at the fractional ruv (nsds50replruv) on Master A, it
does correctly line up with the ruv on master B(nsds50ruv).
[6] Then we make an update that does replicate, and now all the ruv's
line up.
Master A
ldapsearch -h localhost -D cn=dm -w password -b dc=example,dc=com
-xLLL
'((nsuniqueid=---)(objectclass=nstombstone))'
nsds50ruv nsds50replruv
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
nsds50ruv: {replica 1 ldap://localhost.localdomain:389}
52583d81 52600791
nsds50replruv: {replica 1 ldap://localhost.localdomain:389}
52583d81 52600791
Master B
ldapsearch -h localhost -D cn=dm -w password -b dc=example,dc=com
-xLLL -p 2
'((nsuniqueid=---)(objectclass=nstombstone))'
nsds50ruv nsds50replruv
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
nsds50ruv: {replica 1 ldap://localhost.localdomain:389}
52583d81 52600791
nsds50replruv: {replica 1 ldap://localhost.localdomain:389}
52583d81 52600791
There are still the same problems with fix, as I mentioned before,
except we're not updating the dse config. Now, I am concerned about the
performance hit of checking to see if a mod gets replicated.
As for the sync question, this fix does change how that behaves, or
how repl-monitor already works. It's either behind(by a certain amount
of time), or in sync. I'm not trying to improve the current repl status
model.
Anyway, I just wanted to see if I could get this working. Comments welcome.
Thanks again,
Mark
On 10/17/2013 05:44 AM, thierry bordaz wrote:
On 10/17/2013 11:06 AM, Ludwig Krispenz wrote:
On 10/17/2013 10:56 AM, thierry bordaz wrote:
On 10/17/2013 10:49 AM, Ludwig Krispenz wrote:
On 10/17/2013 10:15 AM, thierry bordaz wrote:
On 10/16/2013 05:41 PM, Ludwig Krispenz wrote:
On 10/16/2013 05:28 PM, Mark Reynolds wrote:
On 10/16/2013 11:05 AM, Ludwig Krispenz wrote:
On 10/15/2013 10:41 PM, Mark Reynolds wrote:
https://fedorahosted.org/389/ticket/47368
So we run into issues when trying to figure out if replicas
are in synch(if those replicas use fractional replication and
strip mods). What happens is that an update is made on
master A, but due to fractional replication there is no update
made to any replicas. So if you look at the ruv in the
tombstone entry on each server, it would appear they are out
of synch. So using the ruv in the db tombstone is no longer
accurate when using fractional replication.
I'm proposing a new ruv to be stored in the backend replica
entry: e.g. cn=replica,cn=dc=example,dc=com,cn=mapping
tree,cn=config. I'm calling this the replicated ruv. So
whenever we actually send an update to a replica, this ruv
will get updated.
I don't see how this will help, you have an additional info on
waht has been replicated (which is available on the consumer as
well) and you have a max csn, but you don't know if there are
outstanding fractional changes to be sent.
Well you will know on master A what operations get
replicated(this updates the new ruv before sending any changes),
and you can use this ruv to
Re: prelink performance gains
On Thu, Oct 17, 2013 at 5:54 PM, Matthew Miller mat...@fedoraproject.org wrote: If it doesn't appear to provide a significant benefit, and there's no expectation of support (for some meaning of support), it should go away. IMHO this is one of the differences between a distribution and a random collection of packages. We need both (although I'd chose a more positive adjective than 'random'), and a way to draw the line. Users may need both; we are supposedly producing a distribution, i.e. not the other thing. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: LVM thin provisioning and virt-manager
On Oct 16, 2013, at 1:09 PM, Chris Murphy li...@colorremedies.com wrote: Fedora 20 default BTRFS guided install to qcow2 on XFS, install time 17m21s. Firstboot systemd-analyze: 874ms (kernel) + 1.558s (initrd) + 12.866s (userspace) = 15.300s From above, two changes: 1. Use virt-manager to create the qcow2 file; 2. The source ISO is moved to a separate drive, rather than on the same drive as the qcow2 file. Fedora 20 default BTRFS guided install, to qcow2 (vmm default) on XFS, virtio, unsafe cache Install time: 16m44s So whatever options virt-manager is using to create qcow2 files, is either the same as -o preallocation=metadata,compat=1.1,lazy_refcounts=on, or any difference in options isn't making a difference in performance. The 37 second performance difference is probably due to less disk contention from the source ISO being on a separate drive this time around. And if I'm right about all of that, then the overwhelming gain is coming from unsafe cache. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Source file audit - 2013-09-30
On Wed, 16 Oct 2013 22:48:31 -0600 Orion Poplawski or...@cora.nwra.com wrote: Thanks! orion:BADURL:Office%20Open%20XML%201st%20edition%20Part%204%20(PDF).zip:apache-poi False positive? This works for me. Yeah, it downloaded ok too... wonder if the spaces were confusing my script some. Will investigate. orion:BADSOURCE:gdl-0.9.3.tar.gz:gdl Now at 0.9.4, so hopefully okay. orion:BADSOURCE:GE2011.11p1.tar.gz:gridengine orion:BAD_CVS_SOURCE:libcore.c:gridengine Fixed. orion:BADURL:hdf5_1.8.10-patch1-1.debian.tar.gz:hdf5 Updated. Hmm, didn't realize I would need to keep updating this... orion:BADURL:kdesvn-1.6.0.tar.bz2:kdesvn They say they have moved into kde proper, but I can't find a tarball there. orion:BADURL:maven-ant-tasks-2.1.3-src.zip:maven-ant-tasks New url orion:BADURL:mayavi-4.3.0-f8f2c4016cbf9172b0a3a3c132dec7539e9e51c9.tar.gz:Mayavi Made explicit that this is a git snapshot. orion:BADURL:mod_xsendfile-0.12.tar.bz2:mod_xsendfile Worked for me. Getting https://tn123.org/mod_xsendfile/mod_xsendfile-0.12.tar.bz2 to ./mod_xsendfile-0.12.tar.bz2 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total Spent Left Speed 100 9345 100 93450 0 7419 0 0:00:01 0:00:01 --:--:-- 7416 http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20130930/mod_xsendfile-dl.txt Looks like the centos5 machine I used didn't have the cert for it. --2013-09-30 06:23:56-- https://tn123.org/mod_xsendfile/mod_xsendfile-0.12.tar.bz2 Resolving tn123.org... 94.23.160.241, 2001:41d0:2:a921::30 Connecting to tn123.org|94.23.160.241|:443... connected. ERROR: certificate common name `*.tn123.org' doesn't match requested host name `tn123.org'. To connect to tn123.org insecurely, use `--no-check-certificate'. Unable to establish SSL connection. orion:BADURL:oct2spec-1.0.1.tar.gz:oct2spec Hmm, looks like I haven't kept up with fedorahosted.org changes. orion:BADURL:jukka-pcfi-bd245c9.tar.gz:pcfi Works for me orion:BAD_CVS_SOURCE:License:pcfi Looks like this disappeared. orion:BADURL:plplot-5.9.9-svn12530.tar.xz:plplot Updated to new 5.9.10 release orion:BADURL:car_2.0-16.tar.gz:R-car Upstream doesn't keep around old tarballs (yay!). Updated to 2.0-19. orion:BADURL:lmtest_0.9-30.tar.gz:R-lmtest Same - 0.9-32 orion:BADURL:multcomp_1.2-17.tar.gz:R-multcomp Same - 1.3-0 orion:BADURL:mvtnorm_0.9-9994.tar.gz:R-mvtnorm Same - 0.9-9996 orion:BADURL:zoo_1.7-9.tar.gz:R-zoo Same - 1.7-10 I added these to upstream release monitoring to help in the future. Thanks for fixing those. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: prelink performance gains
Chris Adams wrote: Once upon a time, Josh Boyer jwbo...@fedoraproject.org said: There's no reason to kill the package entirely. Some people still want to use it despite the current issues. So just don't install it by default. Reducing everything down to absolutes isn't helpful. Well, in this case, I think it should be killed. The bar for banning software from the distribution is *way* higher than what it takes to remove from installing it by default. Baby steps. -- 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
ntp-4.2.6p5-11.fc19.src.rpm does not rpmbuild...
I need to patch ntp for my uses. But I find that the src rpm will not build on F19. cd . env PATH=/home/bscott/rpmbuild/BUILD/ntp-4.2.6p5/ntpd:/home/bscott/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/sbin:/usr/sbin autogen -L ../include --writable -Tagman1.tpl -bntpd ntpd-opts.def ice-9/psyntax.scm:1259:12: In procedure dobody: ice-9/psyntax.scm:1259:12: Syntax error: /usr/share/autogen/agman1.tpl:187:6: definition in expression context, where definitions are not allowed, in form (define optname-from _^) Scheme evaluation error. AutoGen ABEND-ing in template /usr/share/autogen/agman1.tpl on line 179 Failing Guile command: = = = = = (define opt-arg ) (define dis-name ) (define opt-name ) (define optname-from A-Z_^) (define optname-to a-z--) (if (exist? preserve-case) (begin (define optname-from _^) (define optname-to --) ) ) (if (exist? option-info) (string-append \n.PP\n (get option-info) \n) ) = Is this being worked on or should I report a bug? I'd appreciate know what needs fixing. Barry -- 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: Schedule for Thursday's FPC Meeting (2013-10-17 16:00 UTC)
On Wed, Oct 16, 2013 at 09:51:03PM +0200, Michael Schwendt wrote: On Wed, 16 Oct 2013 15:13:45 -0400, James Antill wrote: If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. Please comment on https://fedorahosted.org/fpc/ticket/336 because a Rename Request depends on it, which is still veto'ed by Ralf. We still don't know what the FPC's point of view is, and the first time you've discussed it in the meeting, there has not been any agreement. A few planned review requests (for related bindings) also depend on it, and currently there is no progress. Today's Meeting Log: https://lists.fedoraproject.org/pipermail/meetingminutes/2013-October/000843.html (Sorry, I forgot to do a #startmeeting at the beginning so no nice zodbot logs today) Topics covered were: #topic https://fedorahosted.org/fpc/ticket/336 Please clarify the General Naming Guidelines for packages #info Use lowercase and turn underscores into dashes unless there's a compelling reason to follow a different upstream convention. PASSED (+1:5, 0:0, -1:0) #topic #352 BLAS and LAPACK packaging https://fedorahosted.org/fpc/ticket/352 - Deferred until spot is around (he won't be here next week either) as he worked on the MPI guidelines and could have some insight into whether we want to duplicate those here. #topic https://fedorahosted.org/fpc/ticket/353 Update autodep filter guidelines to mention changes to rpm in F20+ #info update the https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Private_Libraries guidelines with that description from the ticket and open bugs against the packages providing the macros PASSED (+1:5, 0:0, -1:0) #topic https://fedorahosted.org/fpc/ticket/354 PHP Guildelines small addition #info Php guidelines update passed PASSED (+1:5, 0:0, -1:0) We met last week as well and I failed at sending a note to this list with the logs: http://meetbot.fedoraproject.org/teams/fpc/fpc.2013-10-10-15.59.html = #fedora-meeting-1: fedora packaging committee = Meeting started by spot at 15:59:39 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2013-10-10/fpc.2013-10-10-15.59.log.html . Meeting summary --- * Roll Call (spot, 16:00:05) * Software Collections in Fedora - https://fedorahosted.org/fpc/ticket/339 (spot, 16:04:58) * Minetest - jthread bundle - https://fedorahosted.org/fpc/ticket/347 (spot, 16:07:52) * ACTION: ticket updated with +4 and request for unbundling timeline (spot, 16:13:49) * LangPacks Naming Guideline - https://fedorahosted.org/fpc/ticket/348 (spot, 16:14:17) * LINK: https://fedoraproject.org/wiki/PackagingDrafts/LangPack is the draft (spot, 16:14:43) * ACTION: LangPack2 draft approved (+1:5, 0:0, -1:0) (spot, 16:41:05) * Bundling exception for LINPACK DQRDC2 - https://fedorahosted.org/fpc/ticket/349 (spot, 16:42:13) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1000829 (RemiFedora, 16:47:45) * ACTION: LINPACK DQRDC2 are copylibs, exception approved (+1:5, 0:0, -1:0) (spot, 16:48:47) * Bundled library exception for codimension-parser - https://fedorahosted.org/fpc/ticket/350 (spot, 16:50:37) Meeting ended at 17:02:19 UTC. Action Items * ticket updated with +4 and request for unbundling timeline * LangPack2 draft approved (+1:5, 0:0, -1:0) * LINPACK DQRDC2 are copylibs, exception approved (+1:5, 0:0, -1:0) Action Items, by person --- * **UNASSIGNED** * ticket updated with +4 and request for unbundling timeline * LangPack2 draft approved (+1:5, 0:0, -1:0) * LINPACK DQRDC2 are copylibs, exception approved (+1:5, 0:0, -1:0) People Present (lines said) --- * spot (64) * abadger1999 (34) * RemiFedora (23) * paragan (21) * geppetto2 (20) * limburgher (18) * SmootherFrOgZ (5) * zodbot (4) pgpZ0yNYaTYU6.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: LVM thin provisioning and virt-manager
On Oct 17, 2013, at 10:22 AM, Chris Murphy li...@colorremedies.com wrote: So whatever options virt-manager is using to create qcow2 files, is either the same as -o preallocation=metadata,compat=1.1,lazy_refcounts=on, or any difference in options isn't making a difference in performance. The 37 second performance difference is probably due to less disk contention from the source ISO being on a separate drive this time around. And if I'm right about all of that, then the overwhelming gain is coming from unsafe cache. My original 1h41s result I reported was based on a qcow2 file that I made using qemu-img without metadata preallocation, not the virt-manager UI. So the above assertion that most gain is coming from unsafe cache was premature. Here's the retesting: btrfs partitions default guided to qcow2 (libvirt unsafe cache, virt-manager default qcow2 creation) anaconda.log Running Thread: AnaInstallThread = 15:56:02 anaconda.log Thread Done: AnaConfigurationThread = 16:12:46 00:16:44 btrfs partitions default guided to qcow2 (libvirt unsafe cache, qemu-img qcow2 creation with no options) anaconda.log Running Thread: AnaInstallThread = 17:18:10 anaconda.log Thread Done: AnaConfigurationThread = 17:35:23 00:17:13 That's significantly more justification to suggest most of the gain over the first 1h41m case was overwhelming due to the use of the 'none' cache setting; and qcow2 metadata preallocation is not nearly as significant a factor. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Target Display Mode in Fedora
Is there a way to get in touch with their engineers, or someone who'd know who to talk to? I did try the intel-gfx list, and one person in particular who I was encouraged to contact, but haven't heard back from either. Thanks Message: 1 Date: Tue, 15 Oct 2013 04:15:00 -0400 (EDT) From: David Airlie airl...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Re: Target Display Mode in Fedora Message-ID: 352492266.2282276.138182495.javamail.r...@redhat.com Content-Type: text/plain; charset=utf-8 The iMac and HP Z1 have a bi-directional DisplayPort/Thunderbolt port, which lets them be used as a Display for another computer. Apple calls it Target Display Mode, though HP doesn't seem to have a special name for it. This is really quite useful, I've used an iMac hooked up to a Linux machine at a previous job, and it's awesome to switch between the two machines when you've only got space for one display on the desk. The feature is invoked by a fairly non-standard keyboard combination. Here is a video illustrating what I mean ( http://www.youtube.com/watch?feature=player_detailpagev=Y7_OZgBX8kQ#t=60 ), note how he switches the iMac from being the display for the MacBook to being an iMac again via keyboard shortcut (sort of off-screen). However, this feature is only implemented in OS X and Windows (via HP's My Display application) on the iMac and Z1 respectively. Which means that if, for example, a Z1 has Linux as the primary OS, the Z1 cannot currently be used as a monitor for a laptop or another computer (via Target Display Mode). As far as I've been able to discover, Target Display Mode does not exist under any flavor of Linux. What would it take to support this in Fedora? Is this a Desktop-centric feature for Gnome/KDE/Cinnamon, or is this something that would/should be part of the Linux kernel itself? I don't think it's directly part of a graphics driver (at least on Windows, since HP released My Display as a separate program), but again I'm not sure. You'd have to reverse engineer or ask HP/Apple what they actually do for this to work. then implement that. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
libtool broken in Koji F19 buildroot?
While preparing the buildroot, Koji is saying: DEBUG util.py:266: Error: Package: libtool-2.4.2-16.fc19.x86_64 (build) DEBUG util.py:266: Requires: gcc = 4.8.1 DEBUG util.py:266: Installed: gcc-4.8.2-1.fc19.x86_64 (@build/$releasever) DEBUG util.py:266: gcc = 4.8.2-1.fc19 (Full log: http://kojipkgs.fedoraproject.org//work/tasks/2021/6072021/root.log ) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- 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 751886] CVE-2011-4115 perl-Parallel-ForkManager: insecure temporary file usage
https://bugzilla.redhat.com/show_bug.cgi?id=751886 --- Comment #7 from Tomas Hoger tho...@redhat.com --- It seems the fix is: http://code.google.com/p/perl-parallel-forkmanager/source/detail?r=42011ee Additional related fixes: http://code.google.com/p/perl-parallel-forkmanager/source/detail?r=80a4c5c http://code.google.com/p/perl-parallel-forkmanager/source/detail?r=a89abfb AFAICS, this is affected by the clean up concern mentioned in comment 3, albeit you can argue that apps where parent exists before child should not really expect child to be able to (safely) pass their results back. -- 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=CyifADXjYya=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: libtool broken in Koji F19 buildroot?
On Thu, Oct 17, 2013 at 07:38:59PM +0100, Richard W.M. Jones wrote:
While preparing the buildroot, Koji is saying:
DEBUG util.py:266: Error: Package: libtool-2.4.2-16.fc19.x86_64 (build)
DEBUG util.py:266: Requires: gcc = 4.8.1
DEBUG util.py:266: Installed: gcc-4.8.2-1.fc19.x86_64
(@build/$releasever)
DEBUG util.py:266: gcc = 4.8.2-1.fc19
(Full log:
http://kojipkgs.fedoraproject.org//work/tasks/2021/6072021/root.log )
That is a temporary measure, for the F19 gcc errata I need to rebuild
various packages which unfortunately hardcode hard dependency on gcc
%{version} (gcc-python-plugin, libtool, llvm, dragonegg). I have the first
two built now, third is building, 4th I need ACLs for or wait for the owner
to build. Once that is done, gcc 4.8.2 buildroot override will be expired
again.
Jakub
--
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: libtool broken in Koji F19 buildroot?
On Thu, Oct 17, 2013 at 7:54 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Oct 17, 2013 at 07:38:59PM +0100, Richard W.M. Jones wrote:
While preparing the buildroot, Koji is saying:
DEBUG util.py:266: Error: Package: libtool-2.4.2-16.fc19.x86_64 (build)
DEBUG util.py:266: Requires: gcc = 4.8.1
DEBUG util.py:266: Installed: gcc-4.8.2-1.fc19.x86_64
(@build/$releasever)
DEBUG util.py:266: gcc = 4.8.2-1.fc19
(Full log:
http://kojipkgs.fedoraproject.org//work/tasks/2021/6072021/root.log )
That is a temporary measure, for the F19 gcc errata I need to rebuild
various packages which unfortunately hardcode hard dependency on gcc
%{version} (gcc-python-plugin, libtool, llvm, dragonegg). I have the first
two built now, third is building, 4th I need ACLs for or wait for the owner
to build. Once that is done, gcc 4.8.2 buildroot override will be expired
again.
I or any of the other proven packagers can rebuild any deps if needed
and helpful.
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Parallel-ForkManager-1.05.tar.gz uploaded to lookaside cache by tibbs
A file has been added to the lookaside cache for perl-Parallel-ForkManager: 444958052e525790bf30d96f287072d1 Parallel-ForkManager-1.05.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: LVM thin provisioning and virt-manager
On Wed, Oct 16, 2013 at 10:25:30AM +0100, Richard Jones wrote: qemu-img create -f qcow2 -b backing -o preallocation=metadata,compat=1.1 snapshot Backing file and preallocation cannot be used at the same time This is RHEL6, is behavior different now in Fedora? Other options do not work apparently. But it looks like I could pre-allocate metadata on the backing image. Would that help at all? These numbers sound exiting! -- Later, Lukas lzap Zapletal irc: lzap #theforeman -- 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-Parallel-ForkManager/f20] Update to latest upstream version.
Summary of changes: 695685d... Update to latest upstream version. (*) (*) 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
Re: BEAST to be patched in NSS
On 10/16/2013 08:54 PM, Simo Sorce wrote: On Wed, 2013-10-16 at 19:08 -0700, Elio Maldonado Batiz wrote: Oops, I pasted too much is hard to read. The diff lines that matter are # This patch is currently meant for stable branches -# Patch29: nss-ssl-cbc-random-iv-off-by-default.patch +Patch29: nss-ssl-cbc-random-iv-off-by-default.patch . # activate for stable and beta branches -# %%patch29 -p0 -b .cbcrandomivoff +%patch29 -p0 -b .cbcrandomivoff Has a bug entered on this? https://bugzilla.redhat.com/show_bug.cgi?id=1005611 That is for Firefox. I entered one for nss targeted for f20 - https://bugzilla.redhat.com/show_bug.cgi?id=1020420 I think failure to reply to this bug and other communication attempts on this issue is part of the reason this issue was escalated to Fesco. Also, the notes in the Bodhi update should be very clear and explain that user that, for reasons of compatibility, needs to opt out of the more secure default can do so by setting the environment variable NSS_SSL_CBC_RANDOM_IV=0. ... Packagers can also go and patch their software to opt out if they are sure that's what's needed for all their users. It is not solely in the hand of the users. Good point. Simo. -- 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-Parallel-ForkManager/f19] (3 commits) ...Update to latest upstream version.
Summary of changes: 55cc8dd... Perl 5.18 rebuild (*) 0686f22... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) 695685d... Update to latest upstream version. (*) (*) 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-Parallel-ForkManager/f18] (4 commits) ...Update to latest upstream version.
Summary of changes: 2aa9e0c... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass (*) 55cc8dd... Perl 5.18 rebuild (*) 0686f22... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) 695685d... Update to latest upstream version. (*) (*) 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
Re: LVM thin provisioning and virt-manager
On 10/17/2013 07:09 PM, Chris Murphy wrote: On Oct 17, 2013, at 10:22 AM, Chris Murphy li...@colorremedies.com wrote: So whatever options virt-manager is using to create qcow2 files, is either the same as -o preallocation=metadata,compat=1.1,lazy_refcounts=on, or any difference in options isn't making a difference in performance. The 37 second performance difference is probably due to less disk contention from the source ISO being on a separate drive this time around. And if I'm right about all of that, then the overwhelming gain is coming from unsafe cache. My original 1h41s result I reported was based on a qcow2 file that I made using qemu-img without metadata preallocation, not the virt-manager UI. So the above assertion that most gain is coming from unsafe cache was premature. Here's the retesting: btrfs partitions default guided to qcow2 (libvirt unsafe cache, virt-manager default qcow2 creation) anaconda.log Running Thread: AnaInstallThread = 15:56:02 anaconda.log Thread Done: AnaConfigurationThread = 16:12:46 00:16:44 btrfs partitions default guided to qcow2 (libvirt unsafe cache, qemu-img qcow2 creation with no options) anaconda.log Running Thread: AnaInstallThread = 17:18:10 anaconda.log Thread Done: AnaConfigurationThread = 17:35:23 00:17:13 That's significantly more justification to suggest most of the gain over the first 1h41m case was overwhelming due to the use of the 'none' cache setting; and qcow2 metadata preallocation is not nearly as significant a factor. Yes preallocation=metadata makes a huge difference. I've testing benchmarks here: https://blueprints.launchpad.net/nova/+spec/preallocated-images Note the caveats with backing disk though. thanks, Pádraig. -- 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: Schedule for Thursday's FPC Meeting (2013-10-17 16:00 UTC)
On Thu, 17 Oct 2013 10:43:21 -0700, Toshio Kuratomi wrote: #topic https://fedorahosted.org/fpc/ticket/336 Please clarify the General Naming Guidelines for packages #info Use lowercase and turn underscores into dashes unless there's a compelling reason to follow a different upstream convention. PASSED (+1:5, 0:0, -1:0) Awesome! Thank you very much. To add to the meeting log, yum search … is case-insensitive, and yum install … tries to be helpful when case doesn't match: # yum install sfml|grep -i sfml No package sfml available. * Maybe you meant: SFML Error: Nothing to do And in bugzilla, the new component search completion is also case-insensitive. (previously, the list of components had started with all the upper-case package names) -- 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: LVM thin provisioning and virt-manager
On Oct 17, 2013, at 1:57 PM, Pádraig Brady p...@draigbrady.com wrote: On 10/17/2013 07:09 PM, Chris Murphy wrote: On Oct 17, 2013, at 10:22 AM, Chris Murphy li...@colorremedies.com wrote: So whatever options virt-manager is using to create qcow2 files, is either the same as -o preallocation=metadata,compat=1.1,lazy_refcounts=on, or any difference in options isn't making a difference in performance. The 37 second performance difference is probably due to less disk contention from the source ISO being on a separate drive this time around. And if I'm right about all of that, then the overwhelming gain is coming from unsafe cache. My original 1h41s result I reported was based on a qcow2 file that I made using qemu-img without metadata preallocation, not the virt-manager UI. So the above assertion that most gain is coming from unsafe cache was premature. Here's the retesting: btrfs partitions default guided to qcow2 (libvirt unsafe cache, virt-manager default qcow2 creation) anaconda.log Running Thread: AnaInstallThread = 15:56:02 anaconda.log Thread Done: AnaConfigurationThread = 16:12:46 00:16:44 btrfs partitions default guided to qcow2 (libvirt unsafe cache, qemu-img qcow2 creation with no options) anaconda.log Running Thread: AnaInstallThread = 17:18:10 anaconda.log Thread Done: AnaConfigurationThread = 17:35:23 00:17:13 That's significantly more justification to suggest most of the gain over the first 1h41m case was overwhelming due to the use of the 'none' cache setting; and qcow2 metadata preallocation is not nearly as significant a factor. Yes preallocation=metadata makes a huge difference. I've testing benchmarks here: https://blueprints.launchpad.net/nova/+spec/preallocated-images Note the caveats with backing disk though. The OS install times I'm experiencing don't support that conclusion for all workloads. 17m13s is not hugely different from 16m44s, and that's without preallocation vs preallocation=metadata. However 1h41m vs either of those is hugely different, and that came just between caching none vs unsafe. I haven't tested other caching methods yet. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Target Display Mode in Fedora
Forgot to add, thanks to everyone who's chimed in on this! On Thu, Oct 17, 2013 at 11:30 AM, Chris Rydalch cryda...@gmail.com wrote: Is there a way to get in touch with their engineers, or someone who'd know who to talk to? I did try the intel-gfx list, and one person in particular who I was encouraged to contact, but haven't heard back from either. Thanks Message: 1 Date: Tue, 15 Oct 2013 04:15:00 -0400 (EDT) From: David Airlie airl...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Re: Target Display Mode in Fedora Message-ID: 352492266.2282276.138182495.javamail.r...@redhat.com Content-Type: text/plain; charset=utf-8 The iMac and HP Z1 have a bi-directional DisplayPort/Thunderbolt port, which lets them be used as a Display for another computer. Apple calls it Target Display Mode, though HP doesn't seem to have a special name for it. This is really quite useful, I've used an iMac hooked up to a Linux machine at a previous job, and it's awesome to switch between the two machines when you've only got space for one display on the desk. The feature is invoked by a fairly non-standard keyboard combination. Here is a video illustrating what I mean ( http://www.youtube.com/watch?feature=player_detailpagev=Y7_OZgBX8kQ#t=60 ), note how he switches the iMac from being the display for the MacBook to being an iMac again via keyboard shortcut (sort of off-screen). However, this feature is only implemented in OS X and Windows (via HP's My Display application) on the iMac and Z1 respectively. Which means that if, for example, a Z1 has Linux as the primary OS, the Z1 cannot currently be used as a monitor for a laptop or another computer (via Target Display Mode). As far as I've been able to discover, Target Display Mode does not exist under any flavor of Linux. What would it take to support this in Fedora? Is this a Desktop-centric feature for Gnome/KDE/Cinnamon, or is this something that would/should be part of the Linux kernel itself? I don't think it's directly part of a graphics driver (at least on Windows, since HP released My Display as a separate program), but again I'm not sure. You'd have to reverse engineer or ask HP/Apple what they actually do for this to work. then implement that. Dave. -- 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 Parse-CPAN-Packages-2.38.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Parse-CPAN-Packages: a4a7956f364839b2f69d60af9bf1957c Parse-CPAN-Packages-2.38.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-BerkeleyDB
perl-BerkeleyDB has broken dependencies in the F-20 tree: On x86_64: perl-BerkeleyDB-0.53-1.fc20.x86_64 requires libdb = 0:5.3.21 On i386: perl-BerkeleyDB-0.53-1.fc20.i686 requires libdb = 0:5.3.21 On armhfp: perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the F-20 tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the F-20 tree: On x86_64: perl-PDL-2.4.10-6.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit) On i386: perl-PDL-2.4.10-6.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-MIME-Lite-HTML
perl-MIME-Lite-HTML has broken dependencies in the F-20 tree: On x86_64: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: slic3r
slic3r has broken dependencies in the F-20 tree: On x86_64: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On i386: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On armhfp: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Padre
perl-Padre has broken dependencies in the F-20 tree: On x86_64: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-MIME-Lite-HTML
perl-MIME-Lite-HTML has broken dependencies in the rawhide tree: On x86_64: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: slic3r
slic3r has broken dependencies in the rawhide tree: On x86_64: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On i386: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On armhfp: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 751886] CVE-2011-4115 perl-Parallel-ForkManager: insecure temporary file usage
https://bugzilla.redhat.com/show_bug.cgi?id=751886 Petr Pisar ppi...@redhat.com changed: What|Removed |Added CC||ppi...@redhat.com --- Comment #6 from Petr Pisar ppi...@redhat.com --- Upstream has resolved this issue. According to Gentoo, version 1.02 is fixed http://www.gentoo.org/security/en/glsa/glsa-201310-11.xml. Upstream states version 1.0.0 brings the fix http://cpansearch.perl.org/src/SZABGAB/Parallel-ForkManager-1.05/Changes. Please note that upstream has changed version schema in between, thus 1.02 is equaled to 1.20.0. -- 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=aBj20DNdySa=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 751886] CVE-2011-4115 perl-Parallel-ForkManager: insecure temporary file usage
https://bugzilla.redhat.com/show_bug.cgi?id=751886 --- Comment #8 from Jason Tibbitts ti...@math.uh.edu --- To be honest I had given up hope that upstream would ever reawaken. I'll have a look at the latest 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=141X4we7JTa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Parallel-ForkManager] Update to latest upstream version.
commit 695685de60baa05878e71629d955ba6799bfadbf
Author: Jason Tibbitts ti...@math.uh.edu
Date: Thu Oct 17 14:06:21 2013 -0500
Update to latest upstream version.
.gitignore |1 +
perl-Parallel-ForkManager.spec | 14 +-
sources|2 +-
3 files changed, 11 insertions(+), 6 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index de494b5..2a4f615 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Parallel-ForkManager-0.7.5.tar.gz
/Parallel-ForkManager-0.7.9.tar.gz
+/Parallel-ForkManager-1.05.tar.gz
diff --git a/perl-Parallel-ForkManager.spec b/perl-Parallel-ForkManager.spec
index 0191780..5881a53 100644
--- a/perl-Parallel-ForkManager.spec
+++ b/perl-Parallel-ForkManager.spec
@@ -1,13 +1,13 @@
Name: perl-Parallel-ForkManager
-Version:0.7.9
-Release:9%{?dist}
+Version:1.05
+Release:1%{?dist}
Summary:Simple parallel processing fork manager
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Parallel-ForkManager/
-Source0:
http://search.cpan.org/CPAN/authors/id/D/DL/DLUX/Parallel-ForkManager-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/S/SZ/SZABGAB/Parallel-ForkManager-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::MakeMaker) perl(Test::More) perl(utf8::all)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
@@ -43,11 +43,15 @@ make test
%files
%defattr(-,root,root,-)
-%doc Changes TODO examples/
+%doc Changes examples/
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Thu Oct 17 2013 Jason L Tibbitts III ti...@math.uh.edu - 1.05-1
+- Update to 1.05; new source location, additional build deps. Should fix the
+ longstanding security bug, 751886.
+
* Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.7.9-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 7da011a..648cf37 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b49dbc6fafb697945d33ffbded0009f7 Parallel-ForkManager-0.7.9.tar.gz
+444958052e525790bf30d96f287072d1 Parallel-ForkManager-1.05.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File CPAN-Meta-2.132830.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-CPAN-Meta: 93e8b95fea03835ff18d7b3b4c5267b5 CPAN-Meta-2.132830.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-CPAN-Meta] Update to 2.132830
commit ac9bc54e87dd6057c81cbba632253393f96713c7
Author: Paul Howarth p...@city-fan.org
Date: Thu Oct 17 21:45:47 2013 +0100
Update to 2.132830
- New upstream release 2.132830
- Fixed incorrectly encoded META.yml
- META validation used to allow a scalar value when a list (i.e. array
reference) was required for a field; this has been tightened and
validation will now fail if a scalar value is given
- Installation on Perls 5.12 will uninstall older versions installed
due to being bundled with ExtUtils::MakeMaker
- Updated Makefile.PL logic to support PERL_NO_HIGHLANDER
- Dropped ExtUtils::MakeMaker configure_requires dependency to 6.17
- CPAN::Meta::Prereqs now has a 'merged_requirements' method for combining
requirements across multiple phases and types
- Invalid 'meta-spec' is no longer a fatal error: instead, it will usually
be treated as spec version 1.0 (prior to formalization of the
meta-spec
field); conversion has some heuristics for guessing a version depending
on
other fields if 'meta-spec' is missing or invalid
- Don't need to remove empty directories from the buildroot
.gitignore |1 +
perl-CPAN-Meta.spec | 25 ++---
sources |2 +-
3 files changed, 24 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6fb9122..0a50bf1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -16,3 +16,4 @@ CPAN-Meta-2.102160.tar.gz
/CPAN-Meta-2.120900.tar.gz
/CPAN-Meta-2.120921.tar.gz
/CPAN-Meta-2.132140.tar.gz
+/CPAN-Meta-2.132830.tar.gz
diff --git a/perl-CPAN-Meta.spec b/perl-CPAN-Meta.spec
index 8e021ef..be124d5 100644
--- a/perl-CPAN-Meta.spec
+++ b/perl-CPAN-Meta.spec
@@ -1,6 +1,6 @@
Name: perl-CPAN-Meta
Summary:Distribution metadata for a CPAN dist
-Version:2.132140
+Version:2.132830
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -13,13 +13,15 @@ BuildRequires: perl(Carp)
BuildRequires: perl(CPAN::Meta::Requirements) = 2.121
BuildRequires: perl(CPAN::Meta::YAML) = 0.008
BuildRequires: perl(Data::Dumper)
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.17
BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Find)
BuildRequires: perl(File::Spec)
BuildRequires: perl(File::Spec::Functions)
BuildRequires: perl(File::Temp) = 0.20
BuildRequires: perl(IO::Dir)
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(IPC::Open3)
BuildRequires: perl(JSON::PP) = 2.27200
BuildRequires: perl(List::Util)
BuildRequires: perl(overload)
@@ -56,7 +58,6 @@ make %{?_smp_mflags}
make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
@@ -69,6 +70,24 @@ make test
%{_mandir}/man3/*
%changelog
+* Fri Oct 11 2013 Paul Howarth p...@city-fan.org - 2.132830-1
+- Update to 2.132830
+ - Fixed incorrectly encoded META.yml
+ - META validation used to allow a scalar value when a list (i.e. array
+reference) was required for a field; this has been tightened and
+validation will now fail if a scalar value is given
+ - Installation on Perls 5.12 will uninstall older versions installed
+due to being bundled with ExtUtils::MakeMaker
+ - Updated Makefile.PL logic to support PERL_NO_HIGHLANDER
+ - Dropped ExtUtils::MakeMaker configure_requires dependency to 6.17
+ - CPAN::Meta::Prereqs now has a 'merged_requirements' method for combining
+requirements across multiple phases and types
+ - Invalid 'meta-spec' is no longer a fatal error: instead, it will usually
+be treated as spec version 1.0 (prior to formalization of the meta-spec
+field); conversion has some heuristics for guessing a version depending on
+other fields if 'meta-spec' is missing or invalid
+- Don't need to remove empty directories from the buildroot
+
* Thu Sep 5 2013 Paul Howarth p...@city-fan.org - 2.132140-1
- update to latest upstream version
diff --git a/sources b/sources
index 69a4b45..1a9423d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d9d6011417224298dd39bd7b4fa87dd1 CPAN-Meta-2.132140.tar.gz
+93e8b95fea03835ff18d7b3b4c5267b5 CPAN-Meta-2.132830.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File CPAN-Meta-Check-0.008.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-CPAN-Meta-Check: c39a16ed38cf56d085050893bff52a7c CPAN-Meta-Check-0.008.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-CPAN-Meta] Created tag perl-CPAN-Meta-2.132830-1.fc21
The lightweight tag 'perl-CPAN-Meta-2.132830-1.fc21' was created pointing to: ac9bc54... Update to 2.132830 -- 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-CPAN-Meta-Check] Update to 0.008
commit 84b53c588f58deb44e91704066c39573e324324f
Author: Paul Howarth p...@city-fan.org
Date: Thu Oct 17 21:50:17 2013 +0100
Update to 0.008
- New upstream release 0.008
- Switch to using merged_requirements
- Test Env instead of Carp for version overshoot (CPAN RT#89591)
- Document $incdirs in the right function
perl-CPAN-Meta-Check.spec | 19 ++-
sources |2 +-
2 files changed, 15 insertions(+), 6 deletions(-)
---
diff --git a/perl-CPAN-Meta-Check.spec b/perl-CPAN-Meta-Check.spec
index b014cd7..2eac3ec 100644
--- a/perl-CPAN-Meta-Check.spec
+++ b/perl-CPAN-Meta-Check.spec
@@ -1,7 +1,7 @@
Name: perl-CPAN-Meta-Check
Summary: Verify requirements in a CPAN::Meta object
-Version: 0.007
-Release: 3%{?dist}
+Version: 0.008
+Release: 1%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
URL: https://metacpan.org/release/CPAN-Meta-Check
@@ -10,12 +10,15 @@ BuildArch: noarch
# Build
BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
# Module
-BuildRequires: perl(CPAN::Meta) = 2.120920
-BuildRequires: perl(CPAN::Meta::Requirements) = 2.120920
+BuildRequires: perl(CPAN::Meta::Prereqs) = 2.132830
+BuildRequires: perl(CPAN::Meta::Requirements) = 2.121
BuildRequires: perl(Exporter) = 5.57
BuildRequires: perl(Module::Metadata)
# Test
-BuildRequires: perl(File::Temp)
+BuildRequires: perl(Env)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(IPC::Open3)
BuildRequires: perl(Test::Deep)
BuildRequires: perl(Test::More) = 0.88
# Release tests
@@ -53,6 +56,12 @@ make test RELEASE_TESTING=1
%{_mandir}/man3/CPAN::Meta::Check.3pm*
%changelog
+* Thu Oct 17 2013 Paul Howarth p...@city-fan.org - 0.008-1
+- Update to 0.008
+ - Switch to using merged_requirements
+ - Test Env instead of Carp for version overshoot (CPAN RT#89591)
+ - Document $incdirs in the right function
+
* Wed Sep 4 2013 Paul Howarth p...@city-fan.org - 0.007-3
- Skip the release tests when bootstrapping
diff --git a/sources b/sources
index e384938..ee3e30b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-56f71df79cea8d308a552b3eb996deb0 CPAN-Meta-Check-0.007.tar.gz
+c39a16ed38cf56d085050893bff52a7c CPAN-Meta-Check-0.008.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-CPAN-Meta-Check] Created tag perl-CPAN-Meta-Check-0.008-1.fc21
The lightweight tag 'perl-CPAN-Meta-Check-0.008-1.fc21' was created pointing to: 84b53c5... Update to 0.008 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Mail-IMAPClient-3.34.tar.gz uploaded to lookaside cache by nb
A file has been added to the lookaside cache for perl-Mail-IMAPClient: 163427d32f5fd7f53f1bd8adf1b639f2 Mail-IMAPClient-3.34.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-Mail-IMAPClient] Upgrade to 3.34
commit 99505473d3a7bda0d730ff36dd445acc90635950
Author: Nick Bebout n...@fedoraproject.org
Date: Thu Oct 17 21:00:55 2013 -0500
Upgrade to 3.34
.gitignore|1 +
perl-Mail-IMAPClient.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index fad3fec..c120b19 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ Mail-IMAPClient-3.25.tar.gz
/Mail-IMAPClient-3.31.tar.gz
/Mail-IMAPClient-3.32.tar.gz
/Mail-IMAPClient-3.33.tar.gz
+/Mail-IMAPClient-3.34.tar.gz
diff --git a/perl-Mail-IMAPClient.spec b/perl-Mail-IMAPClient.spec
index b5dd9ae..e06f206 100644
--- a/perl-Mail-IMAPClient.spec
+++ b/perl-Mail-IMAPClient.spec
@@ -1,6 +1,6 @@
Name: perl-Mail-IMAPClient
-Version:3.33
-Release:3%{?dist}
+Version:3.34
+Release:1%{?dist}
Summary:An IMAP Client API
Group: Development/Libraries
License:GPL+ or Artistic
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Thu Oct 17 2013 Nick Bebout n...@fedoraproject.org - 3.34-1
+- Upgrade to 3.34
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 3.33-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index d6a7072..afda7a7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d29c3dce4fdfbe35b847f2bf9002ef83 Mail-IMAPClient-3.33.tar.gz
+163427d32f5fd7f53f1bd8adf1b639f2 Mail-IMAPClient-3.34.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-Mail-IMAPClient/f20] Upgrade to 3.34
Summary of changes: 9950547... Upgrade to 3.34 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mail-IMAPClient/f19] (3 commits) ...Upgrade to 3.34
Summary of changes: f0da96e... Perl 5.18 rebuild (*) fa12ada... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) 9950547... Upgrade to 3.34 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mail-IMAPClient/f18] (3 commits) ...Upgrade to 3.34
Summary of changes: f0da96e... Perl 5.18 rebuild (*) fa12ada... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) 9950547... Upgrade to 3.34 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mail-IMAPClient/el6] (4 commits) ...Merge branch 'master' into el6
Summary of changes: f0da96e... Perl 5.18 rebuild (*) fa12ada... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) 9950547... Upgrade to 3.34 (*) 1486cf9... Merge branch 'master' into el6 (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mail-IMAPClient/el6: 4/4] Merge branch 'master' into el6
commit 1486cf9d770c9580a20b45e34efbd6b2f00b4153 Merge: 927f8d0 9950547 Author: Nick Bebout n...@fedoraproject.org Date: Thu Oct 17 21:07:17 2013 -0500 Merge branch 'master' into el6 .gitignore|1 + perl-Mail-IMAPClient.spec | 11 ++- sources |2 +- 3 files changed, 12 insertions(+), 2 deletions(-) --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [389-devel] fractional replication monitoring proposal
On 10/16/2013 05:41 PM, Ludwig Krispenz wrote: On 10/16/2013 05:28 PM, Mark Reynolds wrote: On 10/16/2013 11:05 AM, Ludwig Krispenz wrote: On 10/15/2013 10:41 PM, Mark Reynolds wrote: https://fedorahosted.org/389/ticket/47368 So we run into issues when trying to figure out if replicas are in synch(if those replicas use fractional replication and strip mods). What happens is that an update is made on master A, but due to fractional replication there is no update made to any replicas. So if you look at the ruv in the tombstone entry on each server, it would appear they are out of synch. So using the ruv in the db tombstone is no longer accurate when using fractional replication. I'm proposing a new ruv to be stored in the backend replica entry: e.g. cn=replica,cn=dc=example,dc=com,cn=mapping tree,cn=config. I'm calling this the replicated ruv. So whenever we actually send an update to a replica, this ruv will get updated. I don't see how this will help, you have an additional info on waht has been replicated (which is available on the consumer as well) and you have a max csn, but you don't know if there are outstanding fractional changes to be sent. Well you will know on master A what operations get replicated(this updates the new ruv before sending any changes), and you can use this ruv to compare against the other master B's ruv(in its replication agreement). Maybe I am missing your point? MY point is that the question is, what is NOT yet replicated. Without fractional replication you have states of the ruv on all servers, and if ruv(A) ruv(B) you know there are updates missing on B. With fractional, if (ruv(A) ruv(B) this might be ok or not. If you keep an additional ruv on A when sending updates to be, you can only record what ws sent or attempted to send, but not what still has to be sent I agree with you Ludwig, but unless I missed something would not be enough to know that the replica B is late or in sync ? For example, we have updates U1 U2 U3 and U4. U3 should be skipped by fractional replication. replica RUV (tombstone) on master_A contains U4 and master_B replica RUV contains U1. Let's assume that as initial value of the replicated ruv on master_A we have U1. Starting a replication session, master_A should send U2 and update the replicated ruv to U2. If the update is successfully applied on master_B, master_B replica ruv is U2 and monitoring the two ruv shoud show they are in sync. If the update is not applierd, master_B replica ruv stays at U1 and the two ruv will show out of sync. In the first case, we have a transient status of 'in sync' because the replica agreement will evaluate U3 then U4 then send U4 and store it into the replicated ruv. At this point master_A and master_B will appear out of sync until master_B will apply U4. If U4 was to be skipped by fractional we have master_B ruv and Master_A replicated ruv both showing U2 and that is correct both servers are in sync. Mark instead of storing the replicated ruv in the replica, would not be possible to store it into the replica agreement (one replicated ruv per RA). So that it can solve the problem of different fractional replication policy ? Do you mean changes that have not been read from the changelog yet? My plan was to update the new ruv in perform_operation() - right after all the stripping has been done and there is something to replicate. We need to have a ruv for replicated operations. I guess there are other scenarios I didn't think of, like if replication is in a backoff state, and valid changes are coming in. Maybe, we could do test stripping earlier in the replication process(when writing to the changelog?), and then update the new ruv there instead of waiting until we try and send the changes. Since we can not compare this replicated ruv to the replicas tombstone ruv, we can instead compare the replicated ruv to the ruv in the replica's repl agreement(unless it is a dedicated consumer - here we might be able to still look at the db tombstone ruv to determine the status). Problems with this approach: - All the servers need to have the same replication configuration(the same fractional replication policy and attribute stripping) to give accurate results. - If one replica has an agreement that does NOT filter the updates, but has agreements that do filter updates, then we can not correctly determine its synchronization state with the fractional replicas. - Performance hit from updating another ruv(in cn=config)? Fractional replication simply breaks our monitoring process. I'm not sure, not without updating the repl protocol, that we can cover all deployment scenarios(mixed fractional repl agmts, etc). However, I think this approach would work for most deployments(compared to none at the moment). For IPA, since they don't use consumers, this approach would work for them. And finally, all of this would have to be handled
Re: [389-devel] fractional replication monitoring proposal
On 10/17/2013 10:56 AM, thierry bordaz wrote: On 10/17/2013 10:49 AM, Ludwig Krispenz wrote: On 10/17/2013 10:15 AM, thierry bordaz wrote: On 10/16/2013 05:41 PM, Ludwig Krispenz wrote: On 10/16/2013 05:28 PM, Mark Reynolds wrote: On 10/16/2013 11:05 AM, Ludwig Krispenz wrote: On 10/15/2013 10:41 PM, Mark Reynolds wrote: https://fedorahosted.org/389/ticket/47368 So we run into issues when trying to figure out if replicas are in synch(if those replicas use fractional replication and strip mods). What happens is that an update is made on master A, but due to fractional replication there is no update made to any replicas. So if you look at the ruv in the tombstone entry on each server, it would appear they are out of synch. So using the ruv in the db tombstone is no longer accurate when using fractional replication. I'm proposing a new ruv to be stored in the backend replica entry: e.g. cn=replica,cn=dc=example,dc=com,cn=mapping tree,cn=config. I'm calling this the replicated ruv. So whenever we actually send an update to a replica, this ruv will get updated. I don't see how this will help, you have an additional info on waht has been replicated (which is available on the consumer as well) and you have a max csn, but you don't know if there are outstanding fractional changes to be sent. Well you will know on master A what operations get replicated(this updates the new ruv before sending any changes), and you can use this ruv to compare against the other master B's ruv(in its replication agreement). Maybe I am missing your point? MY point is that the question is, what is NOT yet replicated. Without fractional replication you have states of the ruv on all servers, and if ruv(A) ruv(B) you know there are updates missing on B. With fractional, if (ruv(A) ruv(B) this might be ok or not. If you keep an additional ruv on A when sending updates to be, you can only record what ws sent or attempted to send, but not what still has to be sent I agree with you Ludwig, but unless I missed something would not be enough to know that the replica B is late or in sync ? For example, we have updates U1 U2 U3 and U4. U3 should be skipped by fractional replication. replica RUV (tombstone) on master_A contains U4 and master_B replica RUV contains U1. Let's assume that as initial value of the replicated ruv on master_A we have U1. Starting a replication session, master_A should send U2 and update the replicated ruv to U2. If the update is successfully applied on master_B, master_B replica ruv is U2 and monitoring the two ruv shoud show they are in sync. They are not, since U4 is not yet replicated, in master_A you see the normal ruv as U4 and the replicated ruv as U2, but you don't know how many changes are between U2 and U4 an if any of them should be replicated, the replicated ruv is more or less a local copy of the remote ruv Yes I agree they are not this is a transient status. Transient because the RA will continue going through the changelog until it hits U4. At this point it will write U4 in the replicated RUV and until master_B will apply U4 both server will appear out of sync. My understanding is that this replicated RUV only says it is in sync or not, but does not address how far a server is out of sync from the other (how many updates are missing). When you say it is more or less a copy, it is exactly what it is. If it is a copy = in sync, if it different = out of sync. maybe we need to define what in sync means. For me in sync means both servers have the same set of updates applied. Forget fractional for a moment, if we have standard replication and master A is at U4 and master B is at U2, we say they are not in sync - or not ? You could keep a replicated ruv for thos as well, but this wouldn't change things. If the update is not applierd, master_B replica ruv stays at U1 and the two ruv will show out of sync. In the first case, we have a transient status of 'in sync' because the replica agreement will evaluate U3 then U4 then send U4 and store it into the replicated ruv. At this point master_A and master_B will appear out of sync until master_B will apply U4. If U4 was to be skipped by fractional we have master_B ruv and Master_A replicated ruv both showing U2 and that is correct both servers are in sync. Mark instead of storing the replicated ruv in the replica, would not be possible to store it into the replica agreement (one replicated ruv per RA). So that it can solve the problem of different fractional replication policy ? Do you mean changes that have not been read from the changelog yet? My plan was to update the new ruv in perform_operation() - right after all the stripping has been done and there is something to replicate. We need to have a ruv for replicated operations. I guess there are other scenarios I didn't think of, like if replication is in a backoff state, and valid changes are coming in. Maybe, we
[389-devel] Please review: Ticket-47477-Cannot-restart-SSL-admin-server-from-console
https://fedorahosted.org/389/ticket/47477 https://fedorahosted.org/389/attachment/ticket/47477/0001-Ticket-47477-Cannot-restart-SSL-admin-server-from-co.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
