Re: Making Fedora work with laptops on docking station with external monitor
On Wed, Oct 06, 2010 at 02:31:22PM -0700, Adam Williamson wrote: On Wed, 2010-10-06 at 23:32 +0300, Pasi Kärkkäinen wrote: What's the worst thing that can happen when trusting the ACPI lid state? Think about this: - Laptop lid open (so internal lvds enabled), and also external monitor connected. - lid state is wrong at boot, so it says lid closed. - Scripts check: lid closed, external display enabled - use only external monitor. That gives you a working setup, you can login using the external display, and use the system perfectly fine. You can then manually enable the internal lvds display, or possibly enable some workaround, as you have a buggy laptop/driver/bios. That doesn't sound bad at all. However, it's not the worst case. The worst case is if someone has an external monitor connected which they're not actually using (it may be hidden or being used with some other input or just turned off). This does happen: https://bugzilla.redhat.com/show_bug.cgi?id=582525 that bug is already inconvenient for some people; if they have laptops with bad lid switches it'd be much more inconvenient. The only active display would be the external display they weren't actually using. I read that bugzilla as it's a driver bug.. so it'll get fixed at some point. We should define policy based on wanted behaviour, not based on various bugs out there.. Bugs need to be fixed, and then the policy works like it's expected. atm we're lacking a policy regarding these laptop lid/dock things. Ie. there's no daemon/script even trying to do the right thing.. (drm/kms driver guys have made it clear the policy has to be decided and set up by userspace). For the transition period we could have a boot/grub menu item that automatically enables the old behaviour for people who have hardware with buggy bios/drivers. Just like we have the safe (vesa) graphics boot option on install CDs. Does this make sense? -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg koji error
Try verbose variant to figure out what happened: $ fedpkg -v scratch-build 06.10.2010 13:19, Farkas Levente wrote: hi, while try to make a scratch build i always got: - # fedpkg scratch-build Could not log into koji: Opening a SSL connection failed - even if i try to remove .fedora.cert and fedora-packager-setup (so it's not a certificate problem). what else can be the reason? thanks in advance. regards. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On 10/06/2010 08:31 PM, Richard W.M. Jones wrote: Seems quite complex. What's wrong with a directory: /etc/iptables.d/ where RPMs like libvirt just drop the required additional rules (in a separate chain if you like) and restart the iptables service? It's low-tech but simple and it's all that libvirt needs. Rich. I have thought a lot about the iptables.d directory. It is a nice thing if your firewall is static and there are no dynamic elements like wireless networks or services or programs requesting to open a port and also if the rule representation would be non-ambiguous. Saving the rules with service ip*tables save is hard to do with this because you you have to check if the rules in the firewall match rules in one or more of the files to prevent to have double, triple, .. rules every time you are saving them. The biggest problem here is though that ip*tables are reformatting and also changing parameters from the external to the internal representation (see icmp types, marks, insert id's, addresses, .. ). If you are saving, then you will get the internal representation, which might be different to the one you have in the file. Therefore simple rule matching is impossible to decide if the rule is the same or not. You have to actively parse and compare every single parameter. Insert id's for example are completely lost in the internal representation. Using the ip*tables commands to add and remove rules is working, because it does not matter if you are using names or id's and so on, because it matches the internal representation in netfilter. Ciao, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On 10/07/2010 02:20 AM, Genes MailLists wrote: On 10/06/2010 11:26 AM, Thomas Woerner wrote: 6) Compatibility Mode The current static firewall model will still be available for compatibility for users or administrators creating their own firewall. This deactivates the firewall service and also the D-BUS daemon. --- Comments and additional information is highly welcome. I hope by 'compatibility mode' you mean it is 'completely off' and there is no possibility of it touching the rules because its not running in any form. Its vital for those of us who have hand coded firewall rules that this is totally turned off and it is impossible for it to touch the rules. In my case, I have about 40,000 rules and I def don't want anything else mucking with them! Thanks - its an interesting idea and the default firewall could use some spiffing up for many use cases. Yes, the compatibility mode means that the dynamic daemon is disabled and the current system-config-firewall, ip*tables and ebtables services will still be availabe to be able to have an own and/or static firewall setup. The only question here is what the default should be in the furture. I think for desktop installations it should be the daemon and for servers the static model. Firstboot, installation time or first network usage is a good place to define this in my opinion. Ciao, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg koji error
On Wed, 06 Oct 2010 11:19:21 +0200 Farkas Levente wrote: hi, while try to make a scratch build i always got: - # fedpkg scratch-build Could not log into koji: Opening a SSL connection failed - even if i try to remove .fedora.cert and fedora-packager-setup (so it's not a certificate problem). what else can be the reason? thanks in advance. regards. This is because the ssl_login to koji failed, so your SSL key is expired. Generate a new one and upload it to fas: https://admin.fedoraproject.org/accounts/ After waiting an hour or something, it should work again (I hope). Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On Wed, 2010-10-06 at 17:26 +0200, Thomas Woerner wrote: It is possible to specify a timeout for a firewall service and also the other features. The service will be opened immediately and closed again after the defined period is over. This allows to accept new connections from unknown sources in the specified time frame. This will be very useful for UPNP, SNMP or NetBIOS for example to find printers or to share data with others. This mechanism is similar to the bluetooth handler in cell phones. This is great news, can't wait to see the interface. Thanks, Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On Wed, 2010-10-06 at 19:31 +0100, Richard W.M. Jones wrote: Seems quite complex. What's wrong with a directory: /etc/iptables.d/ where RPMs like libvirt just drop the required additional rules (in a separate chain if you like) and restart the iptables service? It's low-tech but simple and it's all that libvirt needs. Other applications need more than that. For example, when CUPS wants to detect network printers using SNMP, a query is sent as a UDP packet to the broadcast address(es) from a local unprivileged port to the remote SNMP port, 161. It needs to be able to hear replies. What I was saying in my original post is that there is no simple iptables rule that can be written today to express that, aside from simply allowing all UDP packets to unprivileged ports, obviously not something we want to do. Ideally the kernel would provide a way to express this using a conntrack module. Until that time, however, being able to do this would suffice: * bind() to get a free local unprivileged port * use D-Bus to tell the firewall to allow UDP sport:161 dport:$port for a short time * send query * listen for responses * (optionally) use D-Bus to tell the firewall it can discard that rule now Until bind() is called, no-one knows what local port to allow UDP packets in on. Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]
On 10/6/10, Adam Williamson awill...@redhat.com wrote: On Wed, 2010-10-06 at 16:41 +0200, Ralf Corsepius wrote: However, this here is Fedora, a project that once was aiming at Freedom - As trivial as it is, restrictive trademark policies simply do not fit into this philosophy. If we don't protect the Fedora trademark, anyone can produce anything and call it 'Fedora'. Including something which doesn't fit into our philosophy of freedom at all. It's really pretty simple: we can only define goals and values and blahblah for 'the Fedora project' as long as we actually retain control over 'the Fedora project' (that's we as in the Fedora community, not Red Hat, BTW) and we can only do that if we control the name 'Fedora'. If anyone can make anything and call it 'Fedora', how are people to know what comes from the Fedora project and is backed by its values, and what doesn't? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel What are you guys going to do if someone does it anyway in a country where Redhat hasn't registered the Fedora trademark, or countries where another country already owns the Fedora trademark. Do you think spammers are going to host in the good old US of A? Bad argument. Strawman arguments make bad policy change decisions. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]
I think an exception should be made for Chromium too. Having a more secure browser would benefit the main repositories. On 10/7/10, Brandon Lozza bran...@pwnage.ca wrote: On 10/6/10, Adam Williamson awill...@redhat.com wrote: On Wed, 2010-10-06 at 16:41 +0200, Ralf Corsepius wrote: However, this here is Fedora, a project that once was aiming at Freedom - As trivial as it is, restrictive trademark policies simply do not fit into this philosophy. If we don't protect the Fedora trademark, anyone can produce anything and call it 'Fedora'. Including something which doesn't fit into our philosophy of freedom at all. It's really pretty simple: we can only define goals and values and blahblah for 'the Fedora project' as long as we actually retain control over 'the Fedora project' (that's we as in the Fedora community, not Red Hat, BTW) and we can only do that if we control the name 'Fedora'. If anyone can make anything and call it 'Fedora', how are people to know what comes from the Fedora project and is backed by its values, and what doesn't? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel What are you guys going to do if someone does it anyway in a country where Redhat hasn't registered the Fedora trademark, or countries where another country already owns the Fedora trademark. Do you think spammers are going to host in the good old US of A? Bad argument. Strawman arguments make bad policy change decisions. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101007 changes
...@redhat.com * Fri Aug 06 2010 Rüdiger Landmann r.landm...@redhat.com 2.1-0 - Update Feedback section to link to customer portal pyatspi-1.91.0-1.fc15 - * Tue Oct 05 2010 Matthias Clasen mcla...@redhat.com - 1.91.0-1 - Update to 1.91.0 pypoppler-0.12.1-5.fc15 --- * Wed Oct 06 2010 Tom spot Callaway tcall...@redhat.com - 0.12.1-6 - apply useful fixes from upstream bzr - fix pypoppler against poppler 0.15.0 * Fri Oct 01 2010 Fabian Affolter fab...@bernewireless.net - 0.12.1-5 - Rebuild against new poppler quota-3.17-14.fc15 -- * Wed Oct 06 2010 Petr Pisar ppi...@redhat.com - 1:3.17-14 - Remove quotactl(2) as it's part of `man-pages' package (bug #640590) referencer-1.1.6-8.fc15 --- * Tue Oct 05 2010 Alex Lancaster alexlan[AT]fedoraproject org - 1.1.6-8 - Add patch to fix API to use new poppler 0.15 - Add BR: libSM-devel libICE-devel, need to have them explicitly required * Tue Sep 28 2010 Deji Akingunola dakin...@gmail.com - 1.1.6-7 - Rebuild for poppler-0.15. regexp-1.5-5.fc15 - * Wed Oct 06 2010 Alexander Kurtakov akurt...@redhat.com 0:1.5-5 - Drop gcj support. rekonq-0.6.1-1.fc15 --- * Wed Oct 06 2010 Thomas Janssen thom...@fedoraproject.org 0.6.1-1 - rekonq 0.6.1 resource-agents-3.0.17-1.fc15 - * Thu Oct 07 2010 Fabio M. Di Nitto fdini...@redhat.com - 3.0.17-1 - new upstream release Resolves: rhbz#632595, rhbz#633856, rhbz#632385, rhbz#628013 Resolves: rhbz#621313, rhbz#595383, rhbz#580492, rhbz#605733 Resolves: rhbz#636243, rhbz#591003, rhbz#637913, rhbz#634718 Resolves: rhbz#617247, rhbz#617247, rhbz#617234, rhbz#631943 Resolves: rhbz#639018 * Thu Oct 07 2010 Andrew Beekhof and...@beekhof.net - 3.0.16-2 - new upstream release of the Pacemaker agents: 71b1377f907c rgmanager-3.0.17-1.fc15 --- * Wed Oct 06 2010 Fabio M. Di Nitto fdini...@redhat.com - 3.0.17-1 - new upstream release Resolves: rhbz#632595, rhbz#633856, rhbz#632385, rhbz#628013 Resolves: rhbz#621313, rhbz#595383, rhbz#580492, rhbz#605733 Resolves: rhbz#636243, rhbz#591003, rhbz#637913, rhbz#634718 Resolves: rhbz#617247, rhbz#617247, rhbz#617234, rhbz#631943 Resolves: rhbz#639018 sblim-cmpi-base-1.6.0-1.fc15 * Wed Oct 06 2010 Praveen K Paladugu praveen_palad...@dell.com - 1.6.0-1 - Updated to 1.6.0 - removed the CIMOM dependencies - following the upstream packaging obsolete, sblim-cmpi-base-test pkg. - Added the patches from upstream packaging - fix to restart tog-pegasus properly sblim-cmpi-network-1.4.0-2.fc15 --- * Wed Oct 06 2010 Praveen K Paladugu praveen_palad...@dell.com - 1.4.0-2 - de-registering the providers properly in %pre and %preun * Wed Oct 06 2010 Vitezslav Crhonek vcrho...@redhat.com - 1.4.0-1 - Update to sblim-cmpi-network-1.4.0 - Remove CIMOM dependencies sblim-cmpi-nfsv3-1.1.0-1.fc15 - * Wed Oct 06 2010 Vitezslav Crhonek vcrho...@redhat.com - 1.1.0-1 - Update to sblim-cmpi-nfsv3-1.1.0 - Remove CIMOM dependencies sblim-cmpi-nfsv4-1.1.0-1.fc15 - * Wed Oct 06 2010 Vitezslav Crhonek vcrho...@redhat.com - 1.1.0-1 - Update to sblim-cmpi-nfsv4-1.1.0 - Remove CIMOM dependencies sblim-cmpi-params-1.3.0-1.fc15 -- * Wed Oct 06 2010 Vitezslav Crhonek vcrho...@redhat.com - 1.3.0-1 - Update to sblim-cmpi-params-1.3.0 - Remove CIMOM dependencies sepostgresql-9.0.1-20101007.fc15 * Thu Oct 07 2010 KaiGai Kohei kai...@kaigai.gr.jp - 9.0.1-20101007 - upgrade base version to 9.0.1 subversion-api-docs-1.6.13-1.fc15 - * Thu Oct 07 2010 Bojan Smojver bo...@rexursive.com 1.6.13-1 - bump up to 1.6.13 tcsh-6.17-9.fc15 * Wed Oct 06 2010 Vitezslav Crhonek vcrho...@redhat.com - 6.17-9 - Remove fork when tcsh processes backquotes telepathy-gabble-0.10.3-1.fc15 -- * Wed Oct 06 2010 Brian Pepple bpep...@fedoraproject.org - 0.10.3-1 - Update to 0.10.3. telepathy-salut-0.4.0-1.fc15 * Wed Oct 06 2010 Brian Pepple bpep...@fedoraproject.org - 0.4.0-1 - Update to 0.4.0. tracker-0.8.17-4.fc15 - * Wed Oct 06 2010 Tom spot Callaway tcall...@redhat.com - 0.8.17-4 - fix code for poppler-0.15 * Tue Sep 28 2010 Deji Akingunola dakin...@gmail.com - 0.8.17-3 - Rebuild for poppler-0.15. tuned-0.2.17-1.fc15 --- * Wed Oct 06 2010 Jan Vcelak jvce...@redhat.com 0.2.17-1 - added 'enterprise-storage' profile - added support for architecture-specific configuration files - special sysctl setting for s390x arch in 'throughtput-performance' profile - apply I/O scheduler setting to device mapper devices - workaround for hal-disable-polling bug - fixed problem with network cards that provide unparsable supported network modes (#620686) wsdl4j-1.5.2-8.fc15
F-14 Branched report: 20101007 changes
Compose started at Thu Oct 7 13:15:30 UTC 2010 Broken deps for x86_64 -- almanah-0.7.3-3.fc14.x86_64 requires libedataserverui-1.2.so.10()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgtkjava-2.8.so frysk-devel-0.4-26.fc14.i386 requires libglibjava-0.2.so frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.x86_64 requires libglibjava-0.2.so()(64bit) frysk-devel-0.4-26.fc14.x86_64 requires libgtkjava-2.8.so()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libglibjava-0.2.so()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgtkjava-2.8.so()(64bit) gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires libgpilotdconduit.so.2()(64bit) gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires libgpilotd.so.2()(64bit) gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires libgpilotdcm.so.2()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples libgconf-java-2.12.4-15.fc14.i686 requires libgtkjava-2.8.so libgconf-java-2.12.4-15.fc14.i686 requires libgtkjni-2.8.so libgconf-java-2.12.4-15.fc14.i686 requires libglibjni-0.2.so libgconf-java-2.12.4-15.fc14.i686 requires libglibjava-0.2.so libgconf-java-2.12.4-15.fc14.x86_64 requires libglibjni-0.2.so()(64bit) libgconf-java-2.12.4-15.fc14.x86_64 requires libgtkjni-2.8.so()(64bit) libgconf-java-2.12.4-15.fc14.x86_64 requires libglibjava-0.2.so()(64bit) libgconf-java-2.12.4-15.fc14.x86_64 requires libgtkjava-2.8.so()(64bit) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc php-pecl-imagick-3.0.0-7.fc14.x86_64 requires libMagickWand.so.3()(64bit) php-pecl-imagick-3.0.0-7.fc14.x86_64 requires libMagickCore.so.3()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs = 0:0.8.28 valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0 valide-0.6.1-0.22.20103003svn511.fc14.x86_64 requires libvala.so.0()(64bit) wfut-1.1.0-8.fc12.x86_64 requires libgcj.so.10()(64bit) Broken deps for i386 -- almanah-0.7.3-3.fc14.i686 requires libedataserverui-1.2.so.10 antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 frysk-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.i386 requires libgtkjava-2.8.so frysk-devel-0.4-26.fc14.i386 requires libglibjava-0.2.so frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-gnome-0.4-26.fc14.i386 requires libgtkjava-2.8.so frysk-gnome-0.4-26.fc14.i386 requires libglibjava-0.2.so frysk-gnome-0.4-26.fc14.i386 requires libgcj.so.10 gnome-pilot-conduits-2.0.17-4.fc13.i686 requires libgpilotdcm.so.2 gnome-pilot-conduits-2.0.17-4.fc13.i686 requires libgpilotd.so.2 gnome-pilot-conduits-2.0.17-4.fc13.i686 requires libgpilotdconduit.so.2 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-gtk-0.4.so.0 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-0.4.so.0 intellij-idea-9.0.1.94.399-11.fc14.i686 requires jna-examples libgconf-java-2.12.4-15.fc14.i686 requires libgtkjava-2.8.so libgconf-java-2.12.4-15.fc14.i686 requires libgtkjni-2.8.so libgconf-java-2.12.4-15.fc14.i686 requires libglibjni-0.2.so libgconf-java-2.12.4-15.fc14.i686 requires libglibjava-0.2.so ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc php-pecl-imagick-3.0.0-7.fc14.i686 requires libMagickCore.so.3 php-pecl-imagick-3.0.0-7.fc14.i686 requires libMagickWand.so.3 qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs = 0:0.8.28 valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0 wfut-1.1.0-8.fc12.i686 requires libgcj.so.10 New package: dreampie-1.1-5.fc14 A graphical cross-platform interactive Python shell New package: festival-freebsoft-utils-0.10-1.fc14 A collection of utilities that enhance Festival with some useful features New package: gnustep-examples-1.3.0-3.fc14 The GNUstep examples Removed package: asana-math-fonts-0.914-7.fc12
Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]
On 10/07/2010 08:36 AM, Brandon Lozza wrote: On 10/6/10, Adam Williamsonawill...@redhat.com wrote: If we don't protect the Fedora trademark, anyone can produce anything and call it 'Fedora'. Including something which doesn't fit into our philosophy of freedom at all. What are you guys going to do if someone does it anyway in a country where Redhat hasn't registered the Fedora trademark, or countries where another country already owns the Fedora trademark. Do you think spammers are going to host in the good old US of A? Bad argument. OK, so someone can fool the Elbonians with a bad Fedora distribution. The bad guys will not be able to peddle it anywhere else, because the trademark will protect it, so the majority of Fedora users will be safe from this scam. The system works. Strawman arguments make bad policy change decisions. Indeed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-DateTime-Format-Natural] update to 0.90
commit c7c626e362a1a07ad20af64f9881c6a7dfcd2faf
Author: Iain Arnell iarn...@gmail.com
Date: Thu Oct 7 18:57:20 2010 +0200
update to 0.90
.gitignore|1 +
perl-DateTime-Format-Natural.spec | 19 ---
sources |2 +-
3 files changed, 14 insertions(+), 8 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a82d80b..de6c8f3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
DateTime-Format-Natural-0.88.tar.gz
DateTime-Format-Natural-0.89.tar.gz
+/DateTime-Format-Natural-0.90.tar.gz
diff --git a/perl-DateTime-Format-Natural.spec
b/perl-DateTime-Format-Natural.spec
index 30b1bdf..4e7295b 100644
--- a/perl-DateTime-Format-Natural.spec
+++ b/perl-DateTime-Format-Natural.spec
@@ -1,20 +1,26 @@
Name: perl-DateTime-Format-Natural
-Version:0.89
+Version:0.90
Release:1%{?dist}
Summary:Create machine readable date/time with natural parsing logic
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/DateTime-Format-Natural/
Source0:
http://www.cpan.org/authors/id/S/SC/SCHUBIGER/DateTime-Format-Natural-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(boolean)
+BuildRequires: perl(Carp)
BuildRequires: perl(Class::ISA)
+BuildRequires: perl(DateTime)
BuildRequires: perl(Date::Calc)
BuildRequires: perl(DateTime)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(Getopt::Long)
BuildRequires: perl(List::MoreUtils)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Params::Validate)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Storable)
+BuildRequires: perl(Term::ReadLine)
BuildRequires: perl(Test::MockTime)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod) = 1.14
@@ -38,8 +44,6 @@ done
./Build
%install
-rm -rf $RPM_BUILD_ROOT
-
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
@@ -48,9 +52,6 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%check
./Build test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%files
%defattr(-,root,root,-)
%doc Changes README
@@ -61,6 +62,10 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Oct 07 2010 Iain Arnell iarn...@gmail.com 0.90-1
+- regular update to latest upstream version
+- clean up spec for modern rpmbuild
+
* Fri Aug 06 2010 Iain Arnell iarn...@gmail.com 0.89-1
- update to latest upstream version
diff --git a/sources b/sources
index 54c406e..2d90e6c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ed130d07703d480dfab47f1129048236 DateTime-Format-Natural-0.89.tar.gz
+f732e429505001cec53ac5269e24f572 DateTime-Format-Natural-0.90.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
Yubikeys are now supported
The Fedora Infrastructure team is happy to announce support for the hardware key authentication device, the yubikey. Users will be able to use their own yubikeys to access some Fedora services, like fedorapeople.org or some web services. Why have we done this? The main purpose was to provide multi-factor authentication to our high security systems. Requiring both a username/password and yubikey otp to access our most sensitive hosts provides an additional layer of security then just username/password alone. Contributors requiring access to these hosts will be provided with a yubikey. These hosts would include, for example, the signing servers. We also decided to allow yubikeys as an authentication option for the larger community to some hosts and services like fedorapeople.org or https://admin.fedoraproject.org/community/. When asked for a password, just use your yubikey to generate a otp instead. Those wishing to use one may purchase a yubikey on their own at: http://yubico.com/products/yubikey/ For more information on how to program your yubikey see the our yubikey howto on the wiki: http://fedoraproject.org/wiki/Infrastruture/Yubikey Implementation work continues to be discussed and put in please but please direct any questions or comments to #fedora-admin on irc.freenode.net or the Infrastructure mailing list - https://admin.fedoraproject.org/mailman/listinfo/infrastructure -Mike ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-DateTime-Format-Natural/f14/master] update to 0.90
Summary of changes: c7c626e... update to 0.90 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DateTime-Format-Natural/f13/master] update to 0.90
Summary of changes: c7c626e... update to 0.90 (*) (*) 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: Making Fedora work with laptops on docking station with external monitor
On Thu, 2010-10-07 at 10:49 +0300, Pasi Kärkkäinen wrote: that bug is already inconvenient for some people; if they have laptops with bad lid switches it'd be much more inconvenient. The only active display would be the external display they weren't actually using. I read that bugzilla as it's a driver bug.. so it'll get fixed at some point. Not really; the driver isn't able to detect if connected monitors are turned on. It's not clear if this is really *theoretically* possible, which is why the report's been closed. And it doesn't cover the case where a connected monitor is powered on but not actually being used for the computer. We should define policy based on wanted behaviour, not based on various bugs out there.. Bugs need to be fixed, and then the policy works like it's expected. In theory, yeah, but in practice, we can't take this to extremes if it means we wind up with people staring at blank screens with no apparent explanation. atm we're lacking a policy regarding these laptop lid/dock things. Ie. there's no daemon/script even trying to do the right thing.. (drm/kms driver guys have made it clear the policy has to be decided and set up by userspace). For the transition period we could have a boot/grub menu item that automatically enables the old behaviour for people who have hardware with buggy bios/drivers. Just like we have the safe (vesa) graphics boot option on install CDs. Does this make sense? No, not really, parameters aren't magic, they can only do things if the drivers / userspace utilities are written with these parameters in mind. I don't believe there's any such framework at present, and besides, we want to have *fewer* icky bootloader menu workarounds, really, not more. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]
On Thu, 2010-10-07 at 08:36 -0400, Brandon Lozza wrote: What are you guys going to do if someone does it anyway in a country where Redhat hasn't registered the Fedora trademark, or countries where another country already owns the Fedora trademark. Do you think spammers are going to host in the good old US of A? Bad argument. Register the trademark there, or do something about it in the US if they distribute whatever it is they're distributing there. Strawman arguments make bad policy change decisions. Er, change? Nothing's changing. The Fedora trademark and the policy on using it has been in place for years. You're the one trying to change things. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review request: Nice-to-have bug process documentation proposal
On Thu, 2010-10-07 at 11:07 -0400, James Laska wrote: All of them. They're mostly modifications of existing pages. I'm not quite sure how you get that they look the same, they're very different. General note ... There are a few broken links on this page. I didn't inspect *all* of them, but it looks like they will resolve once you've moved the documents into their proposed locations. So probably not a big deal, I can understand the desire to not change the links before and after moving the pages into their final location. Yeah, they'll work after the pages are all put live. https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft is a proposed new page which covers the whole nice-to-have review process much as the above proposed page covers the blocker review process. My first reaction looking at the proposed blocker and nth process SOP pages was that they should be combined into a single page, since there is a lot of duplicate document structure/format. But I can't think of any good proposals to offer at the moment that make it better (not worse). It seems you've already been down this route too. Yeah, I went back and forth. If you make them one page some of the phrasing gets very long and clunky and possibly hard to parse, I was happier with it as two pages. Perhaps a reflection on my visual learning habit, I've been playing around with some minor edits of the 2 previous wiki pages that make it a bit easier for me to rapidly locate/grok information without too much reading. Of course, let me know if the edits are too invasive or detract from your intended message. Thanks, I'll revert them all later ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Thu, 2010-10-07 at 13:40 +, Matej Cepl wrote: Martin Sourada, Wed, 06 Oct 2010 22:39:00 +0200: But I have my doubts about mozilla in this regard, after all, proper support on linux does not seem to be high priority for them I just fell the urge to mention here https://bugzilla.mozilla.org/show_bug.cgi?id=577653#c6 That seems extremely stupid, but it's one person's take and the explanations given elsewhere in this thread have been different. Perhaps Mozilla's overall policy is not what this Chris Pearce thinks it is. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Thu, Oct 07, 2010 at 10:17:11AM -0700, Adam Williamson wrote: On Thu, 2010-10-07 at 10:49 +0300, Pasi Kärkkäinen wrote: that bug is already inconvenient for some people; if they have laptops with bad lid switches it'd be much more inconvenient. The only active display would be the external display they weren't actually using. I read that bugzilla as it's a driver bug.. so it'll get fixed at some point. Not really; the driver isn't able to detect if connected monitors are turned on. It's not clear if this is really *theoretically* possible, which is why the report's been closed. And it doesn't cover the case where a connected monitor is powered on but not actually being used for the computer. Hmm... things seem to work always ok on Windows, so it should be possible.. We should define policy based on wanted behaviour, not based on various bugs out there.. Bugs need to be fixed, and then the policy works like it's expected. In theory, yeah, but in practice, we can't take this to extremes if it means we wind up with people staring at blank screens with no apparent explanation. Well, I'm staring at blank screens with the current behaviour.. :) atm we're lacking a policy regarding these laptop lid/dock things. Ie. there's no daemon/script even trying to do the right thing.. (drm/kms driver guys have made it clear the policy has to be decided and set up by userspace). For the transition period we could have a boot/grub menu item that automatically enables the old behaviour for people who have hardware with buggy bios/drivers. Just like we have the safe (vesa) graphics boot option on install CDs. Does this make sense? No, not really, parameters aren't magic, they can only do things if the drivers / userspace utilities are written with these parameters in mind. I don't believe there's any such framework at present, and besides, we want to have *fewer* icky bootloader menu workarounds, really, not more. Ok. But yes, we need some daemon that monitors ACPI lid state, and kms/drm output states, and enables/disables displays based on those. We're clearly lacking that atm. Driver developers have made it clear userspace needs a component that takes care of that. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
Pasi Kärkkäinen píše v Čt 07. 10. 2010 v 22:29 +0300: On Thu, Oct 07, 2010 at 10:17:11AM -0700, Adam Williamson wrote: On Thu, 2010-10-07 at 10:49 +0300, Pasi Kärkkäinen wrote: that bug is already inconvenient for some people; if they have laptops with bad lid switches it'd be much more inconvenient. The only active display would be the external display they weren't actually using. I read that bugzilla as it's a driver bug.. so it'll get fixed at some point. Not really; the driver isn't able to detect if connected monitors are turned on. It's not clear if this is really *theoretically* possible, which is why the report's been closed. And it doesn't cover the case where a connected monitor is powered on but not actually being used for the computer. Hmm... things seem to work always ok on Windows, so it should be possible.. And I dare to call the recent behaviour a regression, because IIRC it worked well until one (not identified) update in F-12. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Sat, Sep 25, 2010 at 01:03:13PM -0600, Kevin Fenzi wrote: On Wed, 22 Sep 2010 22:21:33 +0200 Till Maas opensou...@till.name wrote: Also can someone please explain the practical advantages of requiring the autokarma threshold to approve the ability to push a non critical path update to stable instead of just requiring a net karma sum of 1? I asked for this several times on the Update Policy ticket but did not get any answer: https://fedorahosted.org/fesco/ticket/351#comment:55 I don't know that there are practical advantages, I think it's a implementation detail. I'd be fine to making it allow after +1 for non critical path updates. Could you file a RFE on bodhi for that? (please cc me?) Done: https://fedorahosted.org/bodhi/ticket/488 The practical advantage is that getting updates allowed to be pushed to stable does is disjunct from automatically pushing this update to stable. E.g. even if one is allowed to push the package to stable, one might not want to do it already with only a net karma of one. Regards Till pgpltIU95420Y.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Quick question on building f14 isos?
On Tue, Oct 5, 2010 at 9:14 PM, Jesse Keating jkeat...@redhat.com wrote: There was a change in glibc during the F14 development cycle that requires running a newer kernel in order to run the f14 binaries. You could probably cheat a new kernel onto F11 and then do the pungi compose in a mock chroot of f14 content (I do all the pungi runs in mock chroots anyway). After seeing your mail it spurred me on to trying to find a way to upgrade to f12 - I found some notes on doing this via a series of yum commands after localinstalling the f12 fedora-release rpm. It took a while with a number of dead ends but eventually I managed to find a path through the dependency hell and got all packages updated to f12 - on rebooting I have the system on f12 and have been able to build f14 test DVD install isos from the packages in the development/f14 repo - so I am happy again! Given this is a headless machine running in a quiet corner of the office, and it would have been a while before I could get a monitor attached to it, I am very pleased that it was possible to do the upgrade without direct physical access to the machine. Even at f11 Fedora had great abilities! Roll on f14 release! -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
On Thu, Oct 07, 2010 at 12:04:49 -0500, Mike McGrath mmcgr...@redhat.com wrote: We also decided to allow yubikeys as an authentication option for the larger community to some hosts and services like fedorapeople.org or https://admin.fedoraproject.org/community/. When asked for a password, just use your yubikey to generate a otp instead. Those wishing to use one may purchase a yubikey on their own at: While I won't make this Fudcon, I am wondering if it might be worth getting some idea of what interest there would be for people wanting those and getting a bulk discount and having people pay for them at a Fudcon. It looked like even 10 got you a decent discount. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GNOME notification icons?
Folks, On current rawhide (perhaps caused by upgrade from F14 beta), I'm getting a few weirdly broken icons for notification applets. Those applets then crash when moused over or clicked on with a SEGV that looks to be caused by it not finding the correct icon (I did file an ABRT bug last night for one of these). Anyway, can someone tell me the magic needed to get GTK/GNOME bits to rebuild their icon caches, or wherever these icons are actually coming from? Thanks, and sorry for noise. If that fixes it, I don't need to file individual bugs, etc. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
On Thu, 7 Oct 2010, Bruno Wolff III wrote: On Thu, Oct 07, 2010 at 12:04:49 -0500, Mike McGrath mmcgr...@redhat.com wrote: We also decided to allow yubikeys as an authentication option for the larger community to some hosts and services like fedorapeople.org or https://admin.fedoraproject.org/community/. When asked for a password, just use your yubikey to generate a otp instead. Those wishing to use one may purchase a yubikey on their own at: While I won't make this Fudcon, I am wondering if it might be worth getting some idea of what interest there would be for people wanting those and getting a bulk discount and having people pay for them at a Fudcon. It looked like even 10 got you a decent discount. I do happen to know there's a 40% discount for people via this site: http://forum.wegotserved.com/index.php/topic/9310-discount-on-yubikey-via-securitynow-podcast/ I suspect it'd be worth it to see if we could get one for Fedora. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
On Thu, 7 Oct 2010, Mike McGrath wrote: We also decided to allow yubikeys as an authentication option for the larger community to some hosts and services like fedorapeople.org or https://admin.fedoraproject.org/community/. When asked for a password, just use your yubikey to generate a otp instead. Those wishing to use one may purchase a yubikey on their own at: I suspect it'd be worth it to see if we could get one for Fedora. I have one and I've played with it in fedora. There is however an important catch. The server and the yubikey share the same AES symmetric key. This means that if the yubikey is used for multiple sites by one user, that user is sharing is his private key over various external sites. So if fedoraproject would accept it, and the same user uses this yubikey for another site, and that other site gets hacked, then fedoraproject could be hacked as well. I guess in a way it is like using the same password, but people might not be thinking of that when they have a device on them that they use. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
On Thu, Oct 07, 2010 at 12:04:49PM -0500, Mike McGrath wrote: Implementation work continues to be discussed and put in please but please direct any questions or comments to #fedora-admin on irc.freenode.net or the Infrastructure mailing list - Hello, synchronicity! I was just looking at this for a work project, and my test Yubikeys arrived today. I'm a little disturbed by the pam module in Fedora Rawhide, though -- it seems to segfault on success, which is non-ideal behavior for a security module. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
I'm not a security expert but I understood that the usual way to use these keys was to have one server that the key authenticates with, and further sites would be accessible through openID or similar - so the authentication is always with one server. Using the same device with mutliple servers is possible but increases the possibility of OTP being replayed - since one server is not aware that the other has consumed the OTP. Also my Yubikey can store more than one set of 'secrets' so it's really two keys in one. I have one that authenticates against the 'official' server and the secondary key is used with a private server. Worth considering if you want to use the same physical device over multiple servers. I hope some technical details will be published about the Fedora use of Yubikeys sometime soon. -Cam On Thu, Oct 7, 2010 at 10:51 PM, Paul Wouters p...@xelerance.com wrote: On Thu, 7 Oct 2010, Mike McGrath wrote: We also decided to allow yubikeys as an authentication option for the larger community to some hosts and services like fedorapeople.org or https://admin.fedoraproject.org/community/. When asked for a password, just use your yubikey to generate a otp instead. Those wishing to use one may purchase a yubikey on their own at: I suspect it'd be worth it to see if we could get one for Fedora. I have one and I've played with it in fedora. There is however an important catch. The server and the yubikey share the same AES symmetric key. This means that if the yubikey is used for multiple sites by one user, that user is sharing is his private key over various external sites. So if fedoraproject would accept it, and the same user uses this yubikey for another site, and that other site gets hacked, then fedoraproject could be hacked as well. I guess in a way it is like using the same password, but people might not be thinking of that when they have a device on them that they use. Paul -- 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: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/6/10 1:44 AM, Tim Waugh wrote: On Tue, 2010-10-05 at 15:27 -0700, Jesse Keating wrote: PPS I did not modify my bump script yet to attempt a commit to master and merge to the f14 branch. In the interest of time, I took the easy route and just did commits to the f14 branch. Maintainers can do a merge and fixup after the builds have been done if they wish to have their branches in sync with master once more. For this sort of thing I would have thought that separate commits on whichever branches need changing would be fine. Git's merging (if/when each maintainer decides to merge branches) ought to be able to handle that. I don't think that merging backwards from master to f14 would be a good idea. Wouldn't that bring rawhide-y changes into f14? For example, ghostscript's master branch uses ghostscript-9.00 -- merging master into f14 would cause havoc. Or have I misunderstood what you are saying? Tim. */ For a large number of packages, master and f14/master are identical, as they have been merged together. These packages are kept in sync across the releases, usually when upstream is only putting out bugfix updates and the like. My script did not do anything to detect this kind of scenario and play accordingly, which in this case would have been to make the rebuild bump on master, then merge it back to f14/master. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyuStMACgkQ4v2HLvE71NWrawCfSbZYph918mttaEINTYPbycQe DoEAn1Grs5kcWtb5vbZYy5DBPEIFDTdD =koVt -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/6/10 1:34 AM, Peter Robinson wrote: What happens in a case where the packager is about to push a new version, or there has been a rebuild since the 26th? In this case my script will detect a new build in either dist-f14-updates-candidate or dist-f14-updates-testing, and I'll bump/build and replace the build in an update ticket if it exists. In the case where a packager is /about/ to push a new version but hasn't done the build yet, they should contact me to let me know and I can skip their package. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyuSzIACgkQ4v2HLvE71NXhEwCfbiAO8mkaAdLIzNbJwVb1OQI+ aLkAnR0CE3YKodlbLQToB7S0/teKp+s1 =pgtC -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Chain builds for non-rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/5/10 2:30 PM, Mamoru Tasaka wrote: Well, how about creating dist-f14-for-chainbuild build target and allow people to tag or untag build as/from that tag freely? For example currently http://koji.fedoraproject.org/koji/buildtargetinfo?targetID=67 says that build target dist-f14-kde uses dist-f14-kde tagged packages for buildroot, and built packages are tagged as dist-f14-kde and the destination tag dist-f14-kde is not locked. (and on the other hand build target dist-f14 still exists, using dist-f14-build tagged packages when building but the destination dist-f14 is locked) So as far as I am correct, we can freely do chain-build using dist-f14-kde build target for F-14 packages. And actually this status was used when fixing ImageMagick related dependency breakage on F-14 (see latest ImageMagick group update request on F-14 on bodhi, and tag history on koji for ImageMagick-6.6.4.1-13.fc14, autotrace-0.31.1-24.fc14.1 for example) So creating build target for chain-build purpose only seems reasonable to me. Without creating different tags for each and every build attempt, using a tag like dist-f14-kde would suffer from the same problem as using dist-f14-updates-candidate. That is something could get built and tagged into there, that is later either never shipped in an update, or pulled out of updates-testing due to problems, and we'd be left with any number of other packages that were built using the now dead package. In short, it doesn't actually solve any problems to use a dist-f14-chainbuild like tag. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyuS54ACgkQ4v2HLvE71NVozQCfQusa6/0Ic4l0zIrmntFK0hbu CBcAn1joIneoN8PtuTuxWrXL4AwVEFvW =RFo/ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
On Thu, Oct 7, 2010 at 5:51 PM, Paul Wouters p...@xelerance.com wrote: I have one and I've played with it in fedora. There is however an important catch. The server and the yubikey share the same AES symmetric key. This means that if the yubikey is used for multiple sites by one user, that user is sharing is his private key over various external sites. So if fedoraproject would accept it, and the same user uses this yubikey for another site, and that other site gets hacked, then fedoraproject could be hacked as well. I guess in a way it is like using the same password, but people might not be thinking of that when they have a device on them that they use. Wow, that's a serious weakness. Are we sure about this? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
On 10/7/2010 12:04, Mike McGrath wrote: http://fedoraproject.org/wiki/Infrastruture/Yubikey ^^ Typo alert! ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
On Thu, 7 Oct 2010, Mike McLean wrote: I guess in a way it is like using the same password, but people might not be thinking of that when they have a device on them that they use. Wow, that's a serious weakness. Are we sure about this? http://www.yubico.com/files/Security_Evaluation_2009-09-09.pdf Section 5.2. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
On Thu, 7 Oct 2010, Paul Wouters wrote: On Thu, 7 Oct 2010, Mike McGrath wrote: We also decided to allow yubikeys as an authentication option for the larger community to some hosts and services like fedorapeople.org or https://admin.fedoraproject.org/community/. When asked for a password, just use your yubikey to generate a otp instead. Those wishing to use one may purchase a yubikey on their own at: I suspect it'd be worth it to see if we could get one for Fedora. I have one and I've played with it in fedora. There is however an important catch. The server and the yubikey share the same AES symmetric key. This means that if the yubikey is used for multiple sites by one user, that user is sharing is his private key over various external sites. So if fedoraproject would accept it, and the same user uses this yubikey for another site, and that other site gets hacked, then fedoraproject could be hacked as well. I guess in a way it is like using the same password, but people might not be thinking of that when they have a device on them that they use. My understanding on this is, and I reserve the right to misunderstand this, is that once the AES key is on the yubikey, there is no way to get it off of there. That key is just used to generate OTP's. So if an attacker were to get an OTP they could use it to access fedora resources. But only once (which is kind of the point of the otp). And they'd only be able to use it once if the real user hadn't used it again making the attack window smaller. If you think I am wrong here please do join #fedora-admin on irc.freenode.net and help walk me through an attack. We have staging and development servers setup for such a purpose. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
On 2010-10-07 07:25:47 PM, Mike McLean wrote: On Thu, Oct 7, 2010 at 5:51 PM, Paul Wouters p...@xelerance.com wrote: I have one and I've played with it in fedora. There is however an important catch. The server and the yubikey share the same AES symmetric key. This means that if the yubikey is used for multiple sites by one user, that user is sharing is his private key over various external sites. So if fedoraproject would accept it, and the same user uses this yubikey for another site, and that other site gets hacked, then fedoraproject could be hacked as well. I guess in a way it is like using the same password, but people might not be thinking of that when they have a device on them that they use. Wow, that's a serious weakness. Are we sure about this? In order for this to happen, the user would have to explicitly take down the generated AES key while it is being written to the key and then submit it to the other site. I don't think this is really something we need to worry about. Thanks, Ricky pgpwcmJdIFobI.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
On Thu, 7 Oct 2010, Ricky Zhou wrote: On 2010-10-07 07:25:47 PM, Mike McLean wrote: On Thu, Oct 7, 2010 at 5:51 PM, Paul Wouters p...@xelerance.com wrote: I have one and I've played with it in fedora. There is however an important catch. The server and the yubikey share the same AES symmetric key. This means that if the yubikey is used for multiple sites by one user, that user is sharing is his private key over various external sites. So if fedoraproject would accept it, and the same user uses this yubikey for another site, and that other site gets hacked, then fedoraproject could be hacked as well. I guess in a way it is like using the same password, but people might not be thinking of that when they have a device on them that they use. Wow, that's a serious weakness. Are we sure about this? In order for this to happen, the user would have to explicitly take down the generated AES key while it is being written to the key and then submit it to the other site. I don't think this is really something we need to worry about. I had this atack in mind when I designed the burn script. The key never touches the drive during the burning process s othe attack window here, while real, is very tiny. Certainly safer then typing your username and password everywhere all the time :) -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
On Thu, Oct 07, 2010 at 08:54:12PM -0400, Paul Wouters wrote: I have one and I've played with it in fedora. There is however an important catch. The server and the yubikey share the same AES symmetric key. This means that if the yubikey is used for multiple sites by one user, that user is sharing is his private key over various external sites. So if fedoraproject would accept it, and the same user uses this yubikey for another site, and that other site gets hacked, then fedoraproject could be hacked as well. I guess in a way it is like using the same password, but people might not be thinking of that when they have a device on them that they use. [..] http://www.yubico.com/files/Security_Evaluation_2009-09-09.pdf Section 5.2. So I see what you're saying but I think some people are misinterpreting it. The one time passwords generated by the yubikey can safely be used with multiple services. The thing that is unsafe is using the same AES key with multiple ykksm's. Yubico runs a ykksm for people to use with some third party websites that support yubikeys. The fedoraproject provides its own ykksm server. If you use the same AES key with both of these then if one of the servers is compromised, both are compromised. If you only use your key with one of the ykksm's then you can safely use your otps on other sites and there will be no negative ramifications (other than not being able to authenticate). The newer yubikey hardware has provision for two AES keys but I'm not sure how that works and whether it actually allows you to use separate keys with separate servers. Someone will need to look into this. -Toshio pgpyDN1kNs5ba.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
On Thu, Oct 07, 2010 at 11:30:43PM -0400, Toshio Kuratomi wrote: The newer yubikey hardware has provision for two AES keys but I'm not sure how that works and whether it actually allows you to use separate keys with separate servers. Someone will need to look into this. Yes, separate keys -- basically two separate configurations in one device. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
systemd service timeout with kdump
Folks, It would seem that systemd employs some kind of arbitrary timeout (30 seconds?) by default and will log operation timed out. Terminating if things take longer than this time to start up. I would like to know how to increase this timeout, or to (preferably) disable it entirely. Certain services, such as kdump.service might require some time to recreate their initramfs and will thus never be able to start normally (I'm very surprised if nobody else has seen this type of problem). On rawhide, I am going to look at the systemd code to see if I have options already (the man pages didn't turn up anything) but otherwise I guess I get to run the commands in /etc/init.d/kdump by hand for now :) Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 640752] Broken dependency: perl-Test-Simple-tests-0.94-2.fc14.noarch requires perl-Test-Simple = 0:0.94-2.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=640752 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||iarn...@gmail.com, ||ka...@ucw.cz, ||lkund...@v3.sk, ||mmasl...@redhat.com, ||ppi...@redhat.com, ||psab...@redhat.com, ||rc040...@freenet.de, ||tcall...@redhat.com Component|perl-Test-Simple|perl AssignedTo|cw...@alumni.drew.edu |ppi...@redhat.com --- Comment #3 from Petr Pisar ppi...@redhat.com 2010-10-07 10:21:49 EDT --- I will try to package tests as subpackage of perl.spec to solve this problem. The same problem is in F15 too. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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 Catalyst-Engine-Apache-1.16.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Catalyst-Engine-Apache: 7a7241dadd7c0eb28ce10aeb90c9944e Catalyst-Engine-Apache-1.16.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-Catalyst-Engine-Apache] update to 1.16
commit 8142ca35f9b8dec6c9971241ed0a427b16620888
Author: Iain Arnell iarn...@gmail.com
Date: Thu Oct 7 18:38:56 2010 +0200
update to 1.16
.gitignore |1 +
perl-Catalyst-Engine-Apache.spec | 37 -
sources |2 +-
3 files changed, 18 insertions(+), 22 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index c34bc47..5fb905b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Catalyst-Engine-Apache-1.12.tar.gz
+/Catalyst-Engine-Apache-1.16.tar.gz
diff --git a/perl-Catalyst-Engine-Apache.spec b/perl-Catalyst-Engine-Apache.spec
index 80c0fbe..2aeea10 100644
--- a/perl-Catalyst-Engine-Apache.spec
+++ b/perl-Catalyst-Engine-Apache.spec
@@ -1,19 +1,17 @@
Name: perl-Catalyst-Engine-Apache
-Version:1.12
-Release:6%{?dist}
+Version:1.16
+Release:1%{?dist}
Summary:Catalyst Apache Engines
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Catalyst-Engine-Apache/
-Source0:
http://www.cpan.org/authors/id/A/AG/AGRUNDMA/Catalyst-Engine-Apache-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Source0:
http://www.cpan.org/authors/id/F/FL/FLORA/Catalyst-Engine-Apache-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl(Catalyst::Runtime)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
-# t/03podcoverage.t fails
-# BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(Test::Pod::Coverage)
Requires: perl(Catalyst::Runtime)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -28,34 +26,31 @@ These classes provide mod_perl support for Catalyst.
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
+make pure_install PERL_INSTALL_ROOT=%{buildroot}
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
# remove MP13 and MP19 as they are not used in Fedora
-find $RPM_BUILD_ROOT -type f -name '*MP13.*' -exec rm -f {} \;
-find $RPM_BUILD_ROOT -type f -name '*MP19.*' -exec rm -f {} \;
+find %{buildroot} -type f -name '*MP13.*' -exec rm -f {} \;
+find %{buildroot} -type f -name '*MP19.*' -exec rm -f {} \;
-%{_fixperms} $RPM_BUILD_ROOT/*
+%{_fixperms} %{buildroot}/*
%check
-# t/03podcoverage.t fails
-rm t/03podcoverage.t
-TEST_POD=1 make test
-
-%clean
-rm -rf $RPM_BUILD_ROOT
+make test
%files
%defattr(-,root,root,-)
-%doc Changes README
+%doc Changes LICENSE README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Thu Oct 07 2010 Iain Arnell iarn...@gmail.com 1.16-1
+- update to latest upstream
+- clean up spec for modern rpmbuild
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 1.12-6
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index 1f908c9..954fbf3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-00d89cac86ed977428468433389f4c6e Catalyst-Engine-Apache-1.12.tar.gz
+7a7241dadd7c0eb28ce10aeb90c9944e Catalyst-Engine-Apache-1.16.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Clipboard-0.11.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Clipboard: 817e33acc9005b5f0da22bcca2827e7d Clipboard-0.11.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-Clipboard] update to 0.11
commit 9facc87310f1ab7522c4f8788306b6a5296cce08
Author: Iain Arnell iarn...@gmail.com
Date: Thu Oct 7 18:45:52 2010 +0200
update to 0.11
.gitignore |1 +
perl-Clipboard.spec | 14 +-
sources |2 +-
3 files changed, 11 insertions(+), 6 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 799c0ca..1b79887 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Clipboard-0.09.tar.gz
+/Clipboard-0.11.tar.gz
diff --git a/perl-Clipboard.spec b/perl-Clipboard.spec
index 7d37e28..0c0d7ba 100644
--- a/perl-Clipboard.spec
+++ b/perl-Clipboard.spec
@@ -1,6 +1,6 @@
Name: perl-Clipboard
-Version:0.09
-Release:4%{?dist}
+Version:0.11
+Release:1%{?dist}
Summary:Copy and paste with any OS
License:GPL+ or Artistic
Group: Development/Libraries
@@ -9,7 +9,6 @@ Source0:
http://www.cpan.org/authors/id/K/KI/KING/Clipboard-%{version}.ta
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(Spiffy)
BuildRequires: perl(Test::More)
BuildRequires: xclip
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -23,8 +22,8 @@ clipboards are magical.
%prep
%setup -q -n Clipboard-%{version}
-# no need for Win32 or Pb
-rm lib/Clipboard/Pb.pm
+# no need for Win32 or MacPasteboard
+rm lib/Clipboard/MacPasteboard.pm
rm lib/Clipboard/Win32.pm
%build
@@ -56,6 +55,11 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Oct 07 2010 Iain Arnell iarn...@gmail.com 0.11-1
+- update to latest upstream version
+- clean up spec for modern rpmbuild
+- doesn't BR/R perl(Spiffy) any more
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.09-4
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index 06f01be..33a3b0a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-07c48138285eb46f5bfc338630ff4efd Clipboard-0.09.tar.gz
+817e33acc9005b5f0da22bcca2827e7d Clipboard-0.11.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
Yubikeys are now supported
The Fedora Infrastructure team is happy to announce support for the hardware key authentication device, the yubikey. Users will be able to use their own yubikeys to access some Fedora services, like fedorapeople.org or some web services. Why have we done this? The main purpose was to provide multi-factor authentication to our high security systems. Requiring both a username/password and yubikey otp to access our most sensitive hosts provides an additional layer of security then just username/password alone. Contributors requiring access to these hosts will be provided with a yubikey. These hosts would include, for example, the signing servers. We also decided to allow yubikeys as an authentication option for the larger community to some hosts and services like fedorapeople.org or https://admin.fedoraproject.org/community/. When asked for a password, just use your yubikey to generate a otp instead. Those wishing to use one may purchase a yubikey on their own at: http://yubico.com/products/yubikey/ For more information on how to program your yubikey see the our yubikey howto on the wiki: http://fedoraproject.org/wiki/Infrastruture/Yubikey Implementation work continues to be discussed and put in please but please direct any questions or comments to #fedora-admin on irc.freenode.net or the Infrastructure mailing list - https://admin.fedoraproject.org/mailman/listinfo/infrastructure -Mike ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
