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: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On 10/07/2010 12:20 AM, Kevin Fenzi wrote: > How would you suggest wording this? The above is what people might > expect from a F(n-1), but what policy would match these goals? > > ie, how can we explain how F(n-1) is different from F(n) for > maintainers? What updates should be in one and not the other? Updates to F (n-1) must be limited to be fixing security bugs and critical bugs ( where critical bugs are crashes or data loss issues). When an upstream release combines such fixes along with feature changes, work with them to cherry pick changes if possible. Rahul -- 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 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 wrote: > On 10/6/10, Adam Williamson 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
7f907c rgmanager-3.0.17-1.fc15 --- * Wed Oct 06 2010 Fabio M. Di Nitto - 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 - 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 - 1.4.0-2 - de-registering the providers properly in %pre and %preun * Wed Oct 06 2010 Vitezslav Crhonek - 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 - 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 - 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 - 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 - 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 1.6.13-1 - bump up to 1.6.13 tcsh-6.17-9.fc15 * Wed Oct 06 2010 Vitezslav Crhonek - 6.17-9 - Remove fork when tcsh processes backquotes telepathy-gabble-0.10.3-1.fc15 -- * Wed Oct 06 2010 Brian Pepple - 0.10.3-1 - Update to 0.10.3. telepathy-salut-0.4.0-1.fc15 * Wed Oct 06 2010 Brian Pepple - 0.4.0-1 - Update to 0.4.0. tracker-0.8.17-4.fc15 - * Wed Oct 06 2010 Tom "spot" Callaway - 0.8.17-4 - fix code for poppler-0.15 * Tue Sep 28 2010 Deji Akingunola - 0.8.17-3 - Rebuild for poppler-0.15. tuned-0.2.17-1.fc15 --- * Wed Oct 06 2010 Jan Vcelak 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 --- * Wed Oct 06 2010 Alexander Kurtakov 0:1.5.2-8 - Drop gcj support. - Fix groups. * Mon May 31 2010 Ville Skyttä - 0:1.5.2-7.7 - Fix specfile encoding. zathura-0.0.8.1-7.fc15 -- * Wed Oct 06 2010 Tom "spot" Callaway - 0.0.8.1-7 - rebuild and fix for new poppler Summary: Added Packages: 6 Removed Packages: 0 Modified Packages: 95 -- 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
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 and http://en.wikipedia.org/wiki/Hanlon%27s_razor -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. -- R. P. Feynman's concluding sentence in his appendix to the Challenger Report -- 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 Wed, 2010-10-06 at 12:32 -0700, Adam Williamson wrote: > On Wed, 2010-10-06 at 14:58 -0400, John Poelstra wrote: > > Adam Williamson said the following on 10/06/2010 01:32 PM Pacific Time: > > > On Thu, 2010-09-23 at 12:58 +0100, Adam Williamson wrote: > > >> Hi, everyone. So we partly used the proposed new nice-to-have bug > > >> tracking system during the F14 Beta process, and it seemed to go well. > > >> In a quick burst of airport productivity, I've quickly written up a > > >> bunch of proposed new wiki pages and modifications to existing ones to > > >> document the nice-to-have process (and, incidentally, extend > > >> documentation of the blocker process, since we don't seem to have much > > >> of it beyond the blocker meeting SOP right now). All the pages can be > > >> found here: > > >> > > >> https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts > > > > > > Thanks to James for his feedback on this. I haven't had much feedback > > > from anyone else. However, given that in practice everyone involved in > > > the release review process has been happy using the NTH system drafted > > > here so far, I intend to make the draft changes final (with > > > modifications to reflect James' feedback) by the end of the week, so if > > > you have any feedback you've been sitting on, now would be the perfect > > > time to send it :) Thanks everyone! > > > > Can you be more specific as to which page we are actually giving > > feedback on? There are five of them there and they almost all look the > > same. > > 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. > https://fedoraproject.org/wiki/User:Adamwill/Draft_desktop_results_nth_adjust > is a proposed change to > https://fedoraproject.org/wiki/QA:Desktop_validation_results_template . Good stuff. > https://fedoraproject.org/wiki/User:Adamwill/Draft_desktop_validation_nth_adjust > is a proposed change to > https://fedoraproject.org/wiki/QA:Desktop_validation_testing . Same as above, equally as wholesome :) > https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_blocker_bug_meeting_nth_draft > is a proposed change to > https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting . > > https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_blocker_bug_process_nth_draft > is a proposed new page; it's not particularly specific to the nice-to-have > proposal, actually, it just became apparent while I was doing this that we > have no page which explains the entire blocker bug review process, and we > should have one. This is it. Funny how when you've been involved in a process for a while, you forget which parts aren't clearly documented/described for others to engage. Nice addition. > 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. 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. > I included a summary of the whole proposed NTH process in my initial > review request mail. These are the wiki changes necessary to document > that process. Thanks, James signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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.fc1
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 Williamson 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
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 0.90-1
+- regular update to latest upstream version
+- clean up spec for modern rpmbuild
+
* Fri Aug 06 2010 Iain Arnell 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 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 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 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
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 > and > http://en.wikipedia.org/wiki/Hanlon%27s_razor Good point. But I vaguely recall a few years (is it so long already?) when the html5 thing was starting there was a bug in mozilla's bugzilla to allow use of system libvorbis (or maybe some other html5 video related one) with the same reaction, but after all, it might be the same person... Anyway, don't feel any weight in my statement, it's just remnants of past frustration with having to use rpath for mozplugins (and thus rebuild for every firefox release, even though the api/abi remained same) softly reinforced by the fact that now you don't need rpath, but unless someone announces API/ABI changes, you'll notice them only after someone fills a bug that your plugin does not work (yes, this is precisely the kind of thing that could be caught by usual dependency check if mozilla used properly versioned libraries...) Plus, I believe I said it a few months (maybe years) back, but I don't like that mozilla decided to use the codecs directly (instead of using platform dependent framework like gstreamer), not to mention they bundle their own patched versions... Anyway, I hope you manage to solve this problem soon :) Martin signature.asc Description: This is a digitally signed message part -- 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 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 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 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 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 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 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 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
On Thu, 7 Oct 2010, Toshio Kuratomi wrote: > 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). That's what I understood yes. It also means you have to trust any other provider (without a compromise). It also makes the server a target to obtain the AES secrets to try elsewhere. In some sense, an md5 hashed password has less value when taken from a compromised server, as it would still need to be brute forced. > 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. I think by pressing down the 1 button for more then 2 seconds, you get the second key. I am not sure if I have such a key (mine is about a year old) I really like the concept of the yubikey - that is the USB keyboard as input method. My company decided not to add this to our products because of the concern of symmetric crypto used. It would be perfect if it had some kind of public key based system like RSA or DSA. One usage of yubikey I would like very much is as storage for the AES encryption key for disk encryption. I'd prefer the disk crypto key to not be on the disk at all, protected by just a passphrase. It would be nice to have it on a yubikey instead. Paul 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, Mike McGrath wrote: > 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. That's right. And since fedora is not using the yubikey as an audit trail, this is fine - anyone with root could obtain anyone AES key and "clone" a yubikey and login as someone else. You might only see some people who know how yubikeys work decide on sticking to one device for multiple services which are not aware they are sharing the same AES key. But it is a clear distinction from say ssh public keys, where I can give everyone my public ssh key without needing to trust the remote party at all (provided I don't use ssh -A to their servers) Paul -- 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
Re: Yubikeys are now supported
On Fri, Oct 08, 2010 at 12:07:34AM -0400, Matthew Miller wrote: > 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. > After a bit of trial and error, I got this working. I now have my yubikey-v2 to send a otp that's associated with fas if I hold the contact for 0.3 – 1.5 seconds and a otp that's registered with yubico's servers if I press for 2.5 – 5 seconds. The sparsity of introductory docs on ykpersonalize made this harder than it should have been. I pieced together the necessary information from this page: http://www.teaparty.net/technotes/yubikey.html and the official upload instructions linked from here: http://www.yubico.com/developers/aeskeys/ and the user's manual http://yubico.com/files/YubiKey_manual-2.0.pdf Writing the second key slot was kinda like this: sudo ykpersonalize -2 -o fixed=vv -a KEY -o -static-ticket -o -strong-pw1 -o -strong-pw2 -o -man-update -o -append-cr -ouid=Y Figuring out ,KEY, and YYY were what I needed to read those documents for. -Toshio pgpBteuQ7TONB.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
