Re: SPDY in F18 (was Re: F17 httpd 2.4?)
On 03/27/2012 09:46 PM, Michał Piotrowski wrote: > W dniu 21 marca 2012 15:13 użytkownik Michał Piotrowski > napisał: >> 2012/3/21 Peter Robinson : > [..] >>> There's nothing stopping you from packaging up mod_spdy or any other >>> modules that add support for the protocol. >> >> I will try tomorrow - I've got mod_fcgid package sources for reference. >> >> Who can mod_spdy if I make the spec file for this? > > I wanted to write "Who can adopt mod_spdy" :) > > I created a feature page > https://fedoraproject.org/wiki/Features/F18SPDY > > If someone accidentally did not know what SPDY is - there is a link to > interesting video from GoogleTechTalks on this page. > > I also created an initial version of spec file for mod_spdy that can > be found at this repo https://github.com/eventhorizonpl/mod_spdy > That mod_ssl_with_npn.so hack looks pretty dodgy to me. Does that even work? Have you tested this together with the regular mod_ssl that comes with the httpd package? I cannot see how both modules can coexist. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting minutes FESCo (2012-03-26)
On Tue, Mar 27, 2012 at 2:40 PM, Adam Williamson wrote: > On Tue, 2012-03-27 at 14:33 -0500, Jon Ciesla wrote: > >> >> If you think this is a good example, I'll edit the page to fix those >> >> issues. >> >> >> >> http://lists.fedoraproject.org/pipermail/devel/2012-March/163885.html >> > >> > I'd probably pick one which doesn't have an extra 'note' in the subject. >> > Never underestimate the idiocy of crowds. ;) >> >> I put the subject in the template. :) >> >> How about this one? >> >> http://lists.fedoraproject.org/pipermail/devel/2012-January/161463.html > > It has a rather different subject from the other one, doesn't it? =) > > Really, either would be fine, I'm just nitpicking. Pick one and go with > it. Any template + specific requirement for subject line + example link > would be better than the present contents. Done. If this needs tweaking, let me know. -J > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SPDY in F18 (was Re: F17 httpd 2.4?)
W dniu 21 marca 2012 15:13 użytkownik Michał Piotrowski napisał: > 2012/3/21 Peter Robinson : [..] >> There's nothing stopping you from packaging up mod_spdy or any other >> modules that add support for the protocol. > > I will try tomorrow - I've got mod_fcgid package sources for reference. > > Who can mod_spdy if I make the spec file for this? I wanted to write "Who can adopt mod_spdy" :) I created a feature page https://fedoraproject.org/wiki/Features/F18SPDY If someone accidentally did not know what SPDY is - there is a link to interesting video from GoogleTechTalks on this page. I also created an initial version of spec file for mod_spdy that can be found at this repo https://github.com/eventhorizonpl/mod_spdy -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting minutes FESCo (2012-03-26)
On Tue, 2012-03-27 at 14:33 -0500, Jon Ciesla wrote: > >> If you think this is a good example, I'll edit the page to fix those > >> issues. > >> > >> http://lists.fedoraproject.org/pipermail/devel/2012-March/163885.html > > > > I'd probably pick one which doesn't have an extra 'note' in the subject. > > Never underestimate the idiocy of crowds. ;) > > I put the subject in the template. :) > > How about this one? > > http://lists.fedoraproject.org/pipermail/devel/2012-January/161463.html It has a rather different subject from the other one, doesn't it? =) Really, either would be fine, I'm just nitpicking. Pick one and go with it. Any template + specific requirement for subject line + example link would be better than the present contents. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting minutes FESCo (2012-03-26)
On Tue, Mar 27, 2012 at 2:20 PM, Adam Williamson wrote: > On Tue, 2012-03-27 at 13:48 -0500, Jon Ciesla wrote: >> On Tue, Mar 27, 2012 at 1:41 PM, Adam Williamson wrote: >> > On Tue, 2012-03-27 at 13:19 -0500, Jon Ciesla wrote: >> >> On Tue, Mar 27, 2012 at 1:16 PM, Adam Williamson >> >> wrote: >> >> > On Mon, 2012-03-26 at 21:17 +0200, Marcela Mašláňová wrote: >> >> > >> >> > Could I suggest that, if FESCo is going to have a different chair each >> >> > week, you at least have an SOP for arranging the meetings, so that this >> >> > kind of thing is done consistently? >> >> >> >> We do. >> >> >> >> https://fedoraproject.org/wiki/FESCo_meeting_process >> >> >> >> > Just in the last two weeks we've had a FESCo meeting announcement with >> >> > an empty topic, and now a minutes post with a different subject from all >> >> > the previous minutes posts (the 'standard' appears to be "Summary & >> >> > minutes for today's FESCo meeting (-XX-XX)") and with no text but an >> >> > *attachment* of the meetbot summary. >> >> > >> >> > It looks rather unprofessional, to be honest. >> >> >> >> I suggest we all pay a bit better attention to it, including myself. >> > >> > Heh. >> > >> > The SOP does not, however, specify the correct topic for either email. >> > It provides a template for the 'announcement' mail, but no template for >> > the 'minutes' mail. It does not provide a link to an example of either >> > mail. >> >> If you think this is a good example, I'll edit the page to fix those issues. >> >> http://lists.fedoraproject.org/pipermail/devel/2012-March/163885.html > > I'd probably pick one which doesn't have an extra 'note' in the subject. > Never underestimate the idiocy of crowds. ;) I put the subject in the template. :) How about this one? http://lists.fedoraproject.org/pipermail/devel/2012-January/161463.html -J > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On 03/27/2012 05:15 PM, Kevin Kofler wrote: I think "removing the legacy cruft" just for the goal of removing it is not helpful at all and is actually the main cause of "half baked", "half removed" stuff in Fedora. Interesting how did you come to that conclusion? I assume that that mod_access_compat module only requires a few bytes, so I don't see why it should not be loaded by default forever (or at least as long as upstream supports it, which hopefully will be for the whole 2.4 cycle). Few bytes for mod_access_compat here, few bytes for something else there Of course, web app packages in Fedora itself SHOULD be updated to the new directives, but that's not a reason to gratuitously break the old ones. It's my experience that things dont seem to get fixed unless they are broken and what "compat" does is just delaying the inevitable... Those web app maintainers that actually bother to monitor upstream have already made the necessary changes to their relevant component and did so as soon as 2.4 got release and probably are just waiting until we start shipping 2.4. It's those that dont and they will drag their feets in doing so until that compatibility is removed... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting minutes FESCo (2012-03-26)
On Tue, 2012-03-27 at 13:48 -0500, Jon Ciesla wrote: > On Tue, Mar 27, 2012 at 1:41 PM, Adam Williamson wrote: > > On Tue, 2012-03-27 at 13:19 -0500, Jon Ciesla wrote: > >> On Tue, Mar 27, 2012 at 1:16 PM, Adam Williamson > >> wrote: > >> > On Mon, 2012-03-26 at 21:17 +0200, Marcela Mašláňová wrote: > >> > > >> > Could I suggest that, if FESCo is going to have a different chair each > >> > week, you at least have an SOP for arranging the meetings, so that this > >> > kind of thing is done consistently? > >> > >> We do. > >> > >> https://fedoraproject.org/wiki/FESCo_meeting_process > >> > >> > Just in the last two weeks we've had a FESCo meeting announcement with > >> > an empty topic, and now a minutes post with a different subject from all > >> > the previous minutes posts (the 'standard' appears to be "Summary & > >> > minutes for today's FESCo meeting (-XX-XX)") and with no text but an > >> > *attachment* of the meetbot summary. > >> > > >> > It looks rather unprofessional, to be honest. > >> > >> I suggest we all pay a bit better attention to it, including myself. > > > > Heh. > > > > The SOP does not, however, specify the correct topic for either email. > > It provides a template for the 'announcement' mail, but no template for > > the 'minutes' mail. It does not provide a link to an example of either > > mail. > > If you think this is a good example, I'll edit the page to fix those issues. > > http://lists.fedoraproject.org/pipermail/devel/2012-March/163885.html I'd probably pick one which doesn't have an extra 'note' in the subject. Never underestimate the idiocy of crowds. ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting minutes FESCo (2012-03-26)
On Tue, Mar 27, 2012 at 1:41 PM, Adam Williamson wrote: > On Tue, 2012-03-27 at 13:19 -0500, Jon Ciesla wrote: >> On Tue, Mar 27, 2012 at 1:16 PM, Adam Williamson wrote: >> > On Mon, 2012-03-26 at 21:17 +0200, Marcela Mašláňová wrote: >> > >> > Could I suggest that, if FESCo is going to have a different chair each >> > week, you at least have an SOP for arranging the meetings, so that this >> > kind of thing is done consistently? >> >> We do. >> >> https://fedoraproject.org/wiki/FESCo_meeting_process >> >> > Just in the last two weeks we've had a FESCo meeting announcement with >> > an empty topic, and now a minutes post with a different subject from all >> > the previous minutes posts (the 'standard' appears to be "Summary & >> > minutes for today's FESCo meeting (-XX-XX)") and with no text but an >> > *attachment* of the meetbot summary. >> > >> > It looks rather unprofessional, to be honest. >> >> I suggest we all pay a bit better attention to it, including myself. > > Heh. > > The SOP does not, however, specify the correct topic for either email. > It provides a template for the 'announcement' mail, but no template for > the 'minutes' mail. It does not provide a link to an example of either > mail. If you think this is a good example, I'll edit the page to fix those issues. http://lists.fedoraproject.org/pipermail/devel/2012-March/163885.html -J > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: Connotation analysis for Fedora Project codenames
On Tue, 27 Mar 2012, Kevin Kofler wrote: My proposal is to just stop using release codenames NOW, including removing the name for Fedora 17 +1 The names are useless. I can't even remember them because they seem so arbitrary. At least the names on Ubuntu give you some indication of which is older/newer. If names are really needed, make them based on the most important new features of the release. For instance, if F18's main new feature would be a new integrity meassurement system, you can call the release Sherlock Holmes :P Or if the next release would allow ECC, you can call the release Elliptic Conundrum :P Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Net-Twitter] Initial import (#611372).
commit 3c2e5d5cee03f667c90e2ef78dcc6410299bf437
Author: Julian C. Dunn
Date: Tue Mar 27 14:42:59 2012 -0400
Initial import (#611372).
.gitignore|1 +
perl-Net-Twitter.spec | 82 +
sources |1 +
3 files changed, 84 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..a10652d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Net-Twitter-3.18001.tar.gz
diff --git a/perl-Net-Twitter.spec b/perl-Net-Twitter.spec
new file mode 100644
index 000..461e4ef
--- /dev/null
+++ b/perl-Net-Twitter.spec
@@ -0,0 +1,82 @@
+Name: perl-Net-Twitter
+Version:3.18001
+Release:1%{?dist}
+Summary:Perl interface to the Twitter API
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Net-Twitter/
+Source0:
http://www.cpan.org/authors/id/M/MM/MMIMS/Net-Twitter-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(base)
+BuildRequires: perl(lib)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Crypt::SSLeay) >= 0.5
+BuildRequires: perl(Data::Visitor::Callback)
+BuildRequires: perl(DateTime) >= 0.51
+BuildRequires: perl(DateTime::Format::Strptime) >= 1.09
+BuildRequires: perl(Devel::StackTrace) >= 1.21
+BuildRequires: perl(Digest::HMAC_SHA1)
+BuildRequires: perl(Digest::SHA)
+BuildRequires: perl(Encode)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(HTML::Entities)
+BuildRequires: perl(HTTP::Request::Common)
+BuildRequires: perl(HTTP::Response)
+BuildRequires: perl(JSON)
+BuildRequires: perl(List::Util)
+BuildRequires: perl(LWP::UserAgent) >= 5.819
+BuildRequires: perl(Moose) >= 0.9
+BuildRequires: perl(Moose::Exporter)
+BuildRequires: perl(Moose::Role)
+BuildRequires: perl(MooseX::Aliases)
+BuildRequires: perl(MooseX::Role::Parameterized)
+BuildRequires: perl(namespace::autoclean) >= 0.09
+BuildRequires: perl(Net::Netrc)
+BuildRequires: perl(Net::OAuth) >= 0.25
+BuildRequires: perl(Pod::Coverage) >= 0.19
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Test::Deep)
+BuildRequires: perl(Test::Fatal)
+BuildRequires: perl(Test::More) >= 0.88
+BuildRequires: perl(Test::Pod) >= 1.00
+BuildRequires: perl(Test::Pod::Coverage) >= 1.04
+BuildRequires: perl(Test::Spelling) >= 0.11
+BuildRequires: perl(Time::HiRes)
+BuildRequires: perl(Try::Tiny) >= 0.03
+BuildRequires: perl(URI) >= 1.4
+BuildRequires: perl(URI::Escape)
+Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+Requires: perl(Net::Netrc)
+
+%description
+This module provides a perl interface to the Twitter APIs. See
+http://dev.twitter.com/doc for a full description of the Twitter APIs.
+
+%prep
+%setup -q -n Net-Twitter-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+
+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 \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+env TEST_POD=1 make test
+
+%files
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Tue Mar 27 2012 Julian C. Dunn 3.18001-1
+- Initial release.
diff --git a/sources b/sources
index e69de29..7158f51 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+88665d245f72b48ee87817edb5906d00 Net-Twitter-3.18001.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
File Net-Twitter-3.18001.tar.gz uploaded to lookaside cache by jdunn
A file has been added to the lookaside cache for perl-Net-Twitter: 88665d245f72b48ee87817edb5906d00 Net-Twitter-3.18001.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Meeting minutes FESCo (2012-03-26)
On Tue, 2012-03-27 at 13:19 -0500, Jon Ciesla wrote: > On Tue, Mar 27, 2012 at 1:16 PM, Adam Williamson wrote: > > On Mon, 2012-03-26 at 21:17 +0200, Marcela Mašláňová wrote: > > > > Could I suggest that, if FESCo is going to have a different chair each > > week, you at least have an SOP for arranging the meetings, so that this > > kind of thing is done consistently? > > We do. > > https://fedoraproject.org/wiki/FESCo_meeting_process > > > Just in the last two weeks we've had a FESCo meeting announcement with > > an empty topic, and now a minutes post with a different subject from all > > the previous minutes posts (the 'standard' appears to be "Summary & > > minutes for today's FESCo meeting (-XX-XX)") and with no text but an > > *attachment* of the meetbot summary. > > > > It looks rather unprofessional, to be honest. > > I suggest we all pay a bit better attention to it, including myself. Heh. The SOP does not, however, specify the correct topic for either email. It provides a template for the 'announcement' mail, but no template for the 'minutes' mail. It does not provide a link to an example of either mail. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
Le 27/03/2012 18:18, Joe Orton a écrit : > Yup - the default config in the f18 httpd does load mod_access_compat, > and I don't see a problem with shipping like that. > > It would be good to convert webapps over for f18, having said that. It seems that mod_access_compat doesn't really work as expected. From my first test, it allow to reduce the default right not to increase it. I Will take phpMyAdmin for example, stock config. By default, access is denied. So even with order deny,allow deny from all allow from 127.0.0.1 allow from ::1 I got an "access denied" (from authz_core) [authz_core:error] [pid 10848] [client ::1:59237] AH01630: client denied by server configuration: /usr/share/phpMyAdmin/, referer: http://localhost/ After adding a trivial default access with Require all granted phpMyAdmin works, and mod_access_compat allow to protect some folders Example, with Order Deny,Allow Deny from All Allow from None I got the expected "access denied" (from access_compat) [access_compat:error] [pid 11130] [client ::1:59330] AH01797: client denied by server configuration: /usr/share/phpMyAdmin/setup/lib/common.inc.php So I mainly see 2 options 1/ allow default access seems really uggly... 2/ fix all web app in fedora 18 just a big job... Perhaps there is another solution... any idea ? Regards, Remi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dependencies on Bodhi Updates
On Mon, 2012-03-26 at 15:53 -0400, Stephen Gallagher wrote: > So I really see two options for improving these situations: > 1) https://fedorahosted.org/bodhi/ticket/663 I opened this ticket two > months ago (to silence). The idea would be to add the ability for bodhi > updates to mark other updates as a dependency, so that in the example > above, Firefox could have been marked as ready for stable, but not > pushed until the nss update was also marked as ready for stable. This to > me seems like the best long-term solution. I'd also like to mention that > Ubuntu's Launchpad system has this capability. > 2) We could continue on the "single update for multiple packages" > approach, but revamp the karma system so that each SRPM gets its own > karma, rather than the update as a whole. Then, the whole update would > not be pushed via autokarma until all of the dependent packages had > sufficient karma (or the owner of the update could push them after the > stable wait period, of course). I think either of these would be an improvement. Both are likely Bodhi 2.0-dependent, though. As I understand the Bodhi 2 design, it would certainly be capable of at least the second (as it's intended to make feedback a much more customizable and granular thing). I think we'd need to make the second more optional than you suggest, though. For instance, when the desktop team pushes a 'GNOME 3.4' update with 30 packages in it, they really want that update to be tested as a whole - broadly they just want people to install all the updates, boot into GNOME, and make sure stuff mostly works. They probably don't want the entire update blocked if there's a typo in the Help file for one of the games, or something. So I think there are cases where an update owner would not want to require the threshold karma on every single sub-package in an update. With that caveat, though, I do like the ideas. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning bibus
On Mon, 2012-03-26 at 16:44 -0400, Alex Lancaster wrote: > Pkgdb link: > > https://admin.fedoraproject.org/pkgdb/acls/name/bibus > > I kept myself on as a co-maintainer, but it deserves a more > proactive main owner. Hi Alex, I've taken ownership: Thank you for maintaining it so far :) -- Thanks, Regards, Ankur: "FranciscoD" http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ 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: Meeting minutes FESCo (2012-03-26)
On Tue, Mar 27, 2012 at 1:16 PM, Adam Williamson wrote: > On Mon, 2012-03-26 at 21:17 +0200, Marcela Mašláňová wrote: > > Could I suggest that, if FESCo is going to have a different chair each > week, you at least have an SOP for arranging the meetings, so that this > kind of thing is done consistently? We do. https://fedoraproject.org/wiki/FESCo_meeting_process > Just in the last two weeks we've had a FESCo meeting announcement with > an empty topic, and now a minutes post with a different subject from all > the previous minutes posts (the 'standard' appears to be "Summary & > minutes for today's FESCo meeting (-XX-XX)") and with no text but an > *attachment* of the meetbot summary. > > It looks rather unprofessional, to be honest. I suggest we all pay a bit better attention to it, including myself. -J > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting minutes FESCo (2012-03-26)
On Mon, 2012-03-26 at 21:17 +0200, Marcela Mašláňová wrote: Could I suggest that, if FESCo is going to have a different chair each week, you at least have an SOP for arranging the meetings, so that this kind of thing is done consistently? Just in the last two weeks we've had a FESCo meeting announcement with an empty topic, and now a minutes post with a different subject from all the previous minutes posts (the 'standard' appears to be "Summary & minutes for today's FESCo meeting (-XX-XX)") and with no text but an *attachment* of the meetbot summary. It looks rather unprofessional, to be honest. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need help with writing a yum plugin
On Tue, Mar 27, 2012 at 1:03 PM, Adam Williamson wrote: > On Sun, 2012-03-25 at 14:51 +0530, Ankur Sinha wrote: >> Hello, >> >> I'm trying to write a yum plug-in: wait-for-kmod >> >> For quite a few users, the kmods from RPMFusion are a must. Take >> broadcom wireless for example. Now, the kmods generally lag the kernel >> updates by a few hours: people who do update their systems in this >> interval are left without wireless/display etc. on reboot. > > That's what the akmods are for... Well yes, but they're not perfect either. If an akmod fails to build it can't stop the kernel from updating (since the transaction is already one) so you can still run into issues and this does happen for various reasons, most recently when some includes got moved for the 3.3 kernel. Although this plugin wouldn't fix that, it would make it easier for most people who don't want to deal with the added complexity and just go back to using kmods. Richard Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need help with writing a yum plugin
On Tue, 2012-03-27 at 11:03 -0700, Adam Williamson wrote: > > That's what the akmods are for... Maybe, but the akmods are not usable in all cases. For instance, you don't want akmods on servers, specially since it pulls in GCC. The akmods do fail once in a while, when the changes between kernels is more than what they can handle. I'd like to spare users the agony of debugging a failed akmod. Debugging "no display/wireless/whatnot on reboot" is quite a handful in itself. Kmods, if fail during builds, fail on RPMFusions servers, not on the users' machines. -- Thanks, Regards, Ankur: "FranciscoD" http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ 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: Booting Fedora from LVM with grub2
On Mon, 2012-03-26 at 21:16 +0200, Kevin Kofler wrote: > Richard W.M. Jones wrote: > > Umm ... okay. > > > > Any particular reason? > > Kickstarts are not very user-friendly nor convenient (unless you have > several machines to install with identical installs, which is what they were > invented for). > > > Any other plans to make the current situation better? > > Even QA-wise, I don't think making such a feature kickstart-only would > improve the situation at all, it'd reduce the testing it gets by a lot. It's worth bearing in mind there's a giant anaconda UI rewrite still pending, which entirely redesigns the storage configuration GUI. One of the other major changes is that it makes all installations kickstart-driven. The GUI will just produce a kickstart file, which anaconda will then process to perform the actual install. It's not a direct response to any of the points raised so far, but it's worth bearing in mind while you're having this argument that F18 anaconda is going to look drastically different from F17 anaconda. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Booting Fedora from LVM with grub2
On Mon, 2012-03-26 at 10:24 +0100, Richard W.M. Jones wrote: > On Sun, Mar 25, 2012 at 11:41:18PM +0200, Kevin Kofler wrote: > > Richard W.M. Jones wrote: > > > Perhaps, like Ubuntu's installer, the graphical part of Anaconda > > > should concentrate on doing the simple stuff, and leave everything > > > else to kickstart non-graphical installations. > > > > I don't think that would be a good idea, at all. > > Umm ... okay. > > Any particular reason? Any other plans to make the current situation > better? Your mail didn't really go very far towards making the situation better, though, did it? Saying that manual partitioning is 'full of bugs and weirdness' without any actual description of any specific bug or weirdness, or link to any bug report, is hardly a candidate for Most Helpful Post Of The Year... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need help with writing a yum plugin
On Sun, 2012-03-25 at 14:51 +0530, Ankur Sinha wrote: > Hello, > > I'm trying to write a yum plug-in: wait-for-kmod > > For quite a few users, the kmods from RPMFusion are a must. Take > broadcom wireless for example. Now, the kmods generally lag the kernel > updates by a few hours: people who do update their systems in this > interval are left without wireless/display etc. on reboot. That's what the akmods are for... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: creating dynamic access control lists for a device: systemd and udev
On Sun, 2012-03-25 at 13:22 +0100, Ian Malone wrote: > Or indeed, if anyone can show me where this is documented. All I've > managed to find with google are git commits and irrelevant mailing > list fragments. systemd-logind isn't documented, > /lib/udev/rules.d/70-uaccess.rules appears to deal with this, but what > I've seen so far appears to say that udev handling of this is being > deprecated for systemd, 70-uaccess.rules is in fact owned by systemd. This is the systemd handling of it. > also there are no suitable ID_ in there, which > brings me back to the question of choosing suitable names. Is there a > list of reserved names or naming rules? If you were creating > site-specific rules presumably they could go in /etc/... To have the > package for the software add its own rules would Fedora accept a new > ID_ into wherever ID_ needs to go? (70-uaccess.rules?). That is what you need, yes. AIUI, anyway. My experience with this is in the context of libconcord, which handles Harmony remote controls; Kay got ID_REMOTE_CONTROL added to udev (at the time) and 70-uaccess.rules owned by systemd (now) for libconcord to use in its udev rules file. > I assume that > setting TAG+="uaccess" directly (assuming that's what's needed, is it? > how should I know?) in a device rule would be frowned on. I believe so, yeah. The idea is to handle categories of device together so that admins can more easily customize the behaviour, I think. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: Connotation analysis for Fedora Project codenames
Robert 'Bob' Jensen wrote:
> This discussion started on the "board" list yet I know a lot of developers
> have an opinion on the topic.
Indeed. I and several others have pointed out this exact problem with the
"Beefy Miracle" release name (namely that it is offensive to most of India)
ever since it was first proposed for Fedora 16 (!). The proponents of the
idiotic name just wouldn't listen. Nor did the fact that the name was voted
down for Fedora 16 help, as it was just reproposed for Fedora 17 (and would
probably have been reproposed again and again if it had kept losing).
FWIW, I'll also point out that it does not make sense to propose the same
release name for 2 consecutive releases, because the rules say there MUST be
a link between the names for Fedora n and n+1 and there MUST NOT be a link
for Fedora n and n+2. Refiling the release name for Fedora 17 amounts to an
admission that the link used for Fedora 16 (which was a completely
artificial "link" based on applying a nonsensical digest to the ASCII values
of the letters) was invalid, which in turn makes the link used for Fedora 17
("both proposed release names for Fedora 16") also moot. Yet the name was
waved through twice despite the blatantly nonsensical links, while much more
reasonable release names were often discarded due to the links (e.g. because
they weren't of the expected "is-a (same superclass)" type).
My proposal is to just stop using release codenames NOW, including removing
the name for Fedora 17 (and possibly even outright issue an apology for
having used the offensive release name in prereleases). (As for the artwork:
Either rename it or just revert to the Verne artwork.)
(And I personally have nothing against eating beef, I eat it myself. Though
I don't like hot dogs. ;-) )
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
Le Mar 27 mars 2012 18:18, Joe Orton a écrit : > Yup - the default config in the f18 httpd does load mod_access_compat, > and I don't see a problem with shipping like that. However, this module does not seem to be installed on http yum updates -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
2012/3/27 Joe Orton : > On Mon, Mar 26, 2012 at 03:09:08PM -0500, Chris Adams wrote: >> Once upon a time, Nicolas Mailhot said: >> > The following is going to kill pretty much every packaged webapp unless >> > they >> > are changed now: >> > >> > https://httpd.apache.org/docs/2.4/upgrading.html#access >> >> Did you read this part: >> >> "The old access control idioms should be replaced by the new >> authentication mechanisms, although for compatibility with old >> configurations, the new module mod_access_compat is provided." >> >> It would be easy to include mod_access_compat in the Fedora default >> config for a release or two while the compat config is deprecated (and >> noted in the release notes as such). > > Yup - the default config in the f18 httpd does load mod_access_compat, > and I don't see a problem with shipping like that. Great. Backward compatibility is a good thing. > > It would be good to convert webapps over for f18, having said that. > > Regards, Joe > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
Jóhann B. Guðmundsson wrote: > We are very good at inventing and implementing the latest and the > greatest but terribly at removing the legacy cruff at the same time, > which results in half baked implementation leaving various things in > "compat" mode and half removed from the distribution/install. I think "removing the legacy cruft" just for the goal of removing it is not helpful at all and is actually the main cause of "half baked", "half removed" stuff in Fedora. I assume that that mod_access_compat module only requires a few bytes, so I don't see why it should not be loaded by default forever (or at least as long as upstream supports it, which hopefully will be for the whole 2.4 cycle). Of course, web app packages in Fedora itself SHOULD be updated to the new directives, but that's not a reason to gratuitously break the old ones. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On Tue, Mar 27, 2012 at 11:56 AM, Jason L Tibbitts III wrote: >> "JO" == Joe Orton writes: > > JO> Yup - the default config in the f18 httpd does load > JO> mod_access_compat, and I don't see a problem with shipping like > JO> that. > > This is good news, because even if we convert the httpd.conf.d files in > all of the packages, they're all marked %config(noreplace) so a package > update won't magically fix > > JO> It would be good to convert webapps over for f18, having said that. > > It would be great to have a short document about this (even though I > know the conversion is largely trivial). Would it be reasonable to have > something should be added to the packaging guidelines at some point so > that new packages don't rely on the compatibility module? Probably, and the release notes as well, if it's not already there. -J > - J< > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
> "JO" == Joe Orton writes: JO> Yup - the default config in the f18 httpd does load JO> mod_access_compat, and I don't see a problem with shipping like JO> that. This is good news, because even if we convert the httpd.conf.d files in all of the packages, they're all marked %config(noreplace) so a package update won't magically fix JO> It would be good to convert webapps over for f18, having said that. It would be great to have a short document about this (even though I know the conversion is largely trivial). Would it be reasonable to have something should be added to the packaging guidelines at some point so that new packages don't rely on the compatibility module? - J< -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: Standard ML in Fedora and in GSoC
On Tue, Mar 27, 2012 at 07:00:15PM +0530, Buddhike Kurera wrote: > Hello, > An idea found on the summer-coding list, please forward if you have > any idea, comment. More ML is better. Take a look at this link for the gory details of how to submit packages: https://fedoraproject.org/wiki/PackageMaintainers/Join Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
27.03.2012 20:18, Joe Orton написал: On Mon, Mar 26, 2012 at 03:09:08PM -0500, Chris Adams wrote: Once upon a time, Nicolas Mailhot said: The following is going to kill pretty much every packaged webapp unless they are changed now: https://httpd.apache.org/docs/2.4/upgrading.html#access Did you read this part: "The old access control idioms should be replaced by the new authentication mechanisms, although for compatibility with old configurations, the new module mod_access_compat is provided." It would be easy to include mod_access_compat in the Fedora default config for a release or two while the compat config is deprecated (and noted in the release notes as such). Yup - the default config in the f18 httpd does load mod_access_compat, and I don't see a problem with shipping like that. It would be good to convert webapps over for f18, having said that. Shouldn't be it the Future? Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On Mon, Mar 26, 2012 at 03:09:08PM -0500, Chris Adams wrote: > Once upon a time, Nicolas Mailhot said: > > The following is going to kill pretty much every packaged webapp unless they > > are changed now: > > > > https://httpd.apache.org/docs/2.4/upgrading.html#access > > Did you read this part: > > "The old access control idioms should be replaced by the new >authentication mechanisms, although for compatibility with old >configurations, the new module mod_access_compat is provided." > > It would be easy to include mod_access_compat in the Fedora default > config for a release or two while the compat config is deprecated (and > noted in the release notes as such). Yup - the default config in the f18 httpd does load mod_access_compat, and I don't see a problem with shipping like that. It would be good to convert webapps over for f18, having said that. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python i686 vs x86_64 -- for testing a python library
On Tue, Mar 27, 2012 at 11:09 AM, Martin Langhoff wrote: > On Tue, Mar 27, 2012 at 11:18 AM, Adam Jackson wrote: >> Use a chroot or an i686 vm. Or possibly just do rpmdev-extract on the i686 >> version and run it directly. > > I've been toying with a chroot via mock, but was awkward for a number > of reasons. I've used rpmdev-extract and installed just the binary as > /usr/bin/python2.6-i686 Yeah, it's a little awkward since it's not really made for that purpose but it does work well, a la: mock --init mock --install mock --shell Of course you need to set a default release and arch to use or just use the "-r fedora--" option. I frequently use this method to run rpmlint on installed packages without having to pollute my main system. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python i686 vs x86_64 -- for testing a python library
On Tue, Mar 27, 2012 at 11:18 AM, Adam Jackson wrote: > Welcome to rpm. ELF files have a wacky concept called "color", which means Color me impressed. That's one thing I didn't know! > Use a chroot or an i686 vm. Or possibly just do rpmdev-extract on the i686 > version and run it directly. I've been toying with a chroot via mock, but was awkward for a number of reasons. I've used rpmdev-extract and installed just the binary as /usr/bin/python2.6-i686 Saved my day -- thanks! m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python i686 vs x86_64 -- for testing a python library
On 3/27/12 10:39 AM, Martin Langhoff wrote: I am diagnosing a bug/odditywith a python library that uses Pyrex and other oddities. In the course of that, I have installed python.i686 on my F16 x86_64 system, and I'm trying to run it and... no dice! According to rpm, python.x86_64 and python.i686 both own /usr/bin/python and /usr/bin/python2.7 . Those binaries are 64 bits. Googling around, I cannot find any clue on how to run the 32 bit binary. Had optimistically assumed that I'd find python.i686 stashed somewhere when I looked at rpm -ql python.686 ... Welcome to rpm. ELF files have a wacky concept called "color", which means you can have both .i686 and .x86_64 versions of the same package installed with no conflict and the x86_64 version wins on disk. Use a chroot or an i686 vm. Or possibly just do rpmdev-extract on the i686 version and run it directly. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 802998] perl-POE-Component-Client-HTTP-0.945 is available
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=802998 Petr Šabata changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-POE-Component-Client-H ||TTP-0.945-1.fc18 Resolution||RAWHIDE Last Closed||2012-03-27 10:50:20 -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Python i686 vs x86_64 -- for testing a python library
I am diagnosing a bug/odditywith a python library that uses Pyrex and other oddities. In the course of that, I have installed python.i686 on my F16 x86_64 system, and I'm trying to run it and... no dice! According to rpm, python.x86_64 and python.i686 both own /usr/bin/python and /usr/bin/python2.7 . Those binaries are 64 bits. Googling around, I cannot find any clue on how to run the 32 bit binary. Had optimistically assumed that I'd find python.i686 stashed somewhere when I looked at rpm -ql python.686 ... cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: Standard ML in Fedora and in GSoC
Hello, An idea found on the summer-coding list, please forward if you have any idea, comment. Thanks for the support ! Dear All, Buddhike Kurera suggested me to write my idea and send it to this mailing list. I am a functional programming advocate and would like to see Standard ML projects in Fedora. Both a better infrastructure for the language and actual projects that are implemented in SML. For a short introduction why SML would be useful, check my blog entry: http://www.buday-rd.com/on-standard-ml I would add the following: as far as I know, daemons are written in Python nowadays in Fedora, with a possible rewriting in C if speed and memory footprint is critical. SML could do both, as the sml/nj and the polyml compiler has an interactive loop like Python for creative programming, but the mlton whole-program optimizing compiler generates executables with speed comparable to C object files. It has a mathematical definition so it is easier to argument about a program than in Python or C. The first step could be proper packaging for various architectures and platforms, and cross-compilation for these. mlton, polyml and mosml has packaging but I did not find packaging for sml/nj. The next step could be choosing a daemon task to write from scratch or an existing one to rewrite. I would appreciate your comments and questions on this. - Gergely -- Regards, Buddhike Chandradeepa Kurera(bckurera) Fedora Ambassador - APAC region Event Liaison - Design Team Email: bckur...@fedoraproject.org | IRC: bckurera -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Managing the GNOME updates in Fedora
On 26 March 2012 20:31, Kevin Kofler wrote: > Let's also mention our mass-update script: > https://fedorahosted.org/kde-settings/browser/scripts > which may or may not be of interest. Very much of interest, thanks. I spent a couple of hours and wrote mclazy, i.e. "I'm lazy and I'm trying to help mclasen". I've hosted it here: https://gitorious.org/mclazy/mclazy/trees/master and it's really just a simple python script. Patches very welcome, but go easy on the python newbie! It's currently automatically building about 20 GNOME packages that we've missed on the spreadsheet. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Test Day 2012-03-29: GNOME Shell Software Rendering
There will be a "GNOME Shell Software Rendering" Test Day on Thursday! https://fedoraproject.org/wiki/Test_Day:2012-03-29_Gnome_Shell_Software_Rendering Here's an introduction from Vitezslav Humpa, who's in charge of this event from QA perspective: This week brings a second installment of Fedora Test Day targeting GNOME 3. This time we will focus on software rendering providing a full GNOME session purely by means of the CPU. Nowadays with most of personal computers capable of hardware 3D acceleration this might seem unnecessary. But let's not forget a whole lot of us who have capable but yet unsupported hardware and get stuck with the Fallback mode. And this is not the only case. In addition to computers with obsolete graphics there are VM hypervisors like KVM or VirtualBox that don't support full 3D yet. Fedora can also run on many kinds of less usual devices like tablets or netbooks that don't have free (or even proprietary) drivers ready. Simply said, our goal is to make sure that no matter what hardware you are running your Fedora on, you will always get the user experience you are entitled to - a full GNOME desktop. Do you have an older PC? Netbook? Or do you like to play with the latest of the latest in VM, where it won't "break" your computer? Even if not, please help us test the GNOME Shell software rendering by following few test cases and catching a few bugs - after all, as always with Fedora, you'll be doing that for yourself :-) Date: 2012-03-29 Time: all day What: https://fedoraproject.org/wiki/Test_Day:2012-03-29_Gnome_Shell_Software_Rendering Where: #fedora-test-day ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-17 Branched report: 20120327 changes
Compose started at Tue Mar 27 08:15:36 UTC 2012 Broken deps for x86_64 -- [HippoDraw] HippoDraw-devel-1.21.3-2.fc17.i686 requires python-numarray HippoDraw-devel-1.21.3-2.fc17.x86_64 requires python-numarray HippoDraw-python-1.21.3-2.fc17.x86_64 requires python-numarray [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.1-5.fc17.noarch requires ruby-nokogiri [alexandria] alexandria-0.6.8-2.fc17.1.noarch requires ruby(abi) = 0:1.8 [catfish] catfish-engines-0.3.2-4.fc17.1.noarch requires pinot [comoonics-cdsl-py] comoonics-cdsl-py-0.2-19.noarch requires comoonics-base-py [comoonics-cluster-py] comoonics-cluster-py-0.1-25.noarch requires comoonics-base-py [contextkit] contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) [converseen] converseen-0.4.9-3.fc17.x86_64 requires libMagickWand.so.5()(64bit) converseen-0.4.9-3.fc17.x86_64 requires libMagickCore.so.5()(64bit) converseen-0.4.9-3.fc17.x86_64 requires libMagick++.so.5()(64bit) [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [eruby] eruby-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) eruby-libs-1.0.5-17.fc17.i686 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.i686 requires libruby.so.1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 [gearmand] gearmand-0.23-2.fc17.x86_64 requires libtcmalloc.so.0()(64bit) gearmand-0.23-2.fc17.x86_64 requires libmemcached.so.8()(64bit) gearmand-0.23-2.fc17.x86_64 requires libboost_program_options-mt.so.1.47.0()(64bit) [genius] genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) gnome-genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) [gnome-phone-manager] gnome-phone-manager-0.66-9.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [gnome-user-share] gnome-user-share-3.0.1-3.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [gorm] gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23 gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-gui.so.0.20()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-base.so.1.23()(64bit) [gscribble] gscribble-0.1.2-2.fc17.noarch requires gnome-python2-gtkhtml2 [i3] i3-4.0.1-2.fc17.x86_64 requires libxcb-property.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-keysyms.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-icccm.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-event.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-aux.so.0()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-atom.so.1()(64bit) [ibus-fep] ibus-fep-1.4.3-1.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [ibus-gucharmap] ibus-gucharmap-1.4.0-3.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [ibus-panel-extensions] ibus-panel-extensions-1.4.99.20111207-1.fc17.i686 requires libibus-1.0.so.0 ibus-panel-extensions-1.4.99.20111207-1.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [ibus-unikey] ibus-unikey-0.6.1-1.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [jboss-jaxrpc-1.1-api] jboss-jaxrpc-1.1-api-1.0.1-0.1.20120309gita3c227.fc17.noarch requires jboss-servlet-3.0-api [kazehakase] kazehakase-ruby-0.5.8-11.svn3873_trunk.fc17.x86_64 requires ruby(abi) = 0:1.8 kazehakase-ruby-0.5.8-11.svn3873_trunk.fc17.x86_64 requires libruby.so.1.8()(64bit) [libprelude] 1:libprelude-ruby-1.0.0-11.fc17.x86_64 requires ruby(abi) = 0:1.8 1:libprelude-ruby-1.0.0-11.fc17.x86_64 requires libruby.so.1.8()(64bit) [libteam] libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-route-3.so.199 libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-nf-3.so.199 libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-genl-3.so.199 libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-cli-3.so.199 libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-3.so.199 libteam-0.1-3.20120130gitb5cf2a8.fc17.x86_64 require
Re: urandom vs haveged
On 03/26/2012 11:55 PM, Chris Murphy wrote: > > > On Mar 26, 2012, at 4:31 PM, Pádraig Brady wrote: >> >> Well if you're just writing huge amounts of "random" data >> to clear existing space, then you don't need it to be cryptographically >> secure. >> Why are you doing this exactly? Would /dev/zero suffice? > > In every supposed best practice case of dm-crypt LUKS setup, urandom is used > by example. Including by Red Hat and Fedora Projects. The Fedora link says: > "You're looking at a process that takes many hours, but it is imperative to > do this in order to have good protection against break-in attempts. Just let > it run overnight." > > http://www.redhat.com/summit/2011/presentations/summit/taste_of_training/wednesday/Strickland_On_Disk_Encryption_with_RHEL.pdf > > http://fedoraproject.org/wiki/Implementing_LUKS_Disk_Encryption > > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption-Manually_Encrypting_Directories-Step_by_Step_Instructions.html > > So then the question is, if urandom is what's recommended, are faster > substitutes just as good? If they are just as good, then why aren't they the > first recommendation? And if this step is superfluous, then I'd suggest > documentation be changed to eliminate the suggestion altogether. Well I can only think of two reasons for writing "random" data. 1. Ensure all existing data is overwritten (zeros would do just as well on modern drives) 2. Homogenize written (with luks data) and nonwritten parts of the drive, so that you can't determine the extent of the real encrypted data. I think `shred -v -n1 /your/device` is fine for this: http://burtleburtle.net/bob/rand/isaacafa.html cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: urandom vs haveged
On 03/27/2012 05:23 AM, Gregory Maxwell wrote: > On Mon, Mar 26, 2012 at 6:55 PM, Chris Murphy wrote: >> So then the question is, if urandom is what's recommended, are faster >> substitutes just as good? If they are just as good, then why aren't they the >> first recommendation? And if this step is superfluous, then I'd suggest >> documentation be changed to eliminate the suggestion altogether. > > Personally, I setup dmcrypt (w/o luks) first using /dev/urandom as the > key and one of the secure block modes (e.g. aes-lrw or aes-essiv). > Then I fill the dmcrypt device with /dev/zero. This goes fairly fast, > filling the device with securely encrypted zeros. > > Then I drop the volume and set up luks normally. Nice trick. Does this saturate the disk speed? Last time I had to do this I compiled my own random generator, using some code from a research article. That was fast C code, when compiled for x86_64 with good gcc options the speed (>/dev/null) was 1.75GB/s (!!!). -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: Connotation analysis for Fedora Project codenames
On 03/26/2012 11:01 PM, Robert 'Bob' Jensen wrote: > As I already pointed out - the process is open. Anybody can step > into in the early phase of naming selection and comment the > potential problems. And I believe the Board members will think > about the concerns raised (at least me ;-). > > So personally I'd like to avoid any strict rule/policy as it could > hurt our community, we don't have a proper set of skills to do > the full analysis during the Board turn and I really hope with help > provided by community we can avoid the naming problems in the > future - just we need your, community, input. I'm sure that's the right approach. > Any thoughts? > > PS: I like Christoph's comment in ticket - that as an international > project we should be proud of our diversity. It is a chance and > a burden at the same time, Fedora will face this problem often and > we can do our best to respect others and their views. Indeed, but let's not get carried away, lest we end up in a situation where no town that ever had a brewery can be named because it might theoretically offend a religion that forbids alcohol consumption. I'm sure you'll be sensible. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
Le Lun 26 mars 2012 22:09, Chris Adams a écrit : > Once upon a time, Nicolas Mailhot said: >> The following is going to kill pretty much every packaged webapp unless they >> are changed now: >> >> https://httpd.apache.org/docs/2.4/upgrading.html#access > > Did you read this part: > > "The old access control idioms should be replaced by the new >authentication mechanisms, although for compatibility with old >configurations, the new module mod_access_compat is provided." > > It would be easy to include mod_access_compat in the Fedora default > config for a release or two while the compat config is deprecated (and > noted in the release notes as such). Sure. But right now there does not seem to be a plan one way or the other, so now that http 2.4 is built rawhide webapps are broken. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On 03/27/2012 12:53 AM, Dennis Jacobfeuerborn wrote: I disagree. Since this is a major update that gets introduced together with a new Fedora version this opportunity should be used to make switches like these. Otherwise you'll be forced to either keep this compat stuff around for a long time (given the long apache release cycles) or remove it with a minor update when people least expect it. I agree on you disagreement. We are very good at inventing and implementing the latest and the greatest but terribly at removing the legacy cruff at the same time, which results in half baked implementation leaving various things in "compat" mode and half removed from the distribution/install. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
