[Test-Announce] 2013-05-06 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2013-05-06 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again today/tomorrow! We'll check in on the status of Beta, and jreznik also wanted to consider the question of what we should about critical issues in secondary arches during freezes. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20130506 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 19 Beta status/planning 3. Secondary arch freeze exceptions 4. Test Days 5. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2013-05-06 @ 16:00 UTC - F19 Beta Blocker Bug Review #3
# F19 Beta Blocker Review meeting #3 # Date: 2013-05-06 # Time: 16:00 UTC (12:00 EDT, 09:00 PDT) (after QA meeting) # Location: #fedora-blocker-review on irc.freenode.net The third blocker review meeting for F19 Beta will follow right after the QA meeting. We have quite a few proposed blockers to knock off, so please come out and help us review them! We'll be running through the Beta blockers and freeze exception bugs. The current list is available at: http://qa.fedoraproject.org/blockerbugs/milestone/19/beta/buglist We'll be reviewing the bugs to determine ... 1. Whether they meet the Beta release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria For guidance on Blocker and FreezeException bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process For the blocker review meeting protocol, see - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FYI: F20 Feature: Migrate to Bluez5
Heya, In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices. Bluez5 uses a D-Bus API that's not compatible with Bluez4[1] and as such, management applications and a number of libraries and daemons will need to be ported. For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages. Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers. Cheers [1]: http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/ and http://lwn.net/Articles/531133/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F19 DVD over size - what to drop?
On 05/04/2013 08:03 AM, Chris Adams wrote: Once upon a time, Mike Pinkerton pseli...@mindspring.com said: On 3 May 2013, at 15:07, Chris Adams wrote: Once upon a time, Mike Pinkerton pseli...@mindspring.com said: Does anaconda check package signatures for the netinstall? I believe so. Checksums are definately checked (RPM won't install a corrupt package). Are you sure that signatures are checked? If so, why this feature? I thought that feature had been implemented, but the status page only shows 5%. The in-package checksums (along similar lines to the DVD media check) are checked, but not the signatures. However, unless your installer image is signed, checking RPM signatures in anaconda is pointless (which is why the feature you mentioned is based on Secure Boot). Unfortunately, Secure Boot does not help here. I already explained why Secure Boot is unusable for boot image verification: http://lists.fedoraproject.org/pipermail/devel/2013-January/176051.html Just because something is signed doesn't mean that it's harmless to run. Creating a complete chain of trust is hard. It's relatively easy to avoid trust in the Internet and the Fedora mirror network. It's not entirely trivial because we'd need overrides (or ways to inject key material) for additional repositories added with Kickstart. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self introduction, and maintaining MySQL package
On Fri, 03 May 2013 16:06:36 +0200, James Hogarth james.hoga...@gmail.com wrote: Please log this in the package review. Let's proceed with the rest of the review and look at renaming as a separate issue later. The current maintainers of community-mysql stated that their preference was to wait for F20 for community-msql 5.6 a couple of weeks back given that we are well past Feature Freeze, Branch, Alpha and only a few days off the Translation Deadline... If the renaming is to be left as a separate issue then what specifically is left for F19? The current maintainers have stated that they don't intend to maintain the package much longer, and we've volunteered to maintain it. Exactly how and when a transition of maintainership is done is still not decided, but please at least review our first package submission. We've been open about the intention to upgrade to 5.6 for months, but have respectfully waited to submit since the change of default has been difficult enough without introducing yet another variable into the equation. Now that the dust has settled and we seem to have a default selection that works, it's time to upgrade. I see review requests on the list for new packages that people want into F19, so I don't see how it could be too late for upgrading an existing package. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Avoid a 32 bits package from being pushed into 64 bits repository
Hi, On 01/05/13 12:24, Michael Schwendt wrote: On Tue, 30 Apr 2013 12:47:24 +0200, Alejandro Alvarez Ayllon wrote: Hello, I co-maintain a package that contains a library that is used as module for a server. The 32 bits version of this library is pushed automatically into the 64 bits repositories (i.e. in epel6), That's because of the multilib compose strategy, which allows for [either] building or running 32-bit software with 64-bit installations and added 32-bit system libs. One basic strategy is to add to the target repo the arch-compatible -devel packages and their base package dependencies. which doesn't make much sense, since the 64 bits version of the server won't run with the 32 bits libraries. ?? The 64-bit version of the server depends on the 64-bit libs, doesn't it? Some details about the problem are missing here. What I want to say is that there is no 32 bits server, so a 32 bits plug-in will be useless. The server does _not_ depend on our plugin. Our plug-in depends on the server. This wouldn't be a big problem, but the pushed 32 bits rpm has a dependency on the 32 bits server, so then I will get complains (with reason) about the broken package. What exactly is the error? Is it caused by automatic dependencies or by manually added (or missing) %_isa dependencies? Manually added %_isa globus-gridftp-server-progs is the server, and dpm-dsi is the module. globus-gridftp-server is the base %name in case anyone searches for it. The dpm-dsi packaging is a bit questionable, because it creates a separate -devel package for only two tiny C header files. The base package contains a *.so plug-in lib. One could have included the two headers in the base package (with a virtual -devel package). The two headers include other headers which are missing. A missing Requires on another -devel package? [Note that I haven't checked what sort of API these two headers define and how it relates to the plug-in lib in the base package. Sometimes plug-in authors publish a private/internal interface, and for a long time -- or forever ;) -- nothing uses it.] Now you mention it, I am checking with the developer what's the potential use case for those headers, as they seem internal to me. If there is none, I'll remove the -devel. If there is, I'll add the missing deps. So my question is: how should I approach this? I got some suggestions in this ticket https://bugzilla.redhat.com/show_bug.cgi?id=957588 Is there any way I can prevent this rpm from being copied into the 64 bits repositories? Typically, I can comment on dependency problems (including multilib related ones) provided that I know the exact scenario. That is either a detailed broken deps report or a yum update scenario. I've not found such details. The Broken dependencies report I have been getting for a while now: dpm-dsi has broken dependencies in the epel-6 tree: On x86_64: dpm-dsi-1.9.0-2.el6.i686 requires globus-gridftp-server-progs(x86-32) Please resolve this as soon as possible. Cheers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI: F20 Feature: Migrate to Bluez5
On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera bnoc...@redhat.com wrote: Heya, In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices. Bluez5 uses a D-Bus API that's not compatible with Bluez4[1] and as such, management applications and a number of libraries and daemons will need to be ported. For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages. Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers. Any analysis to what packages are affected, how many are yet to support the new API and how hard it will be for them to be ported over. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI: F20 Feature: Migrate to Bluez5
On 05/06/2013 11:13 AM, Peter Robinson wrote: On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera bnoc...@redhat.com wrote: For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages. Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers. Any analysis to what packages are affected, how many are yet to support the new API and how hard it will be for them to be ported over. Impact on KDE? -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI: F20 Feature: Migrate to Bluez5
On Mon, May 6, 2013 at 11:38 AM, Roberto Ragusa m...@robertoragusa.it wrote: Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers. Impact on KDE? Probably not much as the upstream developers are already planning Bluez5 integration. -- -- Cheers, Rajeesh http://rajeeshknambiar.wordpress.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI: F20 Feature: Migrate to Bluez5
On Mon, May 6, 2013 at 10:38 AM, Roberto Ragusa m...@robertoragusa.it wrote: On 05/06/2013 11:13 AM, Peter Robinson wrote: On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera bnoc...@redhat.com wrote: For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages. Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers. Any analysis to what packages are affected, how many are yet to support the new API and how hard it will be for them to be ported over. Impact on KDE? No all packages that depend on bluez. It's usual for large potential breakages for the person pushing for the changes to give some overview etc. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130506 changes
Compose started at Mon May 6 08:15:03 UTC 2013 Broken deps for x86_64 -- [byzanz] byzanz-0.3-0.5.fc17.x86_64 requires libpanel-applet-4.so.0()(64bit) [cinnamon] cinnamon-menu-editor-1.6.7-7.fc19.noarch requires gnome-panel [dogtag-pki] dogtag-pki-10.0.2-1.fc20.noarch requires pki-console = 0:10.0.2 [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [eclipse-jbosstools] eclipse-jbosstools-as-4.0.0-1.fc19.noarch requires osgi(org.eclipse.jst.servlet.ui) eclipse-jbosstools-cdi-4.0.0-1.fc19.noarch requires osgi(org.eclipse.jst.servlet.ui) [ekiga] ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit) [fcitx-libpinyin] fcitx-libpinyin-0.2.90-1.fc20.x86_64 requires libpinyin.so.3(LIBPINYIN)(64bit) fcitx-libpinyin-0.2.90-1.fc20.x86_64 requires libpinyin.so.3()(64bit) [glabels] glabels-3.0.1-7.fc20.x86_64 requires libedata-book-1.2.so.17()(64bit) [gnome-applet-sensors] gnome-applet-sensors-3.0.0-4.fc18.i686 requires libpanel-applet-4.so.0 gnome-applet-sensors-3.0.0-4.fc18.x86_64 requires libpanel-applet-4.so.0()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [kdevelop-custom-buildsystem] kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires libkdevplatformutil.so.6()(64bit) kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires libkdevplatformproject.so.6()(64bit) kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires libkdevplatformoutputview.so.6()(64bit) kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires libkdevplatformlanguage.so.6()(64bit) kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires libkdevplatforminterfaces.so.6()(64bit) [lancet] lancet-1.0.1-6.fc19.noarch requires ant-nodeps = 0:1.7.1 [libguestfs] 1:libguestfs-1.21.36-2.fc20.i686 requires libbtrfs.so.0 1:libguestfs-1.21.36-2.fc20.x86_64 requires libbtrfs.so.0()(64bit) [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [libvirt-qmf] libvirt-qmf-0.3.0-6.fc19.x86_64 requires libmcommon_qmf.so.1.0.0()(64bit) libvirt-qmf-0.3.0-6.fc19.x86_64 requires libmcommon.so.1.0.0()(64bit) [mapserver] php-mapserver-6.0.3-9.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapserver-6.0.3-9.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [matreshka] matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-mofext-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-mofext-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-ocl-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-ocl-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-uml-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-uml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-utp-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-utp-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnarl-4.7.so matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnarl-4.7.so()(64bit) matreshka-sql-core-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-core-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-postgresql-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-postgresql-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-sqlite-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-sqlite-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-xml-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-xml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) [ooo2gd] ooo2gd-3.0.0-6.fc19.x86_64 requires gdata-java [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [pagekite] pagekite-0.5.5a-3.fc20.noarch requires python-SocksipyChain [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools]
Re: Do you think this is a security risk and if not is it a bad UI decision?
On 05/04/2013 06:22 PM, Dan Mashal wrote: On Sat, May 4, 2013 at 2:37 AM, Michael Scherer m...@zarb.org wrote: I can add to that that I have seen more than once people setting a password which was not the one they believed due to : - keyboard layout ( ie, qwerty vs azerty in France ) - small usage difference with Windows way, again on azerty keyboard ( people using capslock on french keyboard to type numbers while they should use shift, as capslock just type capital letter like À or É and not 0 or 2, and if you do not understand, just look on the web to compare how different it is from qwerty-based keyboard ) The installer should detect the keyboard automatically. In fact you can even tell it what type of keyboard you have on the first screen. On the screen where you can pick your keyboard, do we have a test area where the user can verify the keyboard layout? Or maybe if you select a different keyboard it should automatically pop up a verify keyboard screen? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On 05/03/2013 04:08 PM, Reartes Guillermo wrote: I think that the previous behaviour was better. (covering the password with bullets). what if the password IS 12 bullet characters :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-SOAP-Lite/f19] Fix sending a large object
Summary of changes: 9369e07... Fix sending a large object (*) (*) 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
F-19 Branched report: 20130506 changes
Compose started at Mon May 6 09:15:02 UTC 2013 Broken deps for x86_64 -- [byzanz] byzanz-0.3-0.5.fc17.x86_64 requires libpanel-applet-4.so.0()(64bit) [cinnamon] cinnamon-menu-editor-1.6.7-7.fc19.noarch requires gnome-panel [deltacloud-core] deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [fcitx-libpinyin] fcitx-libpinyin-0.2.90-1.fc19.x86_64 requires libpinyin.so.3(LIBPINYIN)(64bit) fcitx-libpinyin-0.2.90-1.fc19.x86_64 requires libpinyin.so.3()(64bit) [freeipa] freeipa-server-strict-3.2.0-0.3.beta1.fc19.x86_64 requires pki-ca = 0:10.0.1 freeipa-server-strict-3.2.0-0.3.beta1.fc19.x86_64 requires krb5-server = 0:1.11.2-1 [ghc-data-memocombinators] ghc-data-memocombinators-0.4.4-3.fc19.x86_64 requires libHSdata-inttrie-0.0.8-ghc7.4.2.so()(64bit) ghc-data-memocombinators-0.4.4-3.fc19.x86_64 requires ghc(data-inttrie-0.0.8-1cc0f43b566911f823287ed46100a81e) ghc-data-memocombinators-devel-0.4.4-3.fc19.x86_64 requires ghc-devel(data-inttrie-0.0.8-1cc0f43b566911f823287ed46100a81e) [ghc-show] ghc-show-0.4.1.2-4.fc19.x86_64 requires libHSsmallcheck-0.6.1-ghc7.4.2.so()(64bit) ghc-show-0.4.1.2-4.fc19.x86_64 requires ghc(smallcheck-0.6.1-909159f2996454c279da80ced02cfe48) ghc-show-devel-0.4.1.2-4.fc19.x86_64 requires ghc-devel(smallcheck-0.6.1-909159f2996454c279da80ced02cfe48) [gnome-applet-sensors] gnome-applet-sensors-3.0.0-4.fc18.i686 requires libpanel-applet-4.so.0 gnome-applet-sensors-3.0.0-4.fc18.x86_64 requires libpanel-applet-4.so.0()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [kdevelop-custom-buildsystem] kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires libkdevplatformutil.so.6()(64bit) kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires libkdevplatformproject.so.6()(64bit) kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires libkdevplatformoutputview.so.6()(64bit) kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires libkdevplatformlanguage.so.6()(64bit) kdevelop-custom-buildsystem-1.2.2-2.fc19.x86_64 requires libkdevplatforminterfaces.so.6()(64bit) [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [libvirt-qmf] libvirt-qmf-0.3.0-6.fc19.x86_64 requires libmcommon_qmf.so.1.0.0()(64bit) libvirt-qmf-0.3.0-6.fc19.x86_64 requires libmcommon.so.1.0.0()(64bit) [matreshka] matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-mofext-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-mofext-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-ocl-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-ocl-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-uml-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-uml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-utp-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-utp-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnarl-4.7.so matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnarl-4.7.so()(64bit) matreshka-sql-core-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-core-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-postgresql-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-postgresql-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-sqlite-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-sqlite-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-xml-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-xml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) [maven-dependency-plugin] maven-dependency-plugin-2.7-1.fc19.noarch requires mvn(org.apache.commons:commons-io) [ooo2gd] ooo2gd-3.0.0-6.fc19.x86_64 requires gdata-java [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires
File Test-Smoke-1.59.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Test-Smoke: b1737467e96781883d51527407a01b5a Test-Smoke-1.59.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-Test-Smoke] 1.59 bump
commit 99d391555020782b170b733a4a02ab5c6394c33e
Author: Jitka Plesnikova jples...@redhat.com
Date: Mon May 6 14:49:37 2013 +0200
1.59 bump
.gitignore |1 +
perl-Test-Smoke.spec | 14 ++
sources |2 +-
3 files changed, 12 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 415f1ab..5e37cd4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@ Test-Smoke-1.43.tar.gz
/Test-Smoke-1.47.tar.gz
/Test-Smoke-1.50.tar.gz
/Test-Smoke-1.53.tar.gz
+/Test-Smoke-1.59.tar.gz
diff --git a/perl-Test-Smoke.spec b/perl-Test-Smoke.spec
index 1057090..5134a72 100644
--- a/perl-Test-Smoke.spec
+++ b/perl-Test-Smoke.spec
@@ -1,6 +1,6 @@
Name: perl-Test-Smoke
-Version:1.53
-Release:4%{?dist}
+Version:1.59
+Release:1%{?dist}
Summary:Perl core test smoke suite
License:GPL+ or Artistic
Group: Development/Libraries
@@ -13,6 +13,7 @@ BuildRequires: perl(File::Path)
BuildRequires: perl(File::Spec::Functions)
# Run-time
BuildRequires: perl(base)
+BuildRequires: perl(Carp)
BuildRequires: perl(Exporter)
BuildRequires: perl(File::Spec) = 0.82
BuildRequires: perl(JSON)
@@ -23,8 +24,9 @@ BuildRequires: perl(Text::ParseWords)
# Tests:
BuildRequires: perl(Archive::Tar)
BuildRequires: perl(Compress::Zlib)
-BuildRequires: perl(lib)
BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(Encode)
+BuildRequires: perl(lib)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(Mail::Sendmail)
@@ -39,6 +41,8 @@ results into an easy to read report.
%prep
%setup -q -n Test-Smoke-%{version}
+# Ignore output files from find-debuginfo.sh to fix the test 00-manifest.t
+echo 'debug.+\.list' MANIFEST.SKIP
%build
perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags}
@@ -48,7 +52,6 @@ make %{?_smp_mflags}
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f {} \;
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} %{buildroot}/*
rm -rf %{buildroot}/%{_bindir}/W32Configure.pl
rm -rf %{buildroot}/%{_mandir}/man1/W32Configure*
@@ -74,6 +77,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon May 06 2013 Jitka Plesnikova jples...@redhat.com - 1.59-1
+- 1.59 bump, bug-fix release
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.53-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index 702c78f..92bba21 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-44434030597ef256e76076f53b4076e2 Test-Smoke-1.53.tar.gz
+b1737467e96781883d51527407a01b5a Test-Smoke-1.59.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: Do you think this is a security risk and if not is it a bad UI decision?
what if the password IS 12 bullet characters :) Three UI elements: * two password fields that do not echo the password by default or covers it with bullets or asterisks. * one check-box that shows the password if the user wishes so. It is the most flexible scheme. If one doubts the typed password and re-typing it is not desirable or enough (if one suspects the keyboard) having a check-box that shows the password covers that usage case. And the user will make sure when to enable the check-box (and when not to). When one installs fedora, who is near to you when you install fedora, who is looking at you when you install fedora and the size of the password one will use for fedora, should not make uncomfortable the act of installing fedora. Ultimately, it is the responsibility of the user to not to get its password 'seen' (by any means), but i think the mentioned scheme is more convenient. Cheers. On Mon, May 6, 2013 at 9:41 AM, Przemek Klosowski przemek.klosow...@nist.gov wrote: On 05/03/2013 04:08 PM, Reartes Guillermo wrote: I think that the previous behaviour was better. (covering the password with bullets). what if the password IS 12 bullet characters :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On 05/03/2013 10:59 PM, Matthew Garrett wrote: On Fri, May 03, 2013 at 10:36:51PM -0400, Rahul Sundaram wrote: I was referring to the decision to show the password in full when the user is typing it. Many UI decisions are unprecedented. That doesn't justify reopening bugs that the maintainer has closed. If you want to have a discussion about whether or not this is a reasonable UI decision, do so somewhere other than Bugzilla. In all seriousness, this is a substantial UI decision that requires a commensurate change in user behavior---it shouldn't be dismissed so easily as marking it NOTABUG. Another example of such important change that recently appeared without recourse and much discussion is the lock screen: previously, the password unlock widget had focus so one could start typing the password, while the new behavior is that the focus is in the clock, and one needs to hit Esc or Enter. I understand the security tradeoffs: the former behavior is conditioning people to carelessly type passwords in the blind, so they are more vulnerable to fake authentication dialogs, while the new one almost uses the SAK (secure attention key) paradigm. Still, the user behavior change is significant and I keep making mistakes even though I understand and agree with the new scheme. By the way, does Gnome have a SAK? I don't think Esc is a true SAK, but maybe I am wrong about it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
Will and Mairin had some good links talking about the merits of doing this and how hiding passwords doesn't even do all that much to help (a determined person can always just watch your keyboard). This argument isn't very solid. I mean someone can just break your window to get in your house, so locking the door is waste of time, right? The bigger issue here is we should always have the mantra secure by default. This is not secure by default. Why not use a checkbox? Well, why use a widget if we don't have to? Using a checkbox means now we have to work in another widget to the design, introducing potential padding and layout problems. It's another string that needs to be translated. It's another thing that needs a mnemonic widget. By doing the focus trick, we completely get rid of the keyboard layout problem because you can see what you're typing as you're typing it. It may also even allow us to get rid of the confirmation entries for the same reason. A checkbox is probably the right way to handle this. While yes it's slightly more work, it does two very important things. It puts the user in control, and it is secure by default. Security is hard, and many security decisions can often have unintended impacts. I suspect in this instance, a new Fedora user (and even some old ones) will see this behavior and think one of two things. 1) It's a bug. 2) These people know NOTHING about security! Neither is an ideal outcome. Regardless of all the studies that say masking passwords doesn't help, we can't make this change quickly. We need to slowly ease people into such behavior. For now, the best solution is probably a checkbox, in a few releases we can revisit what the current accepted practice is. The current accepted practice is to mask the password, sometimes with a checkbox to unmask (but never unmask by default). I think a discussion about the merits of password masking could be had, but I'd rather not start down that path. Perhaps the better question is what problem are we trying to solve. Has anyone ever complained about Anaconda masking passwords? Thanks. -- JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On Mon, May 6, 2013 at 3:21 PM, Przemek Klosowski przemek.klosow...@nist.gov wrote: Another example of such important change that recently appeared without recourse and much discussion is the lock screen: previously, the password unlock widget had focus so one could start typing the password, while the new behavior is that the focus is in the clock, and one needs to hit Esc or Enter. This is vastly off-topic of course, but this was actually a temporary limitation in GNOME 3.6 - since 3.8 (e.g. Fedora 19), you can just type in your password again. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Avoid a 32 bits package from being pushed into 64 bits repository
Alejandro Alvarez Ayllon wrote:
The Broken dependencies report I have been getting for a while now:
dpm-dsi has broken dependencies in the epel-6 tree: On x86_64:
dpm-dsi-1.9.0-2.el6.i686 requires globus-gridftp-server-progs(x86-32)
I'd venture dpm-dsi could drop %{_isa} from this dependency.
-- rex
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/06/2013 09:27 AM, Josh Bressers wrote: Will and Mairin had some good links talking about the merits of doing this and how hiding passwords doesn't even do all that much to help (a determined person can always just watch your keyboard). Sure, a person can watch your keyboard, but it's usually more obvious than someone glancing at your screen. Your body tends to be unconsciously huddled over the keyboard when typing a password, obscuring view.(Not to mention that unless you have a VERY high-precision camera pointed the right way (or you type about 5 wpm), most of the time a human won't be able to follow your keystrokes. This argument isn't very solid. I mean someone can just break your window to get in your house, so locking the door is waste of time, right? The bigger issue here is we should always have the mantra secure by default. This is not secure by default. I agree strongly here. I have no problems with *permitting* the user to view the password unmasked, but doing so by default is just wrong. Why not use a checkbox? Well, why use a widget if we don't have to? Using a checkbox means now we have to work in another widget to the design, introducing potential padding and layout problems. It's another string that needs to be translated. It's another thing that needs a mnemonic widget. By doing the focus trick, we completely get rid of the keyboard layout problem because you can see what you're typing as you're typing it. It may also even allow us to get rid of the confirmation entries for the same reason. A checkbox is probably the right way to handle this. While yes it's slightly more work, it does two very important things. It puts the user in control, and it is secure by default. Agreed. Please add the widget. It's more work is not a valid answer. Yes I realize this means layout and translation changes. It also means that the installer is less prone to shoulder-surfing information leaks. The gains far outweigh the (perceived) costs. Security is hard, and many security decisions can often have unintended impacts. I suspect in this instance, a new Fedora user (and even some old ones) will see this behavior and think one of two things. 1) It's a bug. 2) These people know NOTHING about security! Neither is an ideal outcome. Yes, if nothing else, most users have been trained for many years that protecting their passwords is important. To have us suddenly displaying it for all to see (installer demos at conferences?) makes us look like we are intentionally ignoring conventional wisdom. (I'm not going to make any statements about the research studies here. At the moment I'm only talking about perception). Users *will* report this as a bug, and I would not be surprised if some people refuse to install Fedora because of it. I certainly wouldn't use the installer in a public place (even in the office, where someone could walk by wearing a pair of Google Glasses). Regardless of all the studies that say masking passwords doesn't help, we can't make this change quickly. We need to slowly ease people into such behavior. For now, the best solution is probably a checkbox, in a few releases we can revisit what the current accepted practice is. The current accepted practice is to mask the password, sometimes with a checkbox to unmask (but never unmask by default). I think a discussion about the merits of password masking could be had, but I'd rather not start down that path. Perhaps the better question is what problem are we trying to solve. Has anyone ever complained about Anaconda masking passwords? At the risk of sounding glib, when people have complaints about Anaconda, it's usually about more important things. Let's not try to solve a non-problem with a dubious solution, yes? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGHsfYACgkQeiVVYja6o6MfQgCgg+DtJy2pd5USzVrBZSNm92Tr oysAoKjCbTa0kIW5CByPFh11WnwKVhlI =z7Jr -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, May 06, 2013 at 08:27:14AM -0500, Josh Bressers wrote: A checkbox is probably the right way to handle this. While yes it's slightly more work, it does two very important things. It puts the user in control, and it is secure by default. Secure by default is definitely where we need to be at all times. Now if we could just get SSH to be secure by default... Regardless of all the studies that say masking passwords doesn't help, we can't make this change quickly. We need to slowly ease people into such behavior. For now, the best solution is probably a checkbox, in a few releases we can revisit what the current accepted practice is. The current accepted practice is to mask the password, sometimes with a checkbox to unmask (but never unmask by default). I remember another discussion similar to this (not on this list) where passwords are shown one character at a time on Android. That added a risk but because the screens are generally smaller and partially covered by someone's hand it wasn't that big of a deal. That was a good compromise that made it easier for people to make sure their passwords (passphrases, right?) were being entered correctly. I feel that not masking passwords isn't good. We can say that when we install Fedora in our homes that no one is around to see our passwords being entered. But we simply don't know where, physically, the user is when he is typing that password or what kind of surveilence is around at the time. - -- Eric - -- Eric Sparks Christensen Fedora Project - Red Hat spa...@redhat.com - spa...@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) iQGcBAEBCgAGBQJRh7HfAAoJEB/kgVGp2CYv41wL/jCSQ0itqwAxXhyTMb/RDQAJ lXFCGuDeu8+W9umSWtYqgXziGgGS6cVtX1g1RIGex2cCQ1nkRJ1SGqw+NQxx8PdW e+FZU276woHuOwUMVqdz7lr9k7eLHD+tnRpUIWiR/wLbjEUTtqqzkKbSq8p5YWZ9 ULY7uA8y5N02nNpenU5B+UK6y4cVBNmz57PKnhp8LrgbrGAhkwphPLlHjkXY1hi6 VmUy7Zc9B6ytVIPyoYJN5XiMqlvgGDDoUFBLk6RxmsskuuP/nn0dQefpes3zQ3k3 3zr2GduuxjWSQTsYVA9kDoXVMvTBgKFzDKMrskiL4UFKH/kr4h2e2u/rmVEqUWne kxCe/zZqljT1QMHMWkS74vo/JkQZ6MkmmYE+GOarv9ozD3iNRZ8Omb3kzTN7ev7J sjt9Ax+ujWX3l3NiH2+tSsZTlnsMaIeoF9tse9qhfYXLtRZUc5lm9/A4GgXyO0Vc gB9JjKxRqqnQNdQaHlDwZko6xo2QhqFibRVnOKstaw== =PAsn -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up: LLVM 3.3 and Mesa 9.2-pre
LLVM 3.3 is coming soon, and is required [1] for some upcoming Mesa features including newer Radeon support and llvmpipe on big-endian arches. Naturally, zero of the other llvm consumers in the OS actually build against llvm 3.3 without patching. If you're one of the -owners cc'd on this mail, there's a patch in your package in git that inelegantly [2] fixes the build against llvm 3.3. I'll be landing this soon in both F20 and F19, where soon means sometime after piglit stops telling me I've regressed texture_from_pixmap on r600, and after I've smoketested a couple of other GPUs. [1] - The usual caveat applies here, we _could_ backport a bunch of stuff to older Mesa and llvm, but that's both more difficult and riskier, so I ain't gonna do that. [2] - In that I didn't try even a little bit to make the patched state build against any llvm except 3.3. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On 05/04/2013 12:30 AM, Matthew Garrett wrote: On Fri, May 03, 2013 at 11:24:01PM -0500, Eric Sandeen wrote: Matthew, with all due respect the tone of the bug doesn't make me think that there is a lot of interest in discussion from the developers. Reopening bugs is generally a good way of ensuring that there's even less interest in discussion from the developers, and posting to mailing lists that most of the developers concerned don't read has pretty obvious problems in terms of changing their minds. From the process point of view, it does look a little obstructionist: No, we won't discuss it in Bugzilla; No we won't discuss it in fedora-devel either. Reminds me of the joke: Lunch on Tuesday? Sorry, can't do it on Tuesday---how about Never? is Never good for you?. I understand your point that the concerned Anaconda developers may simply not see the traffic, but they do know about the Bugzilla entry and this discussion on the devel list, so I hope that they could find it in their heart to put out their argument in the forum with the largest possible audience which at the moment seems to be here. Big changes deserve more explanation and outreach from the developers, not just dropping them in everyone's lap. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On 05/04/2013 05:37 AM, Michael Scherer wrote: Or I could also speak of the small non standard keyboard such as macbook one where ~ or | are not printed and where using the wrong keyboard could result in wrong characters if you are unaware of the problem. Reminds me of the famous case when someone could login while sitting down but not when they were standing up. The reason turned out to be that their keyboard layout was slightly non-standard and the keycodes didn't agree with keycaps. When they were sitting, they touch-typed and hit the correct keys, but when they were standing, they hunt-and-pecked and got the wrong keys. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-SOAP-Lite/f17] Bundle 0.714 IO modules to fix dependency breakage
commit 355ce891c40ce644d8b9572b3fc181b5323ae3d4
Author: Petr Šabata con...@redhat.com
Date: Thu Aug 2 17:15:45 2012 +0200
Bundle 0.714 IO modules to fix dependency breakage
perl-SOAP-Lite-0.715-IO-modules.patch | 425 +
perl-SOAP-Lite.spec |9 +-
2 files changed, 433 insertions(+), 1 deletions(-)
---
diff --git a/perl-SOAP-Lite-0.715-IO-modules.patch
b/perl-SOAP-Lite-0.715-IO-modules.patch
new file mode 100644
index 000..8c7c9fc
--- /dev/null
+++ b/perl-SOAP-Lite-0.715-IO-modules.patch
@@ -0,0 +1,425 @@
+From e5091cc065b492cfaba9896cb488035e291555e6 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20=C5=A0abata?= con...@redhat.com
+Date: Thu, 2 Aug 2012 17:10:04 +0200
+Subject: [PATCH] Add IO::SessionDat and IO::SessionSet from SOAP::Lite 0.714
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+
+Signed-off-by: Petr Šabata con...@redhat.com
+---
+ lib/IO/SessionData.pm | 230 +
+ lib/IO/SessionSet.pm | 163 ++
+ 2 files changed, 393 insertions(+), 0 deletions(-)
+ create mode 100644 lib/IO/SessionData.pm
+ create mode 100644 lib/IO/SessionSet.pm
+
+diff --git a/lib/IO/SessionData.pm b/lib/IO/SessionData.pm
+new file mode 100644
+index 000..de85382
+--- /dev/null
b/lib/IO/SessionData.pm
+@@ -0,0 +1,230 @@
++# ==
++#
++# Copyright (C) 2000 Lincoln D. Stein
++# Slightly modified by Paul Kulchenko to work on multiple platforms
++# Formatting changed to match the layout layed out in Perl Best Practices
++# (by Damian Conway) by Martin Kutter in 2008
++#
++# ==
++
++package IO::SessionData;
++
++use strict;
++use Carp;
++use IO::SessionSet;
++use vars '$VERSION';
++$VERSION = 1.02;
++
++use constant BUFSIZE = 3000;
++
++BEGIN {
++my @names = qw(EWOULDBLOCK EAGAIN EINPROGRESS);
++my %WOULDBLOCK =
++(eval {require Errno}
++? map {
++Errno-can($_)
++? (Errno-can($_)-() = 1)
++: (),
++} @names
++: ()
++),
++(eval {require POSIX}
++? map {
++POSIX-can($_) eval { POSIX-can($_)-() }
++? (POSIX-can($_)-() = 1)
++: ()
++} @names
++: ()
++);
++
++sub WOULDBLOCK { $WOULDBLOCK{$_[0]+0} }
++}
++
++# Class method: new()
++# Create a new IO::SessionData object. Intended to be called from within
++# IO::SessionSet, not directly.
++sub new {
++my $pack = shift;
++my ($sset,$handle,$writeonly) = @_;
++# make the handle nonblocking (but check for 'blocking' method first)
++# thanks to Jos Clijmans jos.clijm...@recyfin.be
++$handle-blocking(0) if $handle-can('blocking');
++my $self = bless {
++outbuffer = '',
++sset= $sset,
++handle = $handle,
++write_limit = BUFSIZE,
++writeonly = $writeonly,
++choker = undef,
++choked = 0,
++},$pack;
++$self-readable(1) unless $writeonly;
++return $self;
++}
++
++# Object method: handle()
++# Return the IO::Handle object corresponding to this IO::SessionData
++sub handle {
++return shift-{handle};
++}
++
++# Object method: sessions()
++# Return the IO::SessionSet controlling this object.
++sub sessions {
++return shift-{sset};
++}
++
++# Object method: pending()
++# returns number of bytes pending in the out buffer
++sub pending {
++return length shift-{outbuffer};
++}
++
++# Object method: write_limit([$bufsize])
++# Get or set the limit on the size of the write buffer.
++# Write buffer will grow to this size plus whatever extra you write to it.
++sub write_limit {
++my $self = shift;
++return defined $_[0]
++? $self-{write_limit} = $_[0]
++: $self-{write_limit};
++}
++
++# set a callback to be called when the contents of the write buffer becomes
larger
++# than the set limit.
++sub set_choke {
++my $self = shift;
++return defined $_[0]
++? $self-{choker} = $_[0]
++: $self-{choker};
++}
++
++# Object method: write($scalar)
++# $obj-write([$data]) -- append data to buffer and try to write to handle
++# Returns number of bytes written, or 0E0 (zero but true) if data queued but
not
++# written. On other errors, returns undef.
++sub write {
++my $self = shift;
++return unless my $handle = $self-handle; # no handle
++return unless defined $self-{outbuffer}; # no buffer for queued data
++
++$self-{outbuffer} .= $_[0] if defined $_[0];
++
++my $rc;
++if ($self-pending) { # data in the out buffer to write
++local $SIG{PIPE}='IGNORE';
++# added length() to make it work on Mac. Thanks to Robin Fuller
rful...@broadjump.com
++
Re: FYI: F20 Feature: Migrate to Bluez5
On Mon, 2013-05-06 at 10:13 +0100, Peter Robinson wrote: On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera bnoc...@redhat.com wrote: Heya, In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices. Bluez5 uses a D-Bus API that's not compatible with Bluez4[1] and as such, management applications and a number of libraries and daemons will need to be ported. For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages. Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers. Any analysis to what packages are affected, The ones I care about are: - gnome-user-share, gvfsd-obexftp, obex-data-server (ObexFTP/Obex PUSH will use a new obexd implementation) - gnome-bluetooth - PulseAudio (already ported to BlueZ 5) - NetworkManager blueman, and KDE will need to rework their Bluetooth support. Other applications that chose to poke at Bluetooth's D-Bus API directly will also need to be ported. Applications that use libbluetooth will most likely just need a rebuild against the library with the updated soname. how many are yet to support the new API and how hard it will be for them to be ported over. Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-SOAP-Lite/f17] Increase release
commit 3817d3ad787aa8448f08a64f7e952cdc1c2168d5
Author: Petr Písař ppi...@redhat.com
Date: Mon May 6 16:04:49 2013 +0200
Increase release
perl-SOAP-Lite.spec |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/perl-SOAP-Lite.spec b/perl-SOAP-Lite.spec
index 86de985..f6177d0 100644
--- a/perl-SOAP-Lite.spec
+++ b/perl-SOAP-Lite.spec
@@ -1,6 +1,6 @@
Name: perl-SOAP-Lite
Version:0.715
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Client and server side SOAP implementation
License:GPL+ or Artistic
Group: Development/Libraries
--
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: FYI: F20 Feature: Migrate to Bluez5
On Mon, May 6, 2013 at 3:35 AM, Bastien Nocera bnoc...@redhat.com wrote: Heya, In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices. So your Subject says this is a Feature, yet there's no link to a Feature page. I can't find one in the wiki either, and I know this hasn't gone through FESCo. Can you create one and get it submitted please? josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Pending soname bumps for m4ri, m4rie, and ntl
2013/5/3 Jerry James loganje...@gmail.com: Hi, Sorry for the delay responding. I would like to push updates for m4ri 20130416, m4rie 20130416, and ntl 6.0.0 to Rawhide. Each of those updates involves an soname bump. This will require rebuilds of the following packages: eclib flint latte-integrale linbox Macaulay2 polybori sagemath Singular I have built all of these in mock (although the sagemath build is still going; that one takes awhile!). This also incidentally fixes the Macaulay2 failure to build due to a bug in latte-integrale, Rex. Sorry that has taken so long, but I just got the patch from upstream to fix the problem this morning. I started working on updating to sagemath 5.9 that was just released. But if the 5.8 build finished, and most likely did, as most of the time is spent building documentation, it should be ok to update. I can handle all of the rebuilds unless any of the maintainers want to do it themselves. If the Singular maintainer is interested, I have worked out how to update it to 3-1-6, and also enable the polymake interface at the same time. Let me know if you would like me to do that as part of the rebuild. We should also consider making a flint-compat or flint1 package, so we can upgrade the flint package to version 2, unless sagemath can be adapted to flint 2.x without too much trouble. Singular wants version 2. The Singular abi/api is somewhat volatile, so, I prefer to keep at the version used by sagemath. Testing/updating after the m4ri and m4rie updates should be a better plan. If the other maintainers involved will let me know how they would like to handle this, I can either coordinate the rebuilds or do them myself. Regards, -- Jerry James http://www.jamezone.org/ Paulo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self introduction, and maintaining MySQL package
Hi On Mon, May 6, 2013 at 4:13 AM, Norvald H. Ryeng wrote: I see review requests on the list for new packages that people want into F19, so I don't see how it could be too late for upgrading an existing package. I don't think it is too late to update MySQL but a new package isn't really comparable. If existing packages break in an update, that is far more problematic than a completely new package that a user has to choose to install. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On Sat, May 4, 2013 at 6:31 AM, Rahul Sundaram methe...@gmail.com wrote: On 05/04/2013 12:24 AM, Eric Sandeen wrote: On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no? On a related note, Anaconda, GNOME, KDE etc seems to be relying on different rules about what an acceptable password is. We really need to settle on one library and provide a consistent way to tweak it. Everything (certainly Anaconda and GNOME, not sure about KDE) is supposed to use libpwquality. Is that not so? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 959945] perl-WebService-Validator-CSS-W3C-0.3 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=959945 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-WebService-Validator-CSS-W3C-0.3-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-WebService-Validator-CSS-W3C-0.3-1.fc17 -- 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=p5sR5VzIQQa=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: F19 DVD over size - what to drop?
On 5 May 2013, at 20:31, Chris Adams wrote: Once upon a time, Lars Seipel lars.sei...@gmail.com said: - the checksums for netinstall images are signed with a Fedora key - the corresponding public key is made available through https - therefore the integrity of installer images can be verified That's only verifiable after the fact (when you want to use the installer) if you burn to CD/DVD (which I believe is less common these days). If you put it on a USB stick with something like livecd-iso-to-disk it gets changed. That also doesn't protect against malicious updates.img from the install server. In any case, I was talking about validation _during_ install, not prior to install. How many people compare the ISO checksum and the signature on the checksum file? AFAIK there is not automated tool to do that, so it is a bunch of manual steps. Sure, the steps are manual: download iso, download checksum file, verify signature on checksum file, verify checksum on iso. Once I've done that, though, I have a reasonable expectation that the iso -- and anaconda, the keys and rpms on it -- are good. And I only have to do those steps once per release image, not every time I install a system. I know that the images that I stored on my local repo server are ones that I have previously checked. Whether I then put that image on an USB stick, or mount it on a local network server, or stick it in a DVD drive, I trust that image and its contents as much as I trust anything coming from the Fedora project. For me, though, the real head scratcher is this: the keys on that iso are the ones that yum will use to verify signatures on updates -- why are they trustworthy enough for that, but not for verifying signatures on rpms downloaded via netinstall or additional repos configured in the DVD's installation source spoke? Makes no sense to me. To bring this back around to the topic of this thread, this is the reason that I've continued to use the DVD for installations, and then do a yum upgrade afterwards. It is the only way that I know to ensure that all installed rpms are actually verified. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI?decision?
On 05.05.2013 10:54, drago01 wrote: Seriously this changes just papers over another bug we suck at keyboard layout selection ... fixing it by showing the password like that is just wrong. Thank you for writing this here! Password entry box is not a place for testing keyboard layout. Maybe this obvious remark should be forwarded to Anaconda developers? Pleas don't break unrelated things in UI just to say that some other bugs are fixed by this change. I really don't like to say it but after this whole Anaconda rewrite it's still not as usable as it was in F17 and now this plain password issue which fixes nothing occurred! Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Pending soname bumps for m4ri, m4rie, and ntl
On Mon, May 6, 2013 at 8:18 AM, Paulo César Pereira de Andrade
paulo.cesar.pereira.de.andr...@gmail.com wrote:
I started working on updating to sagemath 5.9 that was just
released. But if the 5.8 build finished, and most likely did, as
most of the time is spent building documentation, it should
be ok to update.
No, the build failed because of the new version of NTL. Sagemath's
ntl_wrap.{h,cpp} assume that many of the fundamental types (ZZ, ZZ_p,
ZZX, etc.) are structs. In NTL 6.0.0, they are classes, not structs.
I've got a patch to adapt sagemath to this, but didn't have time to
test it over the weekend. I've just started a test build.
If the build succeeds, what would you like me to do? I can send you
the patch, and you can work it into the 5.9 update, or I can do a
build of 5.8 with the patch.
The Singular abi/api is somewhat volatile, so, I prefer to keep
at the version used by sagemath. Testing/updating after the m4ri
and m4rie updates should be a better plan.
OK, that makes sense.
Rex, are you okay with me going forward with the rebuilds, or would
you like to handle your own?
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Q: webfonts:
Le Dim 5 mai 2013 12:30, Alec Leamas a écrit : On 05/05/2013 11:40 AM, Nicolas Mailhot wrote: Are you sure it works well in IE8 at all? Because there are lots of other reasons a modern web site will fail in old ie versions Double checking... and you're right, openerp only supports IE 9+. Which means that I could indeed go for using ttf/otf only. Other folks might have interest in this, don't know, but as fas as I am concerned this resolves some loose ends. I'm still not convinced that it makes sense to package a font like zocial like a regular desktop font (leaving legal issues aside here). Why not? People use all kind of symbol fonts in presentations and other documents (they *love* their symbol fonts, that was a major driver for dejavu adoption). As long as the font is technically sane and you've been careful enough to assign it a low priority in fontconfig there is no problem Don't forget, that browsers also use system fonts, so if you don't install the fonts in a standard place you're forcing all your Fedora web clients to download it dynamically from the web site. There is also the case when a package contains both a webfont and a desktop font (with different ttf files). Something like a /usr/share/fonts/webfonts for fonts packaged solely as a web static resource might possibly be a solution, I guess (?) Well as we've established there: 1. the only useful webfont format is eot (to reach users of old ie versions, all major browsers except ie are easily upgradable and support normal opentype fonts and there is no restriction on using opentype for floss fonts) 2. it's only useful for the very narrow range of web applications that use bleeding-edge html5 tricks like webfonts but still work with the braindamaged web engines included in ie 9 So if you wanted to do webfonts, the correct way would be to define a filesystem root such as /usr/share/eot-fonts (not a /usr/share/fonts/ subdirectory, that would pollute fontconfig space) But I doubt the intersection of fedora packages, large ie 9 population, html5-webapp, oldie-compatible-webapp amounts to much. So why bother. Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On 05/06/2013 10:48 AM, Miloslav Trmač wrote: On Sat, May 4, 2013 at 6:31 AM, Rahul Sundaram wrote: On 05/04/2013 12:24 AM, Eric Sandeen wrote: On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no? On a related note, Anaconda, GNOME, KDE etc seems to be relying on different rules about what an acceptable password is. We really need to settle on one library and provide a consistent way to tweak it. Everything (certainly Anaconda and GNOME, not sure about KDE) is supposed to use libpwquality. Is that not so? They are definitely not enforcing the same rules. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On Mon, 2013-05-06 at 11:43 -0400, Rahul Sundaram wrote: On 05/06/2013 10:48 AM, Miloslav Trmač wrote: On Sat, May 4, 2013 at 6:31 AM, Rahul Sundaram wrote: On 05/04/2013 12:24 AM, Eric Sandeen wrote: On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no? On a related note, Anaconda, GNOME, KDE etc seems to be relying on different rules about what an acceptable password is. We really need to settle on one library and provide a consistent way to tweak it. Everything (certainly Anaconda and GNOME, not sure about KDE) is supposed to use libpwquality. Is that not so? They are definitely not enforcing the same rules. One obvious area of inconsistency is that some of the tools _warn_ on weak passwords, and some _block_ on weak passwords. We should standardize on one or the other of those. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-CheckDeps] Initial import (perl-Test-CheckDeps-0.002-2)
commit 6bc0ad3609ccda5eecd3bd4da396143767ca
Author: Paul Howarth p...@city-fan.org
Date: Mon May 6 17:40:32 2013 +0100
Initial import (perl-Test-CheckDeps-0.002-2)
This module adds a test that assures all dependencies have been installed
properly. If requested, it can bail out all testing on error.
.gitignore |1 +
perl-Test-CheckDeps.spec | 64 ++
sources |1 +
3 files changed, 66 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..6882103 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Test-CheckDeps-[0-9.]*.tar.gz
diff --git a/perl-Test-CheckDeps.spec b/perl-Test-CheckDeps.spec
new file mode 100644
index 000..97917a2
--- /dev/null
+++ b/perl-Test-CheckDeps.spec
@@ -0,0 +1,64 @@
+Name: perl-Test-CheckDeps
+Summary: Check for presence of dependencies
+Version: 0.002
+Release: 2%{?dist}
+License: GPL+ or Artistic
+Group: Development/Libraries
+URL: https://metacpan.org/release/Test-CheckDeps
+Source0:
http://cpan.metacpan.org/authors/id/L/LE/LEONT/Test-CheckDeps-%{version}.tar.gz
+BuildArch: noarch
+# Build
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
+# Module
+BuildRequires: perl(CPAN::Meta)
+BuildRequires: perl(CPAN::Meta::Check)
+BuildRequires: perl(Exporter) = 5.57
+BuildRequires: perl(List::Util)
+BuildRequires: perl(Module::Metadata)
+BuildRequires: perl(Test::Builder)
+# Test Suite
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(Test::More) = 0.88
+# Release tests
+BuildRequires: perl(Pod::Coverage::TrustPod)
+# Test::Kwalitee uses Test::CheckDeps in its main test suite
+%if 0%{!?perl_bootstrap:1}
+BuildRequires: perl(Test::Kwalitee)
+%endif
+BuildRequires: perl(Test::Pod) = 1.41
+BuildRequires: perl(Test::Pod::Coverage) = 1.08
+# Runtime
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+
+%description
+This module adds a test that assures all dependencies have been installed
+properly. If requested, it can bail out all testing on error.
+
+%prep
+%setup -q -n Test-CheckDeps-%{version}
+
+%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 RELEASE_TESTING=1
+
+%clean
+
+%files
+%doc Changes LICENSE README
+%{perl_vendorlib}/Test/
+%{_mandir}/man3/Test::CheckDeps.3pm*
+
+%changelog
+* Wed May 1 2013 Paul Howarth p...@city-fan.org - 0.002-2
+- Sanitize for Fedora submission
+
+* Sat Apr 27 2013 Paul Howarth p...@city-fan.org - 0.002-1
+- Initial RPM version
diff --git a/sources b/sources
index e69de29..4f77cc1 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+e9dfcb9aa071ee3e3d66578432b8468d Test-CheckDeps-0.002.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: Do you think this is a security risk and if not is it a bad UI decision?
On Sat, 2013-05-04 at 00:26 -0500, Michael Cronenworth wrote: On 05/03/2013 03:08 PM, Reartes Guillermo wrote: I think that the previous behaviour was better. (covering the password with bullets). At least the phones only show one character at a time, not the whole password. GTK shows everything or nothing with visibility being a boolean setting. GTK would need to gain the ability to do this most likely through a new property for a GtkEntry widget. GTK+ has been able to do for a very long time. See https://developer.gnome.org/gtk3/3.8/GtkSettings.html#GtkSettings--gtk-entry-password-hint-timeout -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: LLVM 3.3 and Mesa 9.2-pre
Will this mean that newish radeon UVD (video decoder acceleration stuff) will be available (or at least easier) for F19? Best regards Andreas 2013/5/6 Adam Jackson a...@redhat.com LLVM 3.3 is coming soon, and is required [1] for some upcoming Mesa features including newer Radeon support and llvmpipe on big-endian arches. Naturally, zero of the other llvm consumers in the OS actually build against llvm 3.3 without patching. If you're one of the -owners cc'd on this mail, there's a patch in your package in git that inelegantly [2] fixes the build against llvm 3.3. I'll be landing this soon in both F20 and F19, where soon means sometime after piglit stops telling me I've regressed texture_from_pixmap on r600, and after I've smoketested a couple of other GPUs. [1] - The usual caveat applies here, we _could_ backport a bunch of stuff to older Mesa and llvm, but that's both more difficult and riskier, so I ain't gonna do that. [2] - In that I didn't try even a little bit to make the patched state build against any llvm except 3.3. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI: F20 Feature: Migrate to Bluez5
On Mon, 2013-05-06 at 09:35 +0200, Bastien Nocera wrote: Heya, In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices. Bluez5 uses a D-Bus API that's not compatible with Bluez4[1] and as such, management applications and a number of libraries and daemons will need to be ported. For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages. Well fun... poke me so we can discuss approaches before starting on the NM parts; I hope we can actually collapse some of the abstractions in NM's Bluez manager since the code is trying to be somewhat defensive. Dan Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers. Cheers [1]: http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/ and http://lwn.net/Articles/531133/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-CheckDeps/f17] Initial import (perl-Test-CheckDeps-0.002-2)
Summary of changes: 6bc0ad3... Initial import (perl-Test-CheckDeps-0.002-2) (*) (*) 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: Review swap (4 slots available)
On 05/05/2013 02:45 AM, Alex G. wrote: Hi, Billy Mays here with a special ml offer: I have 4 packages I'd like to get in before the Release of F19. For each of these slots, I'm offering to review a package of your choosing. But wait, there's more! Choose your slot within 72 hours, and I will add, free of charge, a smiley face to the review of your package. Hurry! Supplies are running low. (firmware) https://bugzilla.redhat.com/show_bug.cgi?id=959734 (fx2lafw)https://bugzilla.redhat.com/show_bug.cgi?id=922246 (sigrok-cli) https://bugzilla.redhat.com/show_bug.cgi?id=865979 Billy Mays -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: clock-applet memory leak
On 05/02/2013 05:43 PM, Adam Williamson wrote: On Wed, 2013-04-24 at 11:22 -0400, Przemek Klosowski wrote: On 04/23/2013 07:40 PM, Florian Müllner wrote: On Mon, Apr 22, 2013 at 6:55 PM, Przemek Klosowski przemek.klosow...@nist.gov wrote: Since clock-applet is a default install on every Fedora, I thought this would be widely reported While it is installed on every (default desktop spin) Fedora system, it is only used by the (non-default) GNOME fallback mode, which is likely why it hasn't been reported as much as you assumed. It is also unmaintained upstream and will no longer be included in Fedora 19. Oh, that's funny because my Gnome uses fallback mode because of problems with Intel graphics drivers, which is the other critical bug I have open: https://bugzilla.redhat.com/show_bug.cgi?id=94 which essentially crashes everything that uses OpenGL (all 3D and some 2D drawing applications). Just my luck I guess. Time for a new hardware. You could try F19. Wasn't there some chatter that that 'all 3D stuff crashes on old Intel hardware' had got fixed in F19? IMBW, I guess. I did--I submitted my report to the Intel graphics test page. It seems that this particular problem has been fixed although some 3D apps still crash, in a different place. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap (4 slots available)
On Mon, May 6, 2013 at 10:39 AM, Alex G. mr.nuke...@gmail.com wrote: On 05/05/2013 02:45 AM, Alex G. wrote: Hi, Billy Mays here with a special ml offer: I have 4 packages I'd like to get in before the Release of F19. For each of these slots, I'm offering to review a package of your choosing. But wait, there's more! Choose your slot within 72 hours, and I will add, free of charge, a smiley face to the review of your package. Hurry! Supplies are running low. (firmware) https://bugzilla.redhat.com/show_bug.cgi?id=959734 (fx2lafw)https://bugzilla.redhat.com/show_bug.cgi?id=922246 (sigrok-cli) https://bugzilla.redhat.com/show_bug.cgi?id=865979 I took the two that have all dependencies satisfied. You can do: https://bugzilla.redhat.com/show_bug.cgi?id=953699 https://bugzilla.redhat.com/show_bug.cgi?id=953701 Billy Mays I didn't know ghosts can post to mailing lists. ;-) -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On Mon, 2013-05-06 at 09:21 -0400, Przemek Klosowski wrote: On 05/03/2013 10:59 PM, Matthew Garrett wrote: On Fri, May 03, 2013 at 10:36:51PM -0400, Rahul Sundaram wrote: I was referring to the decision to show the password in full when the user is typing it. Many UI decisions are unprecedented. That doesn't justify reopening bugs that the maintainer has closed. If you want to have a discussion about whether or not this is a reasonable UI decision, do so somewhere other than Bugzilla. In all seriousness, this is a substantial UI decision that requires a commensurate change in user behavior---it shouldn't be dismissed so easily as marking it NOTABUG. Another example of such important change that recently appeared without recourse and much discussion is the lock screen: previously, the password unlock widget had focus so one could start typing the password, while the new behavior is that the focus is in the clock, and one needs to hit Esc or Enter. I understand the security tradeoffs: the former behavior is conditioning people to carelessly type passwords in the blind, so they are more vulnerable to fake authentication dialogs, while the new one almost uses the SAK (secure attention key) paradigm. Still, the user behavior change is significant and I keep making mistakes even though I understand and agree with the new scheme. This was a temporary situation in GNOME 3.6, when the new lock screen was introduced. In GNOME 3.8 (F19), you can just type your password again. By the way, does Gnome have a SAK? I don't think Esc is a true SAK, but maybe I am wrong about it? You can't implement a true SAK without support from X and the kernel. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On Mon, 2013-05-06 at 12:48 -0400, Matthias Clasen wrote: On Sat, 2013-05-04 at 00:26 -0500, Michael Cronenworth wrote: On 05/03/2013 03:08 PM, Reartes Guillermo wrote: I think that the previous behaviour was better. (covering the password with bullets). At least the phones only show one character at a time, not the whole password. GTK shows everything or nothing with visibility being a boolean setting. GTK would need to gain the ability to do this most likely through a new property for a GtkEntry widget. GTK+ has been able to do for a very long time. See https://developer.gnome.org/gtk3/3.8/GtkSettings.html#GtkSettings--gtk-entry-password-hint-timeout Is there a standard GTK+ widget for the apparently-fairly-popular compromise of 'hidden with a confirmation box by default, with a button that shows the password and greys out the confirmation box'? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On Mon, 2013-05-06 at 11:01 -0700, Adam Williamson wrote: On Mon, 2013-05-06 at 12:48 -0400, Matthias Clasen wrote: On Sat, 2013-05-04 at 00:26 -0500, Michael Cronenworth wrote: On 05/03/2013 03:08 PM, Reartes Guillermo wrote: I think that the previous behaviour was better. (covering the password with bullets). At least the phones only show one character at a time, not the whole password. GTK shows everything or nothing with visibility being a boolean setting. GTK would need to gain the ability to do this most likely through a new property for a GtkEntry widget. GTK+ has been able to do for a very long time. See https://developer.gnome.org/gtk3/3.8/GtkSettings.html#GtkSettings--gtk-entry-password-hint-timeout Is there a standard GTK+ widget for the apparently-fairly-popular compromise of 'hidden with a confirmation box by default, with a button that shows the password and greys out the confirmation box'? No, and I don't think it is a very likely candidate for a widget to add to GTK. I could see adding a password entry widget that adds the peekabo eye thingie. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Pending soname bumps for m4ri, m4rie, and ntl
2013/5/6 Jerry James loganje...@gmail.com:
On Mon, May 6, 2013 at 8:18 AM, Paulo César Pereira de Andrade
paulo.cesar.pereira.de.andr...@gmail.com wrote:
I started working on updating to sagemath 5.9 that was just
released. But if the 5.8 build finished, and most likely did, as
most of the time is spent building documentation, it should
be ok to update.
No, the build failed because of the new version of NTL. Sagemath's
ntl_wrap.{h,cpp} assume that many of the fundamental types (ZZ, ZZ_p,
Ok. This will not be one of the easy updates, as sagemath 5.9
besides not changing much build requires from sagemath 5.8,
had a lot of refactoring on the key portions of the rpm package
build.
ZZX, etc.) are structs. In NTL 6.0.0, they are classes, not structs.
I've got a patch to adapt sagemath to this, but didn't have time to
test it over the weekend. I've just started a test build.
If it works for sagemath 5.8, updating for sagemath 5.9 should
be trivial.
If the build succeeds, what would you like me to do? I can send you
the patch, and you can work it into the 5.9 update, or I can do a
build of 5.8 with the patch.
This is fine, feel free to rebuild sagemath 5.8 in rawhide if you
think it is required to avoid breakage for some time/days. If
everything goes fine, I will add your patch to the sagemath 5.9
package.
The Singular abi/api is somewhat volatile, so, I prefer to keep
at the version used by sagemath. Testing/updating after the m4ri
and m4rie updates should be a better plan.
OK, that makes sense.
Rex, are you okay with me going forward with the rebuilds, or would
you like to handle your own?
--
Jerry James
http://www.jamezone.org/
Paulo
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Review swap (2 items)
2 (two) trivial qt-based applicaions for sale: https://bugzilla.redhat.com/show_bug.cgi?id=957333 - QuiteRSS - RSS/Atom aggregator https://bugzilla.redhat.com/show_bug.cgi?id=960194 - QTerminal - terminal emulator Welcome! PS: I prefere to review qt-based applications. And/or C/C++. WARNING: after _unsuccessfull_ (for me) review swaps with Christopher Meng mailto:cicku...@gmail.com (tea https://bugzilla.redhat.com/show_bug.cgi?id=957422) and Markus Mayer mailto:lotharl...@gmx.de (jimtcl https://bugzilla.redhat.com/show_bug.cgi?id=959747) I will review your package _after_ complete reviewing my ones. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On 06.05.2013 18:38, Adam Williamson wrote: On Mon, 2013-05-06 at 11:43 -0400, Rahul Sundaram wrote: On 05/06/2013 10:48 AM, Miloslav Trmač wrote: On Sat, May 4, 2013 at 6:31 AM, Rahul Sundaram wrote: On 05/04/2013 12:24 AM, Eric Sandeen wrote: On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no? On a related note, Anaconda, GNOME, KDE etc seems to be relying on different rules about what an acceptable password is. We really need to settle on one library and provide a consistent way to tweak it. Everything (certainly Anaconda and GNOME, not sure about KDE) is supposed to use libpwquality. Is that not so? They are definitely not enforcing the same rules. One obvious area of inconsistency is that some of the tools _warn_ on weak passwords, and some _block_ on weak passwords. We should standardize on one or the other of those. Not really. It makes complete sense to allow overriding the rules in certain contexts. For example when root is setting another user's password. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-FailWarnings/f19] Initial import.
commit 0fe0cdfc637524739aef877977378062e0a3e826
Author: Emmanuel Seyman emman...@seyman.fr
Date: Mon May 6 21:39:23 2013 +0200
Initial import.
.gitignore |1 +
perl-Test-FailWarnings.spec | 63 +++
sources |1 +
3 files changed, 65 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..9d07648 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Test-FailWarnings-0.003.tar.gz
diff --git a/perl-Test-FailWarnings.spec b/perl-Test-FailWarnings.spec
new file mode 100644
index 000..e21656c
--- /dev/null
+++ b/perl-Test-FailWarnings.spec
@@ -0,0 +1,63 @@
+Name: perl-Test-FailWarnings
+Version:0.003
+Release:2%{?dist}
+Summary:Add test failures if warnings are caught
+License:ASL 2.0
+
+URL:http://search.cpan.org/dist/Test-FailWarnings/
+Source0:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/Test-FailWarnings-%{version}.tar.gz
+
+BuildArch: noarch
+BuildRequires: perl
+BuildRequires: perl(Capture::Tiny)
+BuildRequires: perl(Carp)
+BuildRequires: perl(constant)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Find)
+BuildRequires: perl(File::Spec::Functions)
+BuildRequires: perl(List::Util)
+BuildRequires: perl(strict)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(warnings)
+
+# tests
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(Test::Script)
+
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+This module hooks $SIG{__WARN__} and converts warnings to Test::More's
+fail() calls. It is designed to be used with done_testing, when you don't
+need to know the test count in advance.
+
+%prep
+%setup -q -n Test-FailWarnings-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes CONTRIBUTING LICENSE README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Fri May 03 2013 Emmanuel Seyman emman...@seyman.fr - 0.003-2
+- Take into account review comments (#957466)
+
+* Sun Apr 28 2013 Emmanuel Seyman emman...@seyman.fr 0.003-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..775c409 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+bbed4b467d8934f285b8a0cffc9fe200 Test-FailWarnings-0.003.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: Review swap (2 items)
On 06.05.2013 21:33, Eugene Pivnev wrote: 2 (two) trivial qt-based applicaions for sale: https://bugzilla.redhat.com/show_bug.cgi?id=957333 - QuiteRSS - RSS/Atom aggregator https://bugzilla.redhat.com/show_bug.cgi?id=960194 - QTerminal - terminal emulator Welcome! I'll take qterminal in exchange for https://bugzilla.redhat.com/show_bug.cgi?id=960258 (Sailcut - A sail design and plotting software) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap (2 items)
Thanks. Ok. 06.05.2013 23:44, Sandro Mani: On 06.05.2013 21:33, Eugene Pivnev wrote: 2 (two) trivial qt-based applicaions for sale: https://bugzilla.redhat.com/show_bug.cgi?id=957333 - QuiteRSS - RSS/Atom aggregator https://bugzilla.redhat.com/show_bug.cgi?id=960194 - QTerminal - terminal emulator Welcome! I'll take qterminal in exchange for https://bugzilla.redhat.com/show_bug.cgi?id=960258 (Sailcut - A sail design and plotting software) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-Kwalitee/f19] Update to 1.04
Summary of changes: 37da3ec... Update to 1.04 (*) (*) 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: Do you think this is a security risk and if not is it a bad UI decision?
On Mon, 2013-05-06 at 21:37 +0200, Stef Walter wrote: On 06.05.2013 18:38, Adam Williamson wrote: On Mon, 2013-05-06 at 11:43 -0400, Rahul Sundaram wrote: On 05/06/2013 10:48 AM, Miloslav Trmač wrote: On Sat, May 4, 2013 at 6:31 AM, Rahul Sundaram wrote: On 05/04/2013 12:24 AM, Eric Sandeen wrote: On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no? On a related note, Anaconda, GNOME, KDE etc seems to be relying on different rules about what an acceptable password is. We really need to settle on one library and provide a consistent way to tweak it. Everything (certainly Anaconda and GNOME, not sure about KDE) is supposed to use libpwquality. Is that not so? They are definitely not enforcing the same rules. One obvious area of inconsistency is that some of the tools _warn_ on weak passwords, and some _block_ on weak passwords. We should standardize on one or the other of those. Not really. It makes complete sense to allow overriding the rules in certain contexts. For example when root is setting another user's password. But they have different behaviours for the same operation. For e.g., initial-setup and g-i-s have different behaviours for setting the password for the first user account. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Announcing OLPC OS 13.1.0
Hi, We're pleased to announce the release of OLPC OS 13.1.0 for XO-1, XO-1.5, XO-1.75 and XO-4. Details of new features, known issues, and how to download/install/upgrade can all be found in the release notes: http://wiki.laptop.org/go/Release_notes/13.1.0 Many thanks to all contributors, testers, upstreams, and those who have provided feedback of any kind. For those who were following the release candidate process in the last few months: candidate build 36 is released as final with no changes. Thanks! Daniel p.s. We're already knee-deep in development of the next release, 13.2.0. More info here: http://wiki.laptop.org/go/13.2.0 http://wiki.laptop.org/go/13.2.0/Release_plan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On Fri, 2013-05-03 at 13:04 -0700, Dan Mashal wrote: Hi, In the latest Fedora 19 Beta TC2 install after I got through the initial steps of the install I started to setup my root password. To my surprise my password was shown in plain text instead of bullets. For the record: commit da565b769979a031f318dbc727b9888e4f1fb37c Author: Chris Lumens clum...@redhat.com Date: Mon May 6 17:18:30 2013 -0400 Revert Add signal handlers for controlling password entry visibility. (#958608). This reverts commit 99464761dab4e43cfbf8caa059815c6ab67c6282. Internet, you may stand down. I don't know if the devs plan to look at the various 'compromise' solutions that were suggested, or if the plan is just to stick with regular old full-on masking. But right now, the status is that we're back to full-on masking. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding open-vm-tools to core group
Just picking the latest mail on this thread. I don't see why we would add this by default, the VM will function without is (unlike storage) and we don't add ovirt-guest-agent and other virt vendor's agents by default. We do, in fact, include the SPICE agent stuff by default now. (Which I like because it means copy/paste out of Fedora KVMs always works, but I never claimed not to be a hypocrite :) I think there are opinions in favor as well as against including open-vm-tools to core group. However, I'm not sure if there is a convincing explanation for following issues with conditional install of open-vm-tools: 1. Given that DVD image will not have open-vm-tools, installing these by default inside a VM will not be possible when VM is not connected to network or VM is running behind a proxy. 2. All the usecases where install environment is not the same as execution environment (including P2V) will have poor install experience. 3. Installer (Anaconda) will have to be modified specifically for each virtualization solution. Given that open-vm-tools is not a large package and is a no-op on physical, what are the real obstacles in putting it in core? Or, in other words, what would it take to put it in core group? If it is absolute no, I would proceed with the Anaconda patch if there is a good explanation/alternative to the 3 issues I have listed above. Thanks, Ravindra -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding open-vm-tools to core group
On Mon, 2013-05-06 at 15:04 -0700, Ravindra Kumar wrote: If it is absolute no, I would proceed with the Anaconda patch if there is a good explanation/alternative to the 3 issues I have listed above. Talk to the anaconda devs first. I'm no expert on anaconda internals, but I play one on TV, and I'm pretty sure they wouldn't take a patch that tries to uninstall stuff from the system it just installed. There are already mechanisms in anaconda for conditionally adding packages to the 'to be installed' set, based on the system architecture, and probably some other things. You probably want to either make use of or at least mirror the design of these existing mechanisms, rather than just inventing a new one out of thin air. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Pending soname bumps for m4ri, m4rie, and ntl
On Mon, May 6, 2013 at 12:25 PM, Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com wrote: This is fine, feel free to rebuild sagemath 5.8 in rawhide if you think it is required to avoid breakage for some time/days. If everything goes fine, I will add your patch to the sagemath 5.9 package. Something went wrong with the i386 build. I only tried the x86_64 build in mock, due to the length of time it takes to build. I will do an i386 mock build overnight, so I can fix the problem in the morning. Sorry about that. Macaulay2 is still building, but everything else on the list is now done in Rawhide. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On Mon, May 6, 2013 at 2:42 PM, Adam Williamson awill...@redhat.com wrote: For the record: commit da565b769979a031f318dbc727b9888e4f1fb37c Author: Chris Lumens clum...@redhat.com Date: Mon May 6 17:18:30 2013 -0400 Revert Add signal handlers for controlling password entry visibility. (#958608). This reverts commit 99464761dab4e43cfbf8caa059815c6ab67c6282. Internet, you may stand down. Thank you. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap (only one slot left!!! UAAARGH!!!)
There's only one slot left! Only one! Oh n! Grab it before it's gone! (fx2lafw)https://bugzilla.redhat.com/show_bug.cgi?id=922246 Alex (under mentorship from ghost of Billy Mays) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On Mon, May 6, 2013 at 9:37 AM, Eric H. Christensen spa...@fedoraproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, May 06, 2013 at 08:27:14AM -0500, Josh Bressers wrote: A checkbox is probably the right way to handle this. While yes it's slightly more work, it does two very important things. It puts the user in control, and it is secure by default. Secure by default is definitely where we need to be at all times. Now if we could just get SSH to be secure by default... That's a separate issue. But it's not gonna happen. I've raised some of the more obvious flaws on the developer's list, fhaws that existed back before OpenSSH even existed such as lack of hostkey experation, user key experiation, lack of tools to delete specific host keys from .ssh/known_hosts, lack of tools to manage authorized_keys, and the continuing support for the default use of unencrypted private keys. The attitude from the core OpenBSD development community was if you don't trust the machine you're on, you shouldn't be using it, and Theo de Raadt calling me four letter words. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Do you think this is a security risk and if not is it a bad UI decision?
On Mon, May 6, 2013 at 8:34 AM, Bill Peck bp...@redhat.com wrote: On 05/04/2013 06:22 PM, Dan Mashal wrote: On Sat, May 4, 2013 at 2:37 AM, Michael Scherer m...@zarb.org wrote: I can add to that that I have seen more than once people setting a password which was not the one they believed due to : - keyboard layout ( ie, qwerty vs azerty in France ) - small usage difference with Windows way, again on azerty keyboard ( people using capslock on french keyboard to type numbers while they should use shift, as capslock just type capital letter like À or É and not 0 or 2, and if you do not understand, just look on the web to compare how different it is from qwerty-based keyboard ) The installer should detect the keyboard automatically. In fact you can even tell it what type of keyboard you have on the first screen. On the screen where you can pick your keyboard, do we have a test area where the user can verify the keyboard layout? Or maybe if you select a different keyboard it should automatically pop up a verify keyboard screen? No matter how smart the kernel or anaconda, this can be nightmarish when funneled through a virtualization console. The remapping between the user's operating system, through the VMware or VNC or other virtualization console access toolkit, can create. some very odd remappings. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap (2 items)
On 05/06/2013 02:49 PM, Eugene Pivnev wrote: Thanks. Ok. 06.05.2013 23:44, Sandro Mani: On 06.05.2013 21:33, Eugene Pivnev wrote: 2 (two) trivial qt-based applicaions for sale: https://bugzilla.redhat.com/show_bug.cgi?id=957333 - QuiteRSS - RSS/Atom aggregator https://bugzilla.redhat.com/show_bug.cgi?id=960194 - QTerminal - terminal emulator Welcome! I'll take qterminal in exchange for https://bugzilla.redhat.com/show_bug.cgi?id=960258 (Sailcut - A sail design and plotting software) And I'll take QuiteRSS in exchange for: (fx2lafw)https://bugzilla.redhat.com/show_bug.cgi?id=922246 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap (2 items)
On 05/06/2013 10:17 PM, Alex G. wrote: And I'll take QuiteRSS in exchange for: (fx2lafw)https://bugzilla.redhat.com/show_bug.cgi?id=922246 OOPS. I see it's already taken. Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Concern about FedoraCryptoConsolidation
https://fedoraproject.org/wiki/FedoraCryptoConsolidation While I understand the reasons for this idea of Consolidation I have a concern that very valid use cases are being ignored or unknown. As an example I have a use case supported with curl and OpenSSL like this: curl --cacert truststore.pem --cert example.com.pem:test https://example.com This is where I have a private truststore that I don't want shared with any other applications and client certificate that I don't want to install for usage by any other application. With curl and stunnel for example, how is this use case supported with NSS? The paradigm of having certs in db form is fine for shared resources but not appropriate for resources that are never intended to be shared. curl with OpenSSL uses a file paradigm, defaulting to /usr/local/share/certs/ca-root-nss.crt in the nominal case and whatever you specify in the explicit case. If there is something similar that allows you to create a non-shared file in berkeley db format and a non-shared instance of a client certificate in some format that could work. However given that use case is already supported with OpenSSL curl and stunnel, I'm skeptical of all the work to port NSS which was never designed for these use cases. Another problem I see is the case where the global certificates are no longer valid for whatever reason. These decisions can be made by the OS (CRL's), the user/admin OR the application(s). With the NSS, the application seems left out of the decision making process. In many cases the user/admin cannot be relied upon for proper management and the OS's notions of what is valid and the application's notion are different. This situation coalesces to my first use case but I could see it being a more general case of certificate management. r -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI: F20 Feature: Migrate to Bluez5
On Mon, 2013-05-06 at 10:08 -0400, Josh Boyer wrote: On Mon, May 6, 2013 at 3:35 AM, Bastien Nocera bnoc...@redhat.com wrote: Heya, In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices. So your Subject says this is a Feature, yet there's no link to a Feature page. I can't find one in the wiki either, and I know this hasn't gone through FESCo. Can you create one and get it submitted please? The F20 feature pages seem to be lacking (or the curating of the Wiki is). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Mail-GnuPG/f19] Upstream update.
Summary of changes: d4fc324... Upstream update. (*) (*) 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-GnuPG/f18] (3 commits) ...Merge cleanup.
Summary of changes: 3141af8... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass (*) d4fc324... Upstream update. (*) 299ad42... Merge cleanup. (*) 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-GnuPG/f18: 3/3] Merge cleanup.
commit 299ad423a8ff481346f2e7c525d307725ddc1f6d Author: Ralf Corsépius corse...@fedoraproject.org Date: Mon May 6 08:06:18 2013 +0200 Merge cleanup. perl-Mail-GnuPG.spec |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) --- diff --git a/perl-Mail-GnuPG.spec b/perl-Mail-GnuPG.spec index d364063..5586713 100644 --- a/perl-Mail-GnuPG.spec +++ b/perl-Mail-GnuPG.spec @@ -53,9 +53,6 @@ GPG_PRESET_PASSPHRASE=/usr/libexec/gpg-preset-passphrase ./Build test * Mon May 06 2013 Ralf Corsépius corse...@fedoraproject.org - 0.19-1 - Upstream update. -* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.18-2 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild - * Mon Jul 30 2012 Ralf Corsépius corse...@fedoraproject.org - 0.18-1 - Upstream update. - Spec file cleanup. -- 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 912991] perl-GnuPG-Interface-0.46 breaks perl-Mail-GnuPG
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=912991 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- perl-Mail-GnuPG-0.19-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-Mail-GnuPG-0.19-1.fc19 -- 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=MHesTjYerva=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-Mail-GnuPG/f17] (4 commits) ...Merge remote-tracking branch 'origin/f18' into f17
Summary of changes: 3141af8... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass (*) d4fc324... Upstream update. (*) 299ad42... Merge cleanup. (*) 13b1255... Merge remote-tracking branch 'origin/f18' into f17 (*) 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-GnuPG/f17: 4/4] Merge remote-tracking branch 'origin/f18' into f17
commit 13b1255cb0daca33a71c39e44eb794637733ba18 Merge: f363e1e 299ad42 Author: Ralf Corsépius corse...@fedoraproject.org Date: Mon May 6 08:19:02 2013 +0200 Merge remote-tracking branch 'origin/f18' into f17 .gitignore |2 +- perl-Mail-GnuPG.spec |5 - sources |2 +- 3 files changed, 6 insertions(+), 3 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
[Bug 959610] repoclosure failure on 19 Beta TC3 DVDs (perl-DBD-MySQL)
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=959610 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED CC||ppi...@redhat.com Fixed In Version||perl-DBD-MySQL-4.023-2.fc19 Resolution|--- |NEXTRELEASE Last Closed||2013-05-06 02:36:58 --- Comment #3 from Petr Pisar ppi...@redhat.com --- I cannot reproduce with current F19 on x86_64. There was a new build perl-DBD-MySQL-4.023-2.fc19 https://koji.fedoraproject.org/koji/rpminfo?rpmID=3960341 addressing this issue probably. The build has been done on 2013-04-29. I guess your DVD is out-dated. -- 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=QVv9VZd5xva=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 959937] New: perl-App-cpanminus-1.6911 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=959937 Bug ID: 959937 Summary: perl-App-cpanminus-1.6911 is available Product: Fedora Version: rawhide Component: perl-App-cpanminus Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: mmasl...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Category: --- Latest upstream release: 1.6911 Current version in Fedora Rawhide: 1.6909 URL: http://search.cpan.org/dist/App-cpanminus/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=mbHpDRxPOsa=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 959938] New: perl-constant-tiny-1.01 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=959938 Bug ID: 959938 Summary: perl-constant-tiny-1.01 is available Product: Fedora Version: rawhide Component: perl-constant-tiny Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Category: --- Latest upstream release: 1.01 Current version in Fedora Rawhide: 1.00 URL: http://search.cpan.org/dist/constant-tiny/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=GcGxG8hfCda=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 959940] New: perl-Pod-Simple-3.28 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=959940 Bug ID: 959940 Summary: perl-Pod-Simple-3.28 is available Product: Fedora Version: rawhide Component: perl-Pod-Simple Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: extras-orp...@fedoraproject.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: extras-orp...@fedoraproject.org, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, st...@silug.org Category: --- Latest upstream release: 3.28 Current version in Fedora Rawhide: 3.26 URL: http://search.cpan.org/dist/Pod-Simple/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=yfPOXCVgmPa=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 959943] New: perl-Test-Pod-1.48 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=959943 Bug ID: 959943 Summary: perl-Test-Pod-1.48 is available Product: Fedora Version: rawhide Component: perl-Test-Pod Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: mmasl...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, pertu...@free.fr, st...@silug.org Category: --- Latest upstream release: 1.48 Current version in Fedora Rawhide: 1.46 URL: http://search.cpan.org/dist/Test-Pod/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=PfoITn8sLta=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 959944] New: perl-Test-Smoke-1.59 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=959944 Bug ID: 959944 Summary: perl-Test-Smoke-1.59 is available Product: Fedora Version: rawhide Component: perl-Test-Smoke Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: mmasl...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Category: --- Latest upstream release: 1.59 Current version in Fedora Rawhide: 1.53 URL: http://search.cpan.org/dist/Test-Smoke/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=uzOMGqKgmCa=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 959945] New: perl-WebService-Validator-CSS-W3C-0.3 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=959945 Bug ID: 959945 Summary: perl-WebService-Validator-CSS-W3C-0.3 is available Product: Fedora Version: rawhide Component: perl-WebService-Validator-CSS-W3C Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: mmasl...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Category: --- Latest upstream release: 0.3 Current version in Fedora Rawhide: 0.2 URL: http://search.cpan.org/dist/WebService-Validator-CSS-W3C/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=qEpFhViljaa=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 959940] perl-Pod-Simple-3.28 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=959940 Fedora Admin XMLRPC Client fedora-admin-xml...@redhat.com changed: What|Removed |Added Assignee|extras-orphan@fedoraproject |ppi...@redhat.com |.org| -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=4KtBw0EIe2a=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
[pkgdb] perl-Pod-Simple ownership changed
Package perl-Pod-Simple in Fedora devel is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Pod-Simple -- 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 959940] perl-Pod-Simple-3.28 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=959940 --- Comment #1 from Fedora Admin XMLRPC Client fedora-admin-xml...@redhat.com --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. -- 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=v9Udm5YXyGa=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 959943] perl-Test-Pod-1.48 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=959943 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com Assignee|mmasl...@redhat.com |psab...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=7nSCpBKd3za=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Test-Pod-1.48.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Test-Pod: c6bfd00ccdcb417d68fb3c0a0ec884c8 Test-Pod-1.48.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Pod] 1.48 bump, Pod::Simple compatibility enhancements
commit c9f426d54d2bdbfdf8cdef83a8b71741ae590191
Author: Petr Šabata con...@redhat.com
Date: Mon May 6 12:36:02 2013 +0200
1.48 bump, Pod::Simple compatibility enhancements
.gitignore |1 +
perl-Test-Pod.spec | 25 +++--
sources|2 +-
3 files changed, 13 insertions(+), 15 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4e46822..8c87b0c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
Test-Pod-1.44.tar.gz
/Test-Pod-1.45.tar.gz
/Test-Pod-1.46.tar.gz
+/Test-Pod-1.48.tar.gz
diff --git a/perl-Test-Pod.spec b/perl-Test-Pod.spec
index 03033e4..a4541f9 100644
--- a/perl-Test-Pod.spec
+++ b/perl-Test-Pod.spec
@@ -1,20 +1,22 @@
Name: perl-Test-Pod
-Version:1.46
+Version:1.48
Release:1%{?dist}
Summary:Test POD files for correctness
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Test-Pod/
Source0:
http://search.cpan.org/CPAN/authors/id/D/DW/DWHEELER/Test-Pod-%{version}.tar.gz
-
BuildArch: noarch
+BuildRequires: perl
BuildRequires: perl(File::Find)
BuildRequires: perl(Module::Build) = 0.30
BuildRequires: perl(Pod::Simple) = 3.05
+BuildRequires: perl(strict)
BuildRequires: perl(Test::Builder)
BuildRequires: perl(Test::Builder::Tester) = 1.02
BuildRequires: perl(Test::More) = 0.62
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+BuildRequires: perl(warnings)
+Requires: perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo
$version))
Requires: perl(Pod::Simple) = 3.05
Requires: perl(Test::Builder::Tester) = 1.02
Requires: perl(Test::More) = 0.62
@@ -23,34 +25,29 @@ Requires: perl(Test::More) = 0.62
Check POD files for errors or warnings in a test file, using Pod::Simple to do
the heavy lifting.
-
%prep
%setup -q -n Test-Pod-%{version}
-
%build
-%{__perl} Build.PL installdirs=vendor
+perl Build.PL installdirs=vendor
./Build
-
%install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} \; 2/dev/null
-%{_fixperms} $RPM_BUILD_ROOT
-
+./Build install destdir=%{buildroot} create_packlist=0
+%{_fixperms} %{buildroot}
%check
LC_ALL=C ./Build test
-
%files
-%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/Test/
%{_mandir}/man3/Test::Pod.3pm*
-
%changelog
+* Mon May 06 2013 Petr Šabata con...@redhat.com - 1.48-1
+- 1.48 bump, Pod::Simple compatibility enhancements
+
* Mon Feb 18 2013 Jitka Plesnikova jples...@redhat.com - 1.46-1
- 1.46 bump
diff --git a/sources b/sources
index 4227afa..bc79302 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-fd76af5f32b4a5991a233ac9b1c4aaea Test-Pod-1.46.tar.gz
+c6bfd00ccdcb417d68fb3c0a0ec884c8 Test-Pod-1.48.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 959944] perl-Test-Smoke-1.59 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=959944 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||jples...@redhat.com Assignee|mmasl...@redhat.com |jples...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=4WFCZej4f2a=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 959943] perl-Test-Pod-1.48 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=959943 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Test-Pod-1.48-1.fc20 Resolution|--- |RAWHIDE Last Closed||2013-05-06 07:04:06 -- 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=lDuCXmWrs2a=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 959937] perl-App-cpanminus-1.6911 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=959937 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC|mmasl...@redhat.com |ppi...@redhat.com Assignee|mmasl...@redhat.com |ppi...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=S9YBSehQ9Sa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File App-cpanminus-1.6911.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-App-cpanminus: 1b57020851ae62c6f367a022e8a2eebf App-cpanminus-1.6911.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-App-cpanminus] 1.6911 bump
commit 43ec5f7d3047b366d59f4435f084cf25503b952d
Author: Petr Písař ppi...@redhat.com
Date: Mon May 6 13:09:22 2013 +0200
1.6911 bump
.gitignore |1 +
perl-App-cpanminus.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a0bd9dd..fd9e38b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -48,3 +48,4 @@ App-cpanminus-0.9935.tar.gz
/App-cpanminus-1.6902.tar.gz
/App-cpanminus-1.6907.tar.gz
/App-cpanminus-1.6909.tar.gz
+/App-cpanminus-1.6911.tar.gz
diff --git a/perl-App-cpanminus.spec b/perl-App-cpanminus.spec
index 1c9d8bb..55df95c 100644
--- a/perl-App-cpanminus.spec
+++ b/perl-App-cpanminus.spec
@@ -1,5 +1,5 @@
Name: perl-App-cpanminus
-Version:1.6909
+Version:1.6911
Release:1%{?dist}
Summary:Get, unpack, build and install CPAN modules
License:GPL+ or Artistic
@@ -93,6 +93,9 @@ make test
%{_bindir}/cpanm
%changelog
+* Mon May 06 2013 Petr Pisar ppi...@redhat.com - 1.6911-1
+- 1.6911 bump
+
* Thu May 02 2013 Jitka Plesnikova jples...@redhat.com - 1.6909-1
- 1.6909 bump
diff --git a/sources b/sources
index 3534329..457cac3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ad8117facc94c98023cd0dfe5c07511f App-cpanminus-1.6909.tar.gz
+1b57020851ae62c6f367a022e8a2eebf App-cpanminus-1.6911.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 959937] perl-App-cpanminus-1.6911 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=959937 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-App-cpanminus-1.6911-1 ||.fc20 Resolution|--- |RAWHIDE Last Closed||2013-05-06 07:16:44 -- 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=YfiljelIVfa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the rawhide tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) 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-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the rawhide tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) 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
