Re: raising warning flag on firewalld-default feature
On 11/13/2012 05:35 PM, Richard W.M. Jones wrote:
On Tue, Nov 13, 2012 at 02:41:44PM +, Pádraig Brady wrote:
It could be argued that python is more suited to long lived programs:
$ time /bin/true
real 0m0.002s
Hmmm:
$ echo '' true.ml
$ ocamlopt.opt true.ml -o true
$ time ./true
real 0m0.002s
user 0m0.000s
sys0m0.001s
$ time /bin/true
real 0m0.001s
user 0m0.000s
sys0m0.001s
This seems about right to me: Both ocamlopt gcc generate native
x86-64 programs, but there's a small amount of overhead in the OCaml
binary (initializing the minor heap of the GC).
Just for fun, let's see who is the worst.
$ cat JavaTrue.java
public class JavaTrue {
public static void main(String[] args) {
System.exit(0);
}
}
$ javac JavaTrue.java
$ time java -cp . JavaTrue
real0m0.071s
user0m0.037s
sys 0m0.035s
Hmmm. Slow and with a lot of sys...
Let's try compiling it to native.
$ gcj -o JavaTrue JavaTrue.java --main=JavaTrue
$ time ./JavaTrue
real0m0.026s
user0m0.016s
sys 0m0.010s
Good improvement, but still quite slow.
(OT: what a pity gcj is abandoned... great project)
--
Roberto Ragusamail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Schedule for Wednesday's FESCo Meeting (2012-11-14)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC (1:00pm EDT, 19:00 CEST) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #963 change of names of configuration files .fesco 963 https://fedorahosted.org/fesco/ticket/963 = New business = #topic #971 Freezing for Fedora 18 Beta .fesco 971 https://fedorahosted.org/fesco/ticket/971 #topic #969 libexecdir guideline conflicts with extant packages .fesco 969 https://fedorahosted.org/fesco/ticket/969 #topic #970 F19 Feature: RPM 4.11 - http://fedoraproject.org/wiki/Features/RPM4.11 .fesco 970 https://fedorahosted.org/fesco/ticket/970 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File CGI.pm-3.62.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-CGI: 3600b5fb106c256d53393e86ba62c65e CGI.pm-3.62.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CGI] 3.62 bump
commit 293f9a35fdbd1495a58da5206c06074304dcf196
Author: Petr Písař ppi...@redhat.com
Date: Wed Nov 14 10:56:36 2012 +0100
3.62 bump
.gitignore|1 +
perl-CGI.spec | 10 +++---
sources |2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index c5df0dc..8755315 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
/CGI.pm-3.51.tar.gz
/CGI.pm-3.60.tar.gz
/CGI.pm-3.61.tar.gz
+/CGI.pm-3.62.tar.gz
diff --git a/perl-CGI.spec b/perl-CGI.spec
index 808794e..86e651e 100644
--- a/perl-CGI.spec
+++ b/perl-CGI.spec
@@ -1,6 +1,6 @@
Name: perl-CGI
Summary:Handle Common Gateway Interface requests and responses
-Version:3.61
+Version:3.62
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -9,11 +9,12 @@ URL:http://search.cpan.org/dist/CGI
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
# Run-requires:
+BuildRequires: perl(base)
BuildRequires: perl(Carp)
BuildRequires: perl(constant)
BuildRequires: perl(Exporter)
-BuildRequires: perl(File::Spec) = 0.82
BuildRequires: perl(FCGI) = 0.67
+BuildRequires: perl(File::Spec) = 0.82
# Apache modules are optional
# Tests:
BuildRequires: perl(Encode)
@@ -22,8 +23,8 @@ BuildRequires: perl(IO::Handle)
BuildRequires: perl(lib)
BuildRequires: perl(Test::More) = 0.98
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-Requires: perl(File::Spec) = 0.82
Requires: perl(FCGI) = 0.67
+Requires: perl(File::Spec) = 0.82
Obsoletes: %{name}-tests = 3.49
%{?perl_default_filter}
@@ -66,6 +67,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Wed Nov 14 2012 Petr Pisar ppi...@redhat.com - 3.62-1
+- 3.62 bump
+
* Tue Nov 06 2012 Petr Šabata con...@redhat.com - 3.61-1
- 3.61 bump, no code changes
diff --git a/sources b/sources
index 5e38826..852c7a4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-92c3d1a5747be1e60618f999a50dad93 CGI.pm-3.61.tar.gz
+3600b5fb106c256d53393e86ba62c65e CGI.pm-3.62.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: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Wed, Nov 14, 2012 at 2:35 AM, Matthew Miller mat...@fedoraproject.org wrote: Well. I may be a little bit cynical on this, but I think the unsteered drift of this kind of thing goes like this: 1. Shiny new feature covers the desktop case, so let's make it the default in Fedora. 2. Don't worry, if you have other needs, the old way still works. 3. So many things get updated to the new way that the old way isn't reasonable anymore, but *those other use cases never get consideration*. It's like step 2 magically covers the end game. But of course it doesn't. That's not at all the case with firewalld. 2 ouf of 4 of the concerns that led to firewalld being postponed in F17 were server/enterprise-related, and AFAIK are now resolved. Yes, the documentation is still not great, but that's something that can realistically be improved before GA. I'm not against progress. The static firewall scripts don't cover a lot of cases, and are particularly a pain with virt. But let's not jump ahead of ourselves without at _least_ a plan. AFAIK the major things for our usual use cases are covered, at least going by the F17 criteria. Sure, there may be more things missing. Looking at hour original warning flag: Squeezing every last megabyte out of the running system for cloud is a really new thing that we haven't historically required. Sure, it would be great to make firewalld smaller (and rewriting firewalld to C is one of those things that have been promised a long time ago and never happened), but I don't really see that as a blocker. So that's a little bit of a tangent, but, as outlined in the other thread, I don't think firewalld is at a point where making it the default would be a good for Fedora. Maybe it could be by F19. Reducing the dependency load is just one part of that. In the meantime, I think we should make sure a newly installed system with either firewalld or the old thing (now called iptables-service) has a sensible firewall out of the box. (Same all-closed-but-ssh as we've had forever, I expect.) We _cannot_ have two different firewalls equally supported, each with its own command line and API. Applications won't support both equally, documentation won't support both equally, QA won't cover both equally, users will be confused. We'd get the 8-years duplication of init.d/network vs. NetworkManager all over again, and I personally strongly want to avoid that (this was a third of my FESCo election platform). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File No-Worries-0.7.tar.gz uploaded to lookaside cache by mpaladin
A file has been added to the lookaside cache for perl-No-Worries: 2392bf83b131ce4ee31f03da4b1f0b8e No-Worries-0.7.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: remove polkit from core?
On Tue, Nov 13, 2012 at 11:53:16PM -0600, Ian Pilcher wrote: Wait. So the .pkla file I wrote to allow my run virt-manager as my normal user is going to stop working, and I'm going to have to write the replacement in JavaScript? This particular case is the primary one I've seen for people actually writing their own policy. I think maybe we should make a Unix group for it and make that the default. (But I don't think that solves the problem.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 875603] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=875603 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-No-Worries-0.7-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/perl-No-Worries-0.7-1.el5 -- 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
[Bug 875603] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=875603 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-No-Worries-0.7-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-No-Worries-0.7-1.fc18 -- 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
Re: [@core] working definition for the minimal package set
2012/11/13 Bill Nottingham nott...@redhat.com [...] - Minimal tools for admins less man-db procps-ng vim-minimal Is man-db really necessary? In the man pages included in the man-db package are not really helpful for a core system ... from my point of view. [...] - Get mail off the box (and define a default for doing so) sendmail Does an MTA really make sense in the core definition? The configuration of MTA is nowadays much more complex compared to the old days. Normaly you need a FQDN, you need a SMTP relay and lot other stuff more. So you will only get the mails off the system after a lot of configuration work which can, from my point of view, also include the installation of an MTA. Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Wed, Nov 14, 2012 at 11:34:56AM +0100, Miloslav Trmač wrote: AFAIK the major things for our usual use cases are covered, at least going by the F17 criteria. Sure, there may be more things missing. Adam asked to keep those other things to the other thread, so I'll just touch on the dependency bloat issue here. I think there are other reasons it is harmful to Fedora to go ahead before this is ready, though, which I'll continue to address separately. Looking at hour original warning flag: Squeezing every last megabyte out of the running system for cloud is a really new thing that we haven't historically required. Sure, it would be great to make firewalld smaller (and rewriting firewalld to C is one of those things that have been promised a long time ago and never happened), but I don't really see that as a blocker. Making it absolutely minimal isn't a blocker, but pulling X libraries into the minimal install is. I think that will be resolved, reducing this particular issue to being something for future improvement. If that can't be resolved, then it alone should be sufficient cause to postpone the feature. We _cannot_ have two different firewalls equally supported, each with its own command line and API. Applications won't support both equally, documentation won't support both equally, QA won't cover both equally, users will be confused. I agree. That's why I'm so concerned that firewalld needs to be ready for all reasonable cases before we switch to it. Again, more on that in the other thread. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 12:37:38AM -0500, Seth Vidal wrote: On EC2 (as in many virt environments) the hardware clock source is actually synced and running an ntpd service on the client is redundant. I would say this is not accurate. My experience with the instances running under xen is that that is true. My experience with the instances running in euca under kvm is that that is not true. I didn't mean to imply that it's true everywhere. It's just true enough places that we shouldn't make it mandatory. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 01:27:21PM +0100, Thomas Bendler wrote: - Minimal tools for admins less man-db procps-ng vim-minimal Is man-db really necessary? In the man pages included in the man-db package are not really helpful for a core system ... from my point of view. I'd like to go back a step here to the question starting the thread. There's plenty of time to go over each package, but the basic question is intent. Clearly man pages aren't necessary for a super-minimal JEOS image, but that's not *historically* been the intent of @core, and based on the discussion so far I think it will continue to not be. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Once upon a time, Thomas Bendler m...@bendler-net.de said: Does an MTA really make sense in the core definition? The configuration of MTA is nowadays much more complex compared to the old days. Normaly you need a FQDN, you need a SMTP relay and lot other stuff more. So you will only get the mails off the system after a lot of configuration work which can, from my point of view, also include the installation of an MTA. Well, as soon as you have cron, you'll have things wanting to send email, and even sendmail mail to root on the local system requires some type of MTA in most cases. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
2012/11/14 Matthew Miller mat...@fedoraproject.org [...] I'd like to go back a step here to the question starting the thread. There's plenty of time to go over each package, but the basic question is intent. Clearly man pages aren't necessary for a super-minimal JEOS image, but that's not *historically* been the intent of @core, and based on the discussion so far I think it will continue to not be. [...] Ok, but what is the intent? The first mail was a questioning what should be the scope of core and I didn't see a discussion answering this question. I think we should first define the mission statement and then discuss the technical details. Or is it only unclear to me what the intent is? Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 03:24:04PM +0100, Thomas Bendler wrote: Ok, but what is the intent? The first mail was a questioning what should be the scope of core and I didn't see a discussion answering this question. I That's *this* discussion. :) think we should first define the mission statement and then discuss the technical details. Or is it only unclear to me what the intent is? I kind of skipped past the mission statement because no one commented on the draft one I made, which is: The Fedora Minimal Core SIG ensures that the Fedora minimal package set is an intentionally curated selection rather than an ad hoc accretion of packages. to the first of the stated goals, which is: Choose a working definition for minimal (kernel + systemd only vs enough to get to yum install over the net vs basic traditional unix system). Based on the conversation so far, I think the target is: - mandatory install of everything up to yum install from the network - default install of a small set of packages necessary for a consistent Fedora experience including minimal admin tools -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-HTTP-Negotiate] Modernize the spec and drop command macros
commit 36836080810c02ed86d0eb0b87fa452a87b1b396
Author: Petr Šabata con...@redhat.com
Date: Wed Nov 14 15:37:02 2012 +0100
Modernize the spec and drop command macros
perl-HTTP-Negotiate.spec | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
---
diff --git a/perl-HTTP-Negotiate.spec b/perl-HTTP-Negotiate.spec
index 4e44b9a..bd2f8a1 100644
--- a/perl-HTTP-Negotiate.spec
+++ b/perl-HTTP-Negotiate.spec
@@ -1,6 +1,6 @@
Name: perl-HTTP-Negotiate
Version:6.01
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Choose a variant to serve
License:GPL+ or Artistic
Group: Development/Libraries
@@ -13,7 +13,7 @@ BuildRequires: perl(HTTP::Headers) = 6
# Tests only:
BuildRequires: perl(Test)
BuildRequires: perl(HTTP::Request)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(HTTP::Headers) = 6
Conflicts: perl-libwww-perl 6
@@ -31,14 +31,13 @@ value of the various Accept* header fields in the request.
%setup -q -n HTTP-Negotiate-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+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/*
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+%{_fixperms} %{buildroot}/*
%check
make test
@@ -49,6 +48,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Nov 14 2012 Petr Šabata con...@redhat.com - 6.01-4
+- Modernize the spec and drop command macros
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 6.01-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
--
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: remove polkit from core?
On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams cmad...@hiwaay.net wrote: Great - let's take something that people are using, remove that functionality, and not announce it! This is not cool; it represents one of my biggest frustrations with a bunch of the new and improved ways of doing things. You track down how to do something, it works for a few releases, and then it doesn't anymore with no notice. I don't mind this much in isolation— and to some extent its unavoidable if there is to be progress. I also have the experience and impression that Fedora often dismisses use cases in the 'long tail' as things that power users can get by twiddling some opaque config file or registry entry or hacking some bit of code— this happens more often the closer you get to the desktop, but believe its a culture which permeates the project more generally than that. In isolation this too would be occasionally frustrating but finite in baddness. The combination of the two— that anything non-stock is subject to constant and often undocumented breakage _and_ that many non nearly-universal use cases are too non-mainstream to consider supportable stock features really diminishes the value I receive from using a distribution at all. More on the subject— in this brave new polkit JS world, when an administrator is considering upgrading their Fedora (or even some packages), what tools will they have to validate that their local JS actually works at all much less produces the desired behavior? I don't see any tools or documentation to facilitate that.It seems to me that adding a bunch of unsound programmatic configuration which can't reasonably be used by the end users due the overhead of keeping up regular fedora churn, especially absent good validation tools, is not a productive change relative to just baking in the additional logic and exposing it via basic configuration switches. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
2012/11/14 Matthew Miller mat...@fedoraproject.org default install of a small set of packages necessary for a consistent Fedora experience including minimal admin tools I was just surprised that there was no discussion about your proposal, instead, there was immediately a discussion about the packages that should be in core. So should this definition be the one that we are working on? From my point of view, core should only contain kernel, network, ssh-server plus yum to be ready for installation (locally and remotely). But if the rest of the group say, no, we need more (i.e. minimal admin tools), fine with me. But then we have something that we agreed on and that can be documented as the core base. Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Once upon a time, Thomas Bendler m...@bendler-net.de said: True, but then you need a mail client as well otherwise you won't see the local mails. So the question is, what is the definition of core? What should be the goal of core? Ehh, for local root mails from failing cron jobs, less /var/mail/root works just fine. :) -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
From: Stephen John Smoogen smo...@gmail.com On Tue, Nov 13, 2012 at 08:00:23PM -0500, Ben Cotton wrote: On EC2 (as in many virt environments) the hardware clock source is actually synced and running an ntpd service on the client is redundant. bikeshed=blue They say it is but it is not always. I have had multiple cases in KVM and some in Xen where supposedly the clock is kept up but what you end up is actually watching time go backwards if you hit heavy load in IO or CPU or Mem. Of course if you run into hardware like that.. you can install it after your DB has gone poopsies. /bikeshed I've seen that happen as well. I found this by hitting the pause button on the guest IIRC. I just always use NTP to avoid the worry, but I agree NTP (whether ntpd or chronyd) belongs in @standard not @core. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
From: Chris Adams cmad...@hiwaay.net Well, as soon as you have cron, you'll have things wanting to send email, and even sendmail mail to root on the local system requires some type of MTA in most cases. From my experience, an MTA is still not required. Any stdout/err from the cron jobs just go to the syslog, but this may be systemd's journal magic that I've been seeing. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
2012/11/14 Chris Adams cmad...@hiwaay.net [...] Ehh, for local root mails from failing cron jobs, less /var/mail/root works just fine. :) Sending mails with telnet also works fine but I don't think that this is the question ;). We work on the definition of core and what will be inside. If we say, mail must be inside we should also install a client to access the mail. That's why I wrote, we should define what core is first (and document it) and then talk about the packages which should be in core. Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Wednesday, November 14, 2012 08:07:25 AM tim.laurid...@gmail.com wrote: On Wed, Nov 14, 2012 at 6:53 AM, Ian Pilcher arequip...@gmail.com wrote: On 11/13/2012 09:50 PM, Matthias Clasen wrote: Yes, this was a misunderstanding. What is still supported is the .policy files containing the default policy. And that is very good, since such policy files are installed by pretty much every package that uses polkit, while .pkla files were only used by very few packages. Wait. So the .pkla file I wrote to allow my run virt-manager as my normal user is going to stop working, and I'm going to have to write the replacement in JavaScript? Let's just say I'm struggling to find the words ... In F18 yes. http://davidz25.blogspot.dk/2012/06/authorization-rules-in-polkit.html This blog misses the most important property about security settings...they have to be auditable through automation. If you have 10,000 systems and need to know your security posture, you have to be able to check them through automation. If the javascript had a file over in /etc that it read configuration things from, then we are OK. But if we have to go check the code itself, there is a problem. -Steve http://www.freedesktop.org/software/polkit/docs/master/polkit.8.html Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Using snapper for OfflineSystemUpdates
In https://fedoraproject.org/wiki/Features/OfflineSystemUpdates we've implemented doing the package updates at first-boot time. This makes a lot of the hard-to-fix problems a lot easier. The question then becomes, how do we make the OS Update process even smarter? A simple check would be to see if X started after doing an upgrade, and if it failed, to rollback to the disk snapshot or / (and /boot?) that we previously knew worked. Do do this we can currently use anything-on-lvm, or btrfs and quite a bit of shell-foo. I'm quite keen on no adding lots of tricky code to PackageKit to deal with all this complexity, so what about using snapper? See http://en.opensuse.org/Portal:Snapper for more details. It's an OpenSuse project, and other than a small patch I've sent upstream to get things compiling on Fedora it looks pretty small, self-contained and sane. Does anybody have any better ideas than snapper? I really don't want to roll my own on this one unless there's a good reason. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Image-Info-1.33.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Image-Info: 63f36362cb80d783c7f8df751ace89a0 Image-Info-1.33.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Image-Info] 1.33 bump
commit 17b62e29c189ff9d4cb83e2978df1de468491b38
Author: Petr Šabata con...@redhat.com
Date: Wed Nov 14 16:53:58 2012 +0100
1.33 bump
.gitignore |1 +
perl-Image-Info.spec | 65 ++---
sources |2 +-
3 files changed, 36 insertions(+), 32 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d5c715d..d646c5e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Image-Info-1.28.tar.gz
+/Image-Info-1.33.tar.gz
diff --git a/perl-Image-Info.spec b/perl-Image-Info.spec
index b035e36..754f74a 100644
--- a/perl-Image-Info.spec
+++ b/perl-Image-Info.spec
@@ -1,63 +1,66 @@
-%define rgbtxt %{_datadir}/X11/rgb.txt
-
Name: perl-Image-Info
-Version:1.28
-Release:14%{?dist}
+Version:1.33
+Release:1%{?dist}
Summary:Image meta information extraction module for Perl
-
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Image-Info/
-Source0:
http://www.cpan.org/authors/id/T/TE/TELS/image/Image-Info-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
+Source0:
http://search.cpan.org/CPAN/authors/id/S/SR/SREZIC/Image-Info-1.33.tar.gz
BuildArch: noarch
-BuildRequires: perl(Image::Xbm), perl(Image::Xpm), perl(XML::Simple)
-BuildRequires: perl(Test::Pod), perl(Test::Pod::Coverage)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Compress::Zlib)
+BuildRequires: perl(constant)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(Getopt::Long)
+BuildRequires: perl(Image::TIFF)
+BuildRequires: perl(Image::Xbm)
+BuildRequires: perl(Image::Xpm)
+BuildRequires: perl(IO::String)
+BuildRequires: perl(lib)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(XML::LibXML::Reader)
+BuildRequires: perl(XML::Simple)
Requires: rgb
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(Compress::Zlib)
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
This Perl extension allows you to extract meta information from
various types of image files.
-
%prep
%setup -q -n Image-Info-%{version}
chmod -c 644 exifdump imgdump
-%{__perl} -pi -e 's|/usr/X11R6/lib/X11/rgb\.txt|%{rgbtxt}|' \
-lib/Image/Info/XPM.pm
-
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
-
%install
-rm -rf $RPM_BUILD_ROOT
-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 ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
-
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+%{_fixperms} %{buildroot}/*
%check
make test
-
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-
%files
-%defattr(-,root,root,-)
-%doc CHANGES README exifdump imgdump
+%doc CHANGES CREDITS README TODO exifdump imgdump
+%{perl_vendorlib}/Bundle/
%{perl_vendorlib}/Image/
%{_mandir}/man3/*.3pm*
-
%changelog
+* Wed Nov 14 2012 Petr Šabata con...@redhat.com - 1.33-1
+- 1.33 bump
+- Get rid of the old cruft
+- Fix dependencies
+- Update the source URL
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.28-14
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
diff --git a/sources b/sources
index a946495..72e0766 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-09453662ceb4bd57e1f2fcdd957c7a66 Image-Info-1.28.tar.gz
+63f36362cb80d783c7f8df751ace89a0 Image-Info-1.33.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: [@core] working definition for the minimal package set
On Tuesday, November 13, 2012 04:55:50 PM Adam Williamson wrote: So far everything works without, and I think we should endevor to keep that true. I think this is similar to the firewalld issue in that the basic theory here is that, look, NetworkManager is the way, the truth and the light: it's supposed to be the One True Networking System, and we're just keeping the network service around because there's some stuff it does that NM doesn't do yet. This logic is getting a tad stretched because we've been rolling with it for several years at this point, but AIUI this is still the party line and the reason NetworkManager is in core. In theory the idea is not that we provide, actively maintain and support both NM and the network service, but that we want to only provide, maintain and support NM, and we're keeping the legacy 'network service' stuff around only until NM is done. It might be worth re-evaluating whether that's realistic any more, though, and whether we're really committed to finally replacing network with NM in some kind of reasonable timeframe. For Common Criteria purposes, everything running as root goes under the microscope and its painful and costly. We have to avoid that. If NM did not run as root and just retained whatever capability it needed, then we have an easier time. Same thing with firewalld. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
hdf5 1.8.10 being pushed to rawhide
I'll be building hdf5 1.8.10 for rawhide shortly. This will require a rebuild of all hdf5 using packages. I'll try to get to most of them today. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Setting the default firewall configuration (was Re: Attention, dependency fighters)
Am 14.11.2012 01:52, schrieb Adam Williamson: I don't think that maintaining iptables/s-c-f forever as a 'lightweight alternative' to firewalld is the way to go IT IS the way to go! not as default, not supported via GUI is OK but iptables.service and configuration with shellscripts is what in many professional usecases is needed, the only thing which is needed by administrators is the iptables-command and iptables.service loading /etc/sysconfig/iptables at startup so you can satisfy the desktop users with GUI/firewalld and do not punish professional users with iptables-rules you never can put in any GUI signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Pcre 8.32 RC1 in Rawhide
Hello, I've pushed release candidate of PCRE 8.32 into rawhide today. I belive it should not cause any difficulties as I've run it in my system for some time. It should be fully compatible with previous version though it introduces some significant changes like UTF-32 support, proper case-folding for multi-variant cases (e.g. Greek sigma), some JIT refactoring for 1.4 speed-up, Unicode 6.2.0, and pcregrep new `-oN' option to print any arbitrary submatches. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using snapper for OfflineSystemUpdates
Richard Hughes (hughsi...@gmail.com) said: In https://fedoraproject.org/wiki/Features/OfflineSystemUpdates we've implemented doing the package updates at first-boot time. This makes a lot of the hard-to-fix problems a lot easier. The question then becomes, how do we make the OS Update process even smarter? A simple check would be to see if X started after doing an upgrade, and if it failed, to rollback to the disk snapshot or / (and /boot?) that we previously knew worked. Do do this we can currently use anything-on-lvm, or btrfs and quite a bit of shell-foo. I'm quite keen on no adding lots of tricky code to PackageKit to deal with all this complexity, so what about using snapper? See http://en.opensuse.org/Portal:Snapper for more details. It's an OpenSuse project, and other than a small patch I've sent upstream to get things compiling on Fedora it looks pretty small, self-contained and sane. Does anybody have any better ideas than snapper? I really don't want to roll my own on this one unless there's a good reason. If you're using the yum backend, it already has support for this via a plugin. (Haven't tested it recently, but it's been there for a few releases.) snapper's just a wrapper around the other commandline tools, right? We do have 'system-storage-manager' now; see the 'ssm snapshot' command it provides. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using snapper for OfflineSystemUpdates
On 11/14/2012 03:53 PM, Richard Hughes wrote: In https://fedoraproject.org/wiki/Features/OfflineSystemUpdates we've implemented doing the package updates at first-boot time. This makes a lot of the hard-to-fix problems a lot easier. The question then becomes, how do we make the OS Update process even smarter? A simple check would be to see if X started after doing an upgrade, and if it failed, to rollback to the disk snapshot or / (and /boot?) that we previously knew worked. Do do this we can currently use anything-on-lvm, or btrfs and quite a bit of shell-foo. I'm quite keen on no adding lots of tricky code to PackageKit to deal with all this complexity, so what about using snapper? See http://en.opensuse.org/Portal:Snapper for more details. It's an OpenSuse project, and other than a small patch I've sent upstream to get things compiling on Fedora it looks pretty small, self-contained and sane. Does anybody have any better ideas than snapper? I really don't want to roll my own on this one unless there's a good reason. Richard. You mean the snapper which is stuck in review #852174 :) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 18 now in Beta freeze (again)
Greetings. Fedora 18 is now in freeze and the Beta change deadline is upon us (again). Updates will land in updates-testing after being pushed. Updates that fix accepted blocker and accepted NTH bugs for the Beta release will be pushed into the base repo when stable. We are in the Pre Beta section of the release, so the Pre Beta to pre-release updates policy applies: http://fedoraproject.org/wiki/Updates_Policy#Pre_Beta Please see: http://fedoraproject.org/wiki/Branch_Freeze_Policy http://fedoraproject.org/wiki/Change_deadlines http://fedoraproject.org/wiki/QA:SOP_blocker_bug_process http://fedoraproject.org/wiki/QA:SOP_nth_bug_process For more details. kevin signature.asc Description: PGP signature ___ 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
firewalld and other firewall frameworks
Hi folks, Since there's currently a lot of discussion going on surrounding firewalld I thought I'd throw in another aspect to these discussions (following encouragement from Mathew Miller). I'm speaking with my shorewall package maintainer hat on, but the issue would arise with any other framework for managing iptables rulesets. What's the official line (and hopefully this will end up in the documentation) on using other frameworks such as shorewall? In the past we've assumed that users installing shorewall know enough to disable the ip[6]tables service. Will the same be true with firewalld - i.e. will it simply be a case of disabling activation of firewalld? Is there any mechanism within firewalld for playing nicely with other products that generate iptables rules? Cheers, Jonathan. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using snapper for OfflineSystemUpdates
On 14 November 2012 16:27, Bill Nottingham nott...@redhat.com wrote: If you're using the yum backend, it already has support for this via a plugin. Yes, I'm using yum but this problem applies for other distros too. snapper's just a wrapper around the other commandline tools, right? We do have 'system-storage-manager' now; see the 'ssm snapshot' command it provides. I looked at ssm, but I didn't find any way to do anything other than snapshot, create and delete. I need to be able to roll back the current system to a working system using a snapshot, or at least get a diff of one snapshot to another. Snapper seems to provide a dbus service which I can use to do all the heavy lifting. They are indeed very similar. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Wed, Nov 14, 2012 at 1:24 PM, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Nov 13, 2012 at 11:53:16PM -0600, Ian Pilcher wrote: Wait. So the .pkla file I wrote to allow my run virt-manager as my normal user is going to stop working, and I'm going to have to write the replacement in JavaScript? This particular case is the primary one I've seen for people actually writing their own policy. I think maybe we should make a Unix group for it and make that the default. (But I don't think that solves the problem.) If David is unwilling to just resurrect the old .pkla parser, one option for solving the problem might be writing a piece of code that would provide compatibility with the .pkla files. This could be (the only) JS config snippet parsing the files directly if the JS environment allowed file system access, or alternatively a generator run before starting polkit to generate a large JS config representing the contents of .pkla files. Anyone interested in implementing it? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM weekly status meeting 2012-11-14
Good day all, This weeks Fedora ARM status meeting will take place today (Wednesday Nov 14th) in #fedora-meeting-1 on Freenode. Times in various time zones (please let us know if these do not work): PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Current items on the agenda: 1) Problem packages needing attention 2) Exynos 5 (Chromebook) Kernel - Is anyone currently working on this? 3) SE Linux issue with F18 kernels - status update 4) SFP images for F18 Beta - What images will be produced? 5) FUDCon Lawrence ARM activity planning If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Roberto Ragusa wrote: Just for fun, let's see who is the worst. Challenge accepted. :-) $ cat nothing.adb procedure Nothing is begin null; end Nothing; $ gnatmake nothing.adb -o true gcc -c nothing.adb gnatbind -x nothing.ali gnatlink nothing.ali -o true $ time ./true real0m0.001s user0m0.000s sys 0m0.000s Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 876523] perl-Text-CSV_XS-0.92 is available
https://bugzilla.redhat.com/show_bug.cgi?id=876523 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Text-CSV_XS-0.92-1.fc1 ||9 -- 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
Summary/Minutes for today's FESCo Meeting (2012-11-14)
=== #fedora-meeting: FESCO (2012-11-14) === Meeting started by mmaslano at 18:01:05 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-11-14/fesco.2012-11-14-18.01.log.html . Meeting summary --- * init process (mmaslano, 18:01:23) * #963 change of names of configuration files (mmaslano, 18:03:20) * AGREED: defer for now and see if mjg59 can get them access to the info they seek (+8,-0) (mmaslano, 18:12:34) * #971 Freezing for Fedora 18 Beta (mmaslano, 18:12:55) * Fedora 18 was already frozen (mmaslano, 18:13:52) * #969 libexecdir guideline conflicts with extant packages (mmaslano, 18:16:16) * AGREED: defer the decision (until Java rulling comes down) (+9,-0) (mmaslano, 18:29:11) * #970 F19 Feature: RPM 4.11 http://fedoraproject.org/wiki/Features/RPM4.11 (mmaslano, 18:34:14) * AGREED: rpm was accepted as f19 feature (+9,-0) (mmaslano, 18:35:15) * Next week's chair (mmaslano, 18:35:29) * nirik will be the chairman next week (mmaslano, 18:36:19) * Open Floor (mmaslano, 18:36:30) Meeting ended at 18:44:15 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * nirik (38) * mmaslano (36) * mjg59 (25) * mitr (17) * notting (15) * jwb (12) * zodbot (10) * pjones (9) * limburgher (9) * t8m (7) * gholms (5) * jreznik (4) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot 18:01:05 mmaslano #startmeeting FESCO (2012-11-14) 18:01:05 zodbot Meeting started Wed Nov 14 18:01:05 2012 UTC. The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:05 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:10 mjg59 Hi 18:01:10 mmaslano #meetingname fesco 18:01:10 zodbot The meeting name has been set to 'fesco' 18:01:16 jwb hello 18:01:19 nirik morning 18:01:19 mmaslano #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb 18:01:20 zodbot Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m 18:01:23 mmaslano #topic init process 18:01:33 pjones morning. 18:01:51 * limburgher here 18:02:02 mitr Hello 18:02:28 * notting is here 18:02:37 * jreznik is lurking 18:02:47 mmaslano let' start 18:03:10 mmaslano .fesco #963 18:03:10 zodbot mmaslano: Error: '#963' is not a valid integer. 18:03:20 mmaslano #topic #963 change of names of configuration files 18:03:30 pjones .fesco 963 18:03:30 mmaslano .fesco 963 18:03:31 zodbot pjones: #963 (change of names of configuration files) – FESCo - https://fedorahosted.org/fesco/ticket/963 18:03:34 zodbot mmaslano: #963 (change of names of configuration files) – FESCo - https://fedorahosted.org/fesco/ticket/963 18:03:42 mmaslano mjg59: could you help michal or Kay? 18:03:45 mjg59 Yeah 18:03:52 mjg59 Sorry, hadn't really been online much for the past week 18:03:58 mjg59 I'll follow up on that 18:03:58 mmaslano sure, thanks 18:04:21 mitr They could just unpack/analyze rawhide themselves I'd expect.. 18:05:50 mmaslano any proposal? I would be fine with mjg's help 18:06:07 mitr if mjg59 wants to help, I'm completely fine 18:06:11 nirik proposal: defer for now and see if mjg59 can get them access to the info they seek 18:06:13 mmaslano but it should be done before freeze if there are broken packages 18:06:43 mitr mmaslano: We already froze for Beta 18:06:50 mmaslano yes 18:07:05 notting well, packages have been 'broken' inasmuch as there were two configuration files for two releases already. what is the plan if the work mjg59 is helping kay with does not happen? 18:07:20 nirik if there are pending fixes we could pass them thru the freeze as a NTH... or wait until after. 18:07:41 t8m As the breakage is not critical I think that the fixes can be done in updates 18:08:03 mmaslano so for now I agree with nirik's proposal 18:08:22 mitr notting: We are not currently equipped to handle that question AFAICT. (We do need to be, but that's for another time.) 18:08:57 * nirik shrugs. I don't think I would block on it. 18:08:58 t8m nirik, +1 18:09:09 nirik it would be very nice ot fix before release tho... 18:10:20 mjg59 Sure, where possible that clearly ought to happen 18:10:39 mmaslano more votes on nirik's proposal? 18:10:41 limburgher +1 nirik 18:10:56 mitr +1 I think 18:11:40 * nirik is for his own proposal too oddly enough. 18:11:46 * mmaslano too 18:11:56 notting +1 for lack of an alternative 18:12:01 pjones +1 I guess. 18:12:09 jwb sure 18:12:34 mmaslano #agreed defer for now and see if mjg59 can get them access to the info they seek (+8,-0) 18:12:34 pjones I mean, that's the process anyway if we /don't/ vote on it 18:12:55 mmaslano #topic #971 Freezing for Fedora 18 Beta 18:13:00 mmaslano .fesco 971 18:13:02 zodbot mmaslano: #971 (Freezing for Fedora 18 Beta) –
[Bug 876523] perl-Text-CSV_XS-0.92 is available
https://bugzilla.redhat.com/show_bug.cgi?id=876523 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-Text-CSV_XS-0.92-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-Text-CSV_XS-0.92-1.fc18 -- 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
Re: [fedora-arm] Fedora ARM weekly status meeting 2012-11-14
On Wed, Nov 14, 2012 at 6:20 PM, Paul Whalen pwha...@redhat.com wrote: Good day all, This weeks Fedora ARM status meeting will take place today (Wednesday Nov 14th) in #fedora-meeting-1 on Freenode. Times in various time zones (please let us know if these do not work): PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Current items on the agenda: 1) Problem packages needing attention 2) Exynos 5 (Chromebook) Kernel - Is anyone currently working on this? 3) SE Linux issue with F18 kernels - status update 4) SFP images for F18 Beta - What images will be produced? 5) FUDCon Lawrence ARM activity planning If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting. Issues with koji builds/builders/rewRepos. Preferably if we could put this before 5) so I can depart and go to sleep I would appreciate it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Wed, Nov 14, 2012 at 09:44:55AM -0500, Gregory Maxwell wrote: On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams cmad...@hiwaay.net wrote: Great - let's take something that people are using, remove that functionality, and not announce it! This is not cool; it represents one of my biggest frustrations with a bunch of the new and improved ways of doing things. You track down how to do something, it works for a few releases, and then it doesn't anymore with no notice. I don't mind this much in isolation— and to some extent its unavoidable if there is to be progress. I also have the experience and impression that Fedora often dismisses use cases in the 'long tail' as things that power users can get by twiddling some opaque config file or registry entry or hacking some bit of code— this happens more often the closer you get to the desktop, but believe its a culture which permeates the project more generally than that. In isolation this too would be occasionally frustrating but finite in baddness. The combination of the two— that anything non-stock is subject to constant and often undocumented breakage _and_ that many non nearly-universal use cases are too non-mainstream to consider supportable stock features really diminishes the value I receive from using a distribution at all. I was trying yesterday to formulate a question for the people running for FESCo along these lines; also what they thought about: https://news.ycombinator.com/item?id=4772133 However I wasn't able to formulate a snappy and non-carping question in time for the deadline. Still, I do believe it's something that FESCo (those elected and those standing for election) ought to address. 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: remove polkit from core?
On 11/14/2012 07:33 PM, Richard W.M. Jones wrote: On Wed, Nov 14, 2012 at 09:44:55AM -0500, Gregory Maxwell wrote: On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams cmad...@hiwaay.net wrote: Great - let's take something that people are using, remove that functionality, and not announce it! This is not cool; it represents one of my biggest frustrations with a bunch of the new and improved ways of doing things. You track down how to do something, it works for a few releases, and then it doesn't anymore with no notice. I don't mind this much in isolation— and to some extent its unavoidable if there is to be progress. I also have the experience and impression that Fedora often dismisses use cases in the 'long tail' as things that power users can get by twiddling some opaque config file or registry entry or hacking some bit of code— this happens more often the closer you get to the desktop, but believe its a culture which permeates the project more generally than that. In isolation this too would be occasionally frustrating but finite in baddness. The combination of the two— that anything non-stock is subject to constant and often undocumented breakage _and_ that many non nearly-universal use cases are too non-mainstream to consider supportable stock features really diminishes the value I receive from using a distribution at all. I was trying yesterday to formulate a question for the people running for FESCo along these lines; also what they thought about: https://news.ycombinator.com/item?id=4772133 However I wasn't able to formulate a snappy and non-carping question in time for the deadline. Still, I do believe it's something that FESCo (those elected and those standing for election) ought to address. Why are other OS and upstream decision/discussion int their regard fesco problem? Should not their focus be first and foremost on our own distribution and our own OS? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
- Original Message - On Wed, Nov 14, 2012 at 1:24 PM, Matthew Miller If David is unwilling to just resurrect the old .pkla parser, one option for solving the problem might be writing a piece of code that would provide compatibility with the .pkla files. This could be (the only) JS config snippet parsing the files directly if the JS environment allowed file system access, or alternatively a generator run before starting polkit to generate a large JS config representing the contents of .pkla files. Anyone interested in implementing it? The .pkla syntax wasn't particularly appealing or expressive, and there was only a handful of packages using it. I don't really think it is particularly worth reviving. If a declarative syntax is needed, I suggest that the security team simply picks their favourite language, and then implements a single js rule that calls out to a commandline utility implementing that language. Checking compliance should be very simple then - just check that the single single rule is the one you put in place. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revamping the non responsive maintainer process
On 11/11/2012 10:01 PM, Orion Poplawski wrote: On 11/06/2012 06:07 AM, Marcela Mašláňová wrote: Oh no, you are top posting again ;-) And please, please, please could we trim quotes to relevant ones? Thanks! Ohmahgerd, thank you for saying that. I am all for bottom posting but the _reason_ for bottom posting is that one responds to a specific phrase in the original. When people bottom-post a short reply under dozen-quoting-levels, multi-paragraph quote, it's actually less useful than if they just top-posted. In other words, bottom posting should not be a cargo cult, but instead a result of commitment to careful editing and meaningful communication. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM weekly status meeting minutes 2012-11-14
Good day all, Thanks to those who were able to join us for the weekly status meeting today. For those that were unable, the minutes are posted below: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-14/fedora-meeting-1.2012-11-14-21.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-14/fedora-meeting-1.2012-11-14-21.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-14/fedora-meeting-1.2012-11-14-21.00.log.html Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 13.11.2012 18:35, Richard W.M. Jones wrote: Hmmm: $ echo '' true.ml $ ocamlopt.opt true.ml -o true $ time ./true real 0m0.002s user 0m0.000s sys0m0.001s time luajit -e require'os'; os.exit(42) real0m0.001s user0m0.000s sys 0m0.000s But, check here for a far more important feature: http://luajit.org/ext_ffi_tutorial.html#zlib all this in 452088 bytes (libluajit.so, x86_64): This seems about right to me: Both ocamlopt gcc generate native x86-64 programs, but there's a small amount of overhead in the OCaml binary (initializing the minor heap of the GC). luajit too (it is one of the fastest compilers) I will try to formulate an approach for Fedora to benefit from this little miracle in additional note (SWIG bindings problems above in the thread). Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdf5 1.8.10 being pushed to rawhide
On 11/14/2012 09:02 AM, Orion Poplawski wrote: I'll be building hdf5 1.8.10 for rawhide shortly. This will require a rebuild of all hdf5 using packages. I'll try to get to most of them today. This has been delayed due to an unexpected issue. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12.11.12 11:28, Matthew Miller (mat...@fedoraproject.org) wrote: Okay, cool -- there's a lot of enthusiasm for a SIG for the core package set. So, first up on the SIG goals: clarifying our target. It's been suggested before that there's so many possibilities that this is useless, but the point here is to *pick* a reasonable choice as a group and to work with that (even if we can't get complete consensus). Then, later, when someone says but minimal could mean so many differen things! we simply say sure, but *this* is what we mean. I see three basic options for the target: A) kernel + init system and we're done B) boot to yum (with network): a text-mode bootstrap environment on which other things can be added by hand (or by kickstart) C) a traditional Unix command line environment with the expected basic tools available To me, 'C' is too wide for two reasons. First, it's too open for continual debate, because different people might expect different tools. Second, it's not necessarily the right base for the rest of the distribution, because many use cases might not really need that traditional Unix environment. I think 'A' is interesting and useful, but I don't think it should be our target, because it's not *useful enough*. We may want to eventually define a sub-group which covers just this tiny base (maybe with busybox?), but I think that's a different project. So that leaves me at *mostly B*, although I have some sympathy to the idea that we should include a few other things like a man page reader, since we're installing man pages, and a way to deliver e-mail to root, since we're installing things that send such mail. And I think the core environment should include ssh, but I'm open to the idea that even that should be an add-on. What do you think? I think a good way to approach this is by looking for the interesting usecases for a minimal installation: A) Containers B) VMs C) Bare-Metal Servers D) Paranoid people (not relevant) E) Embedded (out of focus for Fedora) ... anything else? I list A and B as separate items, since they have different needs. For A you don't want SSH or bootloader (the bootloader is not necessary, as the container manager will directly invoke init, and you can login via local console). For B you you need a bootloader and probably SSH. I think it would make sense to focus on the intersection of installation set for these usecases. And hence: No SSH. No Boot loader. And definitely not Sendmail. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Thu, 15.11.12 00:56, Lennart Poettering (mzerq...@0pointer.de) wrote: I think a good way to approach this is by looking for the interesting usecases for a minimal installation: A) Containers B) VMs C) Bare-Metal Servers D) Paranoid people (not relevant) E) Embedded (out of focus for Fedora) ... anything else? I list A and B as separate items, since they have different needs. For A you don't want SSH or bootloader (the bootloader is not necessary, as the container manager will directly invoke init, and you can login via local console). For B you you need a bootloader and probably SSH. I think it would make sense to focus on the intersection of installation set for these usecases. And hence: No SSH. No Boot loader. And definitely not Sendmail. Also, no kernel and no kmod for A, as that is provided by the container host. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Thu, 15 Nov 2012 01:03:03 +0100 Lennart Poettering mzerq...@0pointer.de wrote: ...snip... I think it would make sense to focus on the intersection of installation set for these usecases. And hence: No SSH. No Boot loader. And definitely not Sendmail. Also, no kernel and no kmod for A, as that is provided by the container host. That doesn't look like an intersection to me. ;) How about a separate group for containers, since the packages and use case are very different than 'core' provides? @core-container ? or @container ? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 14.11.12 08:18, Chris Adams (cmad...@hiwaay.net) wrote: Once upon a time, Thomas Bendler m...@bendler-net.de said: Does an MTA really make sense in the core definition? The configuration of MTA is nowadays much more complex compared to the old days. Normaly you need a FQDN, you need a SMTP relay and lot other stuff more. So you will only get the mails off the system after a lot of configuration work which can, from my point of view, also include the installation of an MTA. Well, as soon as you have cron, you'll have things wanting to send email, and even sendmail mail to root on the local system requires some type of MTA in most cases. I am pretty sure the default should be to push everything to the logs. But note that in the container case you are likely to encounter a setup where you install the host host, and then add one container for mail, another one for web, a third one for database, and so on. If you do that it would be really bogus to include sendmail in the minimal set... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 14.11.12 10:34, john.flor...@dart.biz (john.flor...@dart.biz) wrote: From: Chris Adams cmad...@hiwaay.net Well, as soon as you have cron, you'll have things wanting to send email, and even sendmail mail to root on the local system requires some type of MTA in most cases. From my experience, an MTA is still not required. Any stdout/err from the cron jobs just go to the syslog, but this may be systemd's journal magic that I've been seeing. cronie is actually able to log the cron output to syslog since a long time. I haven't been running MTAs on any of my machines for a many years now. If you deinstall the MTA then cronie will log a error message that sendmail wasn't around, and then go on and log job output to syslog. This error message is really pointless and should go away. Honestly, we really should drop sendmail from the default install of *all* systems, not just the minimal installations. It is simply not useful without configuration, and nothing else we install requires it, not even cronie. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 14.11.12 17:05, Kevin Fenzi (ke...@scrye.com) wrote: On Thu, 15 Nov 2012 01:03:03 +0100 Lennart Poettering mzerq...@0pointer.de wrote: ...snip... I think it would make sense to focus on the intersection of installation set for these usecases. And hence: No SSH. No Boot loader. And definitely not Sendmail. Also, no kernel and no kmod for A, as that is provided by the container host. That doesn't look like an intersection to me. ;) Well, if you look at all the usecases it happens that the container usecase ends up being the most minimal, and hence the intersection of all of them. How about a separate group for containers, since the packages and use case are very different than 'core' provides? @core-container ? or @container ? Well, it would be weird that the minimal installation is actually not minimal at all, but the container installation is. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 14 November 2012 17:13, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 14.11.12 17:05, Kevin Fenzi (ke...@scrye.com) wrote: On Thu, 15 Nov 2012 01:03:03 +0100 Lennart Poettering mzerq...@0pointer.de wrote: ...snip... I think it would make sense to focus on the intersection of installation set for these usecases. And hence: No SSH. No Boot loader. And definitely not Sendmail. Also, no kernel and no kmod for A, as that is provided by the container host. That doesn't look like an intersection to me. ;) Well, if you look at all the usecases it happens that the container usecase ends up being the most minimal, and hence the intersection of all of them. How about a separate group for containers, since the packages and use case are very different than 'core' provides? @core-container ? or @container ? Well, it would be weird that the minimal installation is actually not minimal at all, but the container installation is. I didn't think one installed an OS inside a container.. but basically copied what one wanted into it... eg running anaconda to build a container means you already went too far :). Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 14.11.12 17:15, Stephen John Smoogen (smo...@gmail.com) wrote: How about a separate group for containers, since the packages and use case are very different than 'core' provides? @core-container ? or @container ? Well, it would be weird that the minimal installation is actually not minimal at all, but the container installation is. I didn't think one installed an OS inside a container.. but basically copied what one wanted into it... eg running anaconda to build a container means you already went too far :). Oh, I wasn't aware that this is solely about anaconda-based installs, sorry. For containers a yum group for usage with --installroot= is the only thing that matters. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: network service fails to set wireless parameters.
Dan Williams wrote: Could be because your wifi adapter is a recent one, and thus uses the preferred upstream nl80211 kernel configuration API. It's an Intel PRO/Wireless 2200bg, so not exactly recent. In addition, the wext api of operation 1, then operation 2, then operation 3 simply doesn't work well for newer devices, and never worked very well for old ones, and it's possible that the driver for your wifi device doesn't like the sequence that the initscripts use. When I use iwconfig manually I have to set the mode before the SSID and the channel, if that's what you mean. You don't seem to think the problem is in my ifcfg file, so I filed a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=876786 Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 14 November 2012 17:19, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 14.11.12 17:15, Stephen John Smoogen (smo...@gmail.com) wrote: How about a separate group for containers, since the packages and use case are very different than 'core' provides? @core-container ? or @container ? Well, it would be weird that the minimal installation is actually not minimal at all, but the container installation is. I didn't think one installed an OS inside a container.. but basically copied what one wanted into it... eg running anaconda to build a container means you already went too far :). Oh, I wasn't aware that this is solely about anaconda-based installs, sorry. Well actually I think the correct question here is.. is this about anaconda based installs which was my guess when reading through this. However it is an assumption.. which means I am probably as much an ass as an umption in it. For containers a yum group for usage with --installroot= is the only thing that matters. Where I think the core-container would go to define that. But again.. my assumptions may be as wrong as anything. -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher arequip...@gmail.com wrote: On 11/13/2012 06:55 PM, Adam Williamson wrote: It might be worth re-evaluating whether that's realistic any more, though, and whether we're _really_ committed to finally replacing network with NM in some kind of reasonable timeframe. To this point, NetworkManager has failed to gain basic bridge support. In the meantime, Open vSwitch, which has a ton more configuration options has been recently added to the distro. I'd argue that NM actually continues to fall farther behind. Yeah, I love NetworkManager until it bites me - I've lost count of how many times I've been in a coffee shop and had to use 'sudo nmcli con del id' to get back online. ;-) -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Time synchronization inside virtual machines is a. Hypervisor-dependent. See the docs for VirtualBox, VMware, Xen and kvm and read the fine print. I don't even know if there *is* documentation for EC2. b. Poorly documented and difficult to test. If you don't *need* anything better than NTP / one second synchronization, don't waste your time. c. A mine field if you *do* need something better. Stay safe out there. ;-) On Wed, Nov 14, 2012 at 7:22 AM, john.flor...@dart.biz wrote: From: Stephen John Smoogen smo...@gmail.com On Tue, Nov 13, 2012 at 08:00:23PM -0500, Ben Cotton wrote: On EC2 (as in many virt environments) the hardware clock source is actually synced and running an ntpd service on the client is redundant. bikeshed=blue They say it is but it is not always. I have had multiple cases in KVM and some in Xen where supposedly the clock is kept up but what you end up is actually watching time go backwards if you hit heavy load in IO or CPU or Mem. Of course if you run into hardware like that.. you can install it after your DB has gone poopsies. /bikeshed I've seen that happen as well. I found this by hitting the pause button on the guest IIRC. I just always use NTP to avoid the worry, but I agree NTP (whether ntpd or chronyd) belongs in @standard not @core. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 4:03 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 15.11.12 00:56, Lennart Poettering (mzerq...@0pointer.de) wrote: I think a good way to approach this is by looking for the interesting usecases for a minimal installation: A) Containers B) VMs C) Bare-Metal Servers D) Paranoid people (not relevant) E) Embedded (out of focus for Fedora) ... anything else? I list A and B as separate items, since they have different needs. For A you don't want SSH or bootloader (the bootloader is not necessary, as the container manager will directly invoke init, and you can login via local console). For B you you need a bootloader and probably SSH. I think it would make sense to focus on the intersection of installation set for these usecases. And hence: No SSH. No Boot loader. And definitely not Sendmail. Also, no kernel and no kmod for A, as that is provided by the container host. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel It's been a while since I did anything with containers (LXC) but as I recall they're pretty much unmanageable without being able to ssh into them. But yes, I do think the bare-assed minimum viable Fedora is an LXC guest that one can get a console of some kind on and install packages into via yum. I'd even be willing to give up vim for nano. I don't need bash-completion or locate or man pages. ;-) -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
LuaJIT - an alternative for current Python C bindings (was: Re: raising warning flag on firewalld-default feature)
On 12.11.2012 21:34, Steve Grubb wrote: But the problem I see is a lot of libraries are wrapped by swig, which leaks memory like a sieve. If swig didn't generate such leaky code, Python based daemons wouldn't be as scary. IMHO, Python is one of the best ways to express management logic. As have stated elsewhere in the thread, from the footprint perspective, python-libs can be decomposed to something including much smaller python-libs-core. The remaining problem is the quality of part of the C bindings. Otherwise, it is great advantage for Fedora that huge part of the system tools are already polished in Python (my own experience is that the C code in many tools/libs shipped with Fedora is of relative poor quality, as already Miloslav explained). David Malcolm already has some real results addressing the Python bindings issues trough static analysis based on his great gcc-python-plugin/libcpychecker work. In the future, this machinery can be used for bug free bindings generation too. Another option for addressing this is ... to just get rid of part of them in their current form. LuaJIT 2.0 is a reimplementation of Lua scripting language, which has build the reputation of one of the fastest compilers (comparable only with gcc) in the course of his 3 years! beta cycle (2.0 final release was announced early this week) The size of luajit.so (interpreter + trace compiler + C parser for the FFI definitions) is 452088 bytes (on x86_64, for comparison sqlite3.so, which is a python requirement is 677672) Unlike other FFI implementations LuaJIT FFI works compiling the functions calls/C structs access to native code. Another difference is that the foreign C definitions are presented in native C syntax: http://luajit.org/ext_ffi_tutorial.html#zlib On top of this kind of FFI, LuaJIT already have bunch of library bindings - as instance the kernel ABI wrapper: https://github.com/justincormack/ljsyscall For a long time already Fedora ships lunatic-python (loading and bridging the Lua interpreter as python module) More recent and feature complete bridge is: https://github.com/scoder/lupa from the author of lxml module. So, to me it seems natural joining all above together to start thinking for replacing the classic python C bindings with thin textual or bytecode(*) LuaJIT/FFI shims in benefit of things with great set of dependencies like Anaconda (thanks to lupa, Lua objects behaves like Python ones in Python). The result will be order of magnitude easier for maintenance (towards the APIs evolution) and faster code. Furthermore, we can get LuaJIT for free, because it is full API/ABI compatible with current Fedora (PUC Rio) Lua 5.1, which is pulled by RPM anyway - we can just replace Lua with LuaJIT as RPM provider for F20. Kind Regards, Alek (*) Unlike original Lua, LuaJIT bytecode is portable across architectures. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Tue, 13.11.12 18:03, Thomas Woerner (twoer...@redhat.com) wrote: The security team asked me not to make firewalld a D-BUS driven mechanism, because of security concerns and also because of SELinux. Uh? If you write a new D-Bus service and want to use bus activation, then you should SystemdService= in the dbus service snippet, so that the actual activation is done by systemd. If you do that, then the effective difference regarding the execution environment of the service is next to zero, you just have two different triggers (start this on boot vs. start this when dbus tells systemd to). In fact, all system bus services should be configured to defer activation to systemd, so that all services regardless how they are triggered are executed in the same clean execution environment, and can be manipulated with the same commands (systemctl stop/kill/restart/mask/...) as any other services. In fact, even if you write a bus service that is started at boot, you should *always* make it bus activatable as well. Why? For two reasons: you make things robust that way, as the service is restarted when needed should it have died, and you enable parallelized boot-up, since services requiring your services don't have to be ordered explicitly after yours, but can just talk to your service name and dbus will queue all messages until your service is actually up. Hence: please make your service bus-activatable. In all cases. There are no security concerns, and you make things faster and more robust by doing this. Additionally every load of the mechanism could have to load modified or removed configuration files. So how should it get to the same state then again? How should it react on and reflect configuration changes? So it would have to write out everything - the state and all configuration files. I am sorry, but this is overkill and a most likely a source of big problems. Actually, no, it's not overkill, it's good coding practice. Most of systemd's various little services (not all though) are written that they can be killed and restarted at any time without losing any state (such as logind, udevd, timedated, localed, hostnamed, ...). In fact even systemd itself can exit and be reexecuted while recovering almost all previous state. (In fact, currently the one exception of the systemd services that can't just be killed without negative effect is journald, but we are working on that). It's really not that hard. I think it's a really good rule to make all low-level system daemons work that way, to keep things robust and resource usage minimal. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Sat, 10.11.12 09:26, Richard W.M. Jones (rjo...@redhat.com) wrote: On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote: Matthew Miller wrote: Apparently the new version of polkit brings in javascript. The js package is 6.5MB. I think anything that uses polkit will depend on it -- can we remove it from core? Of course, the real question is why the heck PolicyKit needs a Turing- complete rule language (which also forced everyone to port their existing rules) when the previously-used simple INI-style pkla rule format did the job just fine! And Unix groups worked OK before that (and still do for the majority of purposes). OK, I'll bite. So: Did they really? If you want to allow a user to execute a specific privileged operation once (let's say format a USB stick), and you grant him group membership for that, then he can drop a SETGID binary for that group somewhere and will have the permission forever. Effectively, you can never take group membership away. Also, creating individual groups for all the various privileged operations we have simply doesn't scale. So, PK's usecase is a valid and an important one. You cannot replace that by Unix groups. Making PK uninstallable hence really is not about removing something that was generally not necessary. It is simply about removing something that is not necessary in the specific usecase of a server setup where no local unprivileged users exist that might need to execute privileged operations interactively. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Thu, 2012-11-15 at 02:10 +0100, Lennart Poettering wrote: On Sat, 10.11.12 09:26, Richard W.M. Jones (rjo...@redhat.com) wrote: On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote: Matthew Miller wrote: Apparently the new version of polkit brings in javascript. The js package is 6.5MB. I think anything that uses polkit will depend on it -- can we remove it from core? Of course, the real question is why the heck PolicyKit needs a Turing- complete rule language (which also forced everyone to port their existing rules) when the previously-used simple INI-style pkla rule format did the job just fine! And Unix groups worked OK before that (and still do for the majority of purposes). OK, I'll bite. So: Did they really? If you want to allow a user to execute a specific privileged operation once (let's say format a USB stick), and you grant him group membership for that, then he can drop a SETGID binary for that group somewhere and will have the permission forever. Effectively, you can never take group membership away. Not saying that groups are always the best option, but I am always amused by this permanent group membership. Makes it sound like nobody invented mounting homes with the nosuid mount option and that admins haven't yet discovered find -perm if indeed there is a file system where users are allowed to drop sgid set binaries ... Also, creating individual groups for all the various privileged operations we have simply doesn't scale. This is a better argument. So, PK's usecase is a valid and an important one. You cannot replace that by Unix groups. You might say that it would be difficult or inconvenient, but it can be replaced if you really want to. Whether it would make sense to try is a different story ... Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 2012-11-14 at 16:27 -0800, M. Edward (Ed) Borasky wrote: On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher arequip...@gmail.com wrote: On 11/13/2012 06:55 PM, Adam Williamson wrote: It might be worth re-evaluating whether that's realistic any more, though, and whether we're _really_ committed to finally replacing network with NM in some kind of reasonable timeframe. To this point, NetworkManager has failed to gain basic bridge support. In the meantime, Open vSwitch, which has a ton more configuration options has been recently added to the distro. I'd argue that NM actually continues to fall farther behind. Yeah, I love NetworkManager until it bites me - I've lost count of how many times I've been in a coffee shop and had to use 'sudo nmcli con del id' to get back online. ;-) SCOPE CREEP ALARM! AWOOGA! AWOOGA! Unless you actually think the network scripts are a better way of managing casual wireless connections, I think this is a bit out of scope, as we can already chalk up 'casual wireless connections' in the 'win' column for NetworkManager - it's already better than network.service at that. it may not be *perfect*, but it's *better*. The context here is not 'let's all get our NM pet peeves out of our systems', but 'what does network.service still do better than NM, and how long is it going to take to fix that?' -- 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: Setting the default firewall configuration (was Re: Attention, dependency fighters)
Miloslav Trmač wrote: Looking at hour original warning flag: Squeezing every last megabyte out of the running system for cloud is a really new thing that we haven't historically required. Sure, it would be great to make firewalld smaller (and rewriting firewalld to C is one of those things that have been promised a long time ago and never happened), but I don't really see that as a blocker. The C rewrite should be treated as a requirement for being considered anything other than a prototype. We'd get the 8-years duplication of init.d/network vs. NetworkManager all over again, and I personally strongly want to avoid that (this was a third of my FESCo election platform). Well, I'm not too happy about having 2 ways of doing things either. However, I really don't see the point of running a Python daemon to dynamically control something I never change in the first place. Now, sure, firewalld also does connection tracking and I'd personally have no problems running a lightweight C daemon to handle that, but why on Earth does it have to be in Python? And what about the many system administrators using handwritten rules (see Harald Reindl's reply)? system-config-firewall is a Fedora- specific UI with limited functionality which it makes sense to replace with something more flexible, but iptables rules are a long-established cross- distribution interface, won't firewalld stomp on those rules, by the way it works? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 15.11.2012 02:19, Lennart Poettering wrote: For containers a yum group for usage with --installroot= is the only thing that matters. FWIW, For me Anaconda is overkill for the KVM guest images too. I am used to do that with small xquery script (easy for the libvirt domain definition) containing: yum (conf, root) install setup kernel acpid chrony acl attr audit rsyslog dhclient openssh-server openssh-clients rootfiles yum (yum dep-solves the above to 152 packages for F17, x86_64) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Alek Paunov wrote: On 13.11.2012 18:35, Richard W.M. Jones wrote: This seems about right to me: Both ocamlopt gcc generate native x86-64 programs, but there's a small amount of overhead in the OCaml binary (initializing the minor heap of the GC). luajit too (it is one of the fastest compilers) Unlike the others, it generates the native code at runtime (Just In Time), so there is a performance penalty (especially for nontrivial programs) for the (JIT) compilation which gcc and ocamlopt won't have. The quality of the generated code could also be a problem (for nonempty programs): Optimized compilation takes time! So there's a tradeoff between the time of the JIT compilation and the time of the actual execution, a very fast JIT is not necessarily optimal because it may be missing important optimizations of the compiled code. In other words: Try nontrivial benchmarks before claiming victory. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 6:02 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2012-11-14 at 16:27 -0800, M. Edward (Ed) Borasky wrote: On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher arequip...@gmail.com wrote: On 11/13/2012 06:55 PM, Adam Williamson wrote: It might be worth re-evaluating whether that's realistic any more, though, and whether we're _really_ committed to finally replacing network with NM in some kind of reasonable timeframe. To this point, NetworkManager has failed to gain basic bridge support. In the meantime, Open vSwitch, which has a ton more configuration options has been recently added to the distro. I'd argue that NM actually continues to fall farther behind. Yeah, I love NetworkManager until it bites me - I've lost count of how many times I've been in a coffee shop and had to use 'sudo nmcli con del id' to get back online. ;-) SCOPE CREEP ALARM! AWOOGA! AWOOGA! Unless you actually think the network scripts are a better way of managing casual wireless connections, I think this is a bit out of scope, as we can already chalk up 'casual wireless connections' in the 'win' column for NetworkManager - it's already better than network.service at that. it may not be *perfect*, but it's *better*. The context here is not 'let's all get our NM pet peeves out of our systems', but 'what does network.service still do better than NM, and how long is it going to take to fix that?' -- 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 the current context, a minimal Fedora, I'd argue that NetworkManager is overkill too. An openSUSE / SUSE Studio JEOS or server appliance defaults to some kind of DHCP client built on top of whatever the base networking tools are in openSUSE. You have to specifically *ask* for NetworkManager if you want it. I don't even think the bridge tools are included at that minimalist level. You get a firewall, yes, and DHCP too but ssh is optional - you probably have to go in with 'vi' from the console and edit configuration files to make networking happen beyond that. While we're on the subject of minimalism, does yum default to installing suggested packages on top of required ones? -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LuaJIT - an alternative for current Python C bindings (was: Re: raising warning flag on firewalld-default feature)
How much Python code are you proposing someone ports to Lua? ;-) On Wed, Nov 14, 2012 at 4:49 PM, Alek Paunov a...@declera.com wrote: On 12.11.2012 21:34, Steve Grubb wrote: But the problem I see is a lot of libraries are wrapped by swig, which leaks memory like a sieve. If swig didn't generate such leaky code, Python based daemons wouldn't be as scary. IMHO, Python is one of the best ways to express management logic. As have stated elsewhere in the thread, from the footprint perspective, python-libs can be decomposed to something including much smaller python-libs-core. The remaining problem is the quality of part of the C bindings. Otherwise, it is great advantage for Fedora that huge part of the system tools are already polished in Python (my own experience is that the C code in many tools/libs shipped with Fedora is of relative poor quality, as already Miloslav explained). David Malcolm already has some real results addressing the Python bindings issues trough static analysis based on his great gcc-python-plugin/libcpychecker work. In the future, this machinery can be used for bug free bindings generation too. Another option for addressing this is ... to just get rid of part of them in their current form. LuaJIT 2.0 is a reimplementation of Lua scripting language, which has build the reputation of one of the fastest compilers (comparable only with gcc) in the course of his 3 years! beta cycle (2.0 final release was announced early this week) The size of luajit.so (interpreter + trace compiler + C parser for the FFI definitions) is 452088 bytes (on x86_64, for comparison sqlite3.so, which is a python requirement is 677672) Unlike other FFI implementations LuaJIT FFI works compiling the functions calls/C structs access to native code. Another difference is that the foreign C definitions are presented in native C syntax: http://luajit.org/ext_ffi_tutorial.html#zlib On top of this kind of FFI, LuaJIT already have bunch of library bindings - as instance the kernel ABI wrapper: https://github.com/justincormack/ljsyscall For a long time already Fedora ships lunatic-python (loading and bridging the Lua interpreter as python module) More recent and feature complete bridge is: https://github.com/scoder/lupa from the author of lxml module. So, to me it seems natural joining all above together to start thinking for replacing the classic python C bindings with thin textual or bytecode(*) LuaJIT/FFI shims in benefit of things with great set of dependencies like Anaconda (thanks to lupa, Lua objects behaves like Python ones in Python). The result will be order of magnitude easier for maintenance (towards the APIs evolution) and faster code. Furthermore, we can get LuaJIT for free, because it is full API/ABI compatible with current Fedora (PUC Rio) Lua 5.1, which is pulled by RPM anyway - we can just replace Lua with LuaJIT as RPM provider for F20. Kind Regards, Alek (*) Unlike original Lua, LuaJIT bytecode is portable across architectures. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing A weem oh way! at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 15.11.2012 04:32, Kevin Kofler wrote: Unlike the others, it generates the native code at runtime (Just In Time), so there is a performance penalty (especially for nontrivial programs) for the (JIT) compilation which gcc and ocamlopt won't have. The quality of the generated code could also be a problem (for nonempty programs): Optimized compilation takes time! So there's a tradeoff between the time of the JIT compilation and the time of the actual execution, a very fast JIT is not necessarily optimal because it may be missing important optimizations of the compiled code. All above is correct, with the small nuance that all practically significant slowdowns are always result of repeatable code paths (loops, recursions, etc) but these lands to near optimal native code after the first few iterations with this concrete implementation (Mike Pall is well known with his in-depth theoretical background). In other words: Try nontrivial benchmarks before claiming victory. I am. Check GSL shell for example. Nobody claims any victories (especially against gcc). The point is, that this concrete JIT is probably the fastest existing one and brings bunch of advantages at the cost of negligible footprint (compared with v8 for example). Have you played with LuaJIT apps already ... or speaking from common sense POV ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LuaJIT - an alternative for current Python C bindings
On 15.11.2012 04:51, M. Edward (Ed) Borasky wrote: How much Python code are you proposing someone ports to Lua? ;-) I am proposing mostly porting C code to Lua/FFI (the code of the problematic Python C bindings) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 09:36:17AM -0500, Matthew Miller wrote: Based on the conversation so far, I think the target is: - mandatory install of everything up to yum install from the network - default install of a small set of packages necessary for a consistent Fedora experience including minimal admin tools Is there any reason those two can't be split up? Maybe @really-hard-core for the first, and @core for the second. ;-) Alternatively, I could see where the first is marked required, but the second is marked default so it can be deselected in a kickstart config without needing to rpm -e it in %post. -- Scott Schmit smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi 0.9.3 deployed to production
Luke Macken wrote: A new bugfix release of Bodhi has just been deployed to production. https://admin.fedoraproject.org/updates Bugs and enhancement requests can be filed here: http://bodhi.fedorahosted.org This seems to be closing bugs as CURRENTRELEASE rather than ERRATA now, is that intentional? If yes, why? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 2012-11-14 at 18:49 -0800, M. Edward (Ed) Borasky wrote: On Wed, Nov 14, 2012 at 6:02 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2012-11-14 at 16:27 -0800, M. Edward (Ed) Borasky wrote: On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher arequip...@gmail.com wrote: On 11/13/2012 06:55 PM, Adam Williamson wrote: It might be worth re-evaluating whether that's realistic any more, though, and whether we're _really_ committed to finally replacing network with NM in some kind of reasonable timeframe. In the current context, a minimal Fedora, I'd argue that NetworkManager is overkill too. We're going round in circles, here. The post of mine quoted above - five levels of quotation deep, 11/13/2012 - was a reply to someone saying the same thing. Please just read back to there, and break us out of this eternal loop. :) -- 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: [@core] working definition for the minimal package set
On Wed, 2012-11-14 at 22:23 -0500, Scott Schmit wrote: On Wed, Nov 14, 2012 at 09:36:17AM -0500, Matthew Miller wrote: Based on the conversation so far, I think the target is: - mandatory install of everything up to yum install from the network - default install of a small set of packages necessary for a consistent Fedora experience including minimal admin tools Is there any reason those two can't be split up? Maybe @really-hard-core for the first, and @core for the second. ;-) That's basically what Kevin proposed several mails back, and I agree it seems like we have two broadly definable cases here rather than one. -- 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: bodhi 0.9.3 deployed to production
On Thu, 2012-11-15 at 05:52 +0100, Kevin Kofler wrote: Luke Macken wrote: A new bugfix release of Bodhi has just been deployed to production. https://admin.fedoraproject.org/updates Bugs and enhancement requests can be filed here: http://bodhi.fedorahosted.org This seems to be closing bugs as CURRENTRELEASE rather than ERRATA now, is that intentional? If yes, why? There seems to be a mania for CURRENTRELEASE lately. I don't know where it's coming from. The policy clearly states ERRATA: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#CLOSED Now admittedly the policy is more or less something I pulled out of my ass a few years ago and I have my suspicions as to how many people a) have ever read it (few) or b) care (fewer). But hey, it's there. In the end we rarely do anything with the resolutions anyway, so I stopped caring as much as I used to, but at least our official tools should probably follow what are nominally our policies. Note that Fedora's policy differs *significantly* from Red Hat's here, as Fedora's update workflow is entirely different from RHEL's. https://bugzilla.redhat.com/page.cgi?id=fields.html - the 'help' page you get by clicking on various bits of a bug page - is RHEL's policy, not Fedora's. There is a link to the Fedora policy at the top of it. Unfortunately, most of the links to the fields.html page jump into the middle of it with anchors, so no-one sees the link. The other problem with our policy is that it's somewhat of a hack job, because it involves taking the resolutions that were written for RHEL's update process and make sense in that context and applying them the Fedora update process, in which context they really don't make sense at all. So several of the choices are just arbitrary decisions I made when I was writing the smegging thing. This is of course one of the drawbacks of sharing a bug tracker with RHEL, but then the point is always made that the effort of having our own would outweigh the benefits. Still, even in RHEL's policy, CURRENTRELEASE is clearly wrong for a straightforward 'this was a bug that got fixed and we pushed an update' case, so I don't know why people are suddenly plumping for it, other than that it somehow 'sounds right'. -- 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: bodhi 0.9.3 deployed to production
On Thu, Nov 15, 2012 at 6:15 AM, Adam Williamson awill...@redhat.com wrote: On Thu, 2012-11-15 at 05:52 +0100, Kevin Kofler wrote: Luke Macken wrote: A new bugfix release of Bodhi has just been deployed to production. https://admin.fedoraproject.org/updates Bugs and enhancement requests can be filed here: http://bodhi.fedorahosted.org This seems to be closing bugs as CURRENTRELEASE rather than ERRATA now, is that intentional? If yes, why? There seems to be a mania for CURRENTRELEASE lately. I don't know where it's coming from. The policy clearly states ERRATA: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#CLOSED Now admittedly the policy is more or less something I pulled out of my ass a few years ago and I have my suspicions as to how many people a) have ever read it (few) or b) care (fewer). But hey, it's there. In the end we rarely do anything with the resolutions anyway, so I stopped caring as much as I used to, but at least our official tools should probably follow what are nominally our policies. Note that Fedora's policy differs *significantly* from Red Hat's here, as Fedora's update workflow is entirely different from RHEL's. https://bugzilla.redhat.com/page.cgi?id=fields.html - the 'help' page you get by clicking on various bits of a bug page - is RHEL's policy, not Fedora's. There is a link to the Fedora policy at the top of it. Unfortunately, most of the links to the fields.html page jump into the middle of it with anchors, so no-one sees the link. The other problem with our policy is that it's somewhat of a hack job, because it involves taking the resolutions that were written for RHEL's update process and make sense in that context and applying them the Fedora update process, in which context they really don't make sense at all. So several of the choices are just arbitrary decisions I made when I was writing the smegging thing. This is of course one of the drawbacks of sharing a bug tracker with RHEL, but then the point is always made that the effort of having our own would outweigh the benefits. Still, even in RHEL's policy, CURRENTRELEASE is clearly wrong for a straightforward 'this was a bug that got fixed and we pushed an update' case, so I don't know why people are suddenly plumping for it, other than that it somehow 'sounds right'. Unless it's a bugfix that is pushed to multiple releases and the one your after isn't the one that made it stable first at which point errata IMO makes slightly more sense. After all in our case CURRENTRELEASE changes roughly every 6 months so it becomes a moving target. In RHEL CR makes more sense because it would be the current dot release in the X cycle, where X is 4/5/6/7 etc. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi 0.9.3 deployed to production
On Thu, 2012-11-15 at 06:31 +, Peter Robinson wrote: Still, even in RHEL's policy, CURRENTRELEASE is clearly wrong for a straightforward 'this was a bug that got fixed and we pushed an update' case, so I don't know why people are suddenly plumping for it, other than that it somehow 'sounds right'. Unless it's a bugfix that is pushed to multiple releases and the one your after isn't the one that made it stable first at which point errata IMO makes slightly more sense. After all in our case CURRENTRELEASE changes roughly every 6 months so it becomes a moving target. In RHEL CR makes more sense because it would be the current dot release in the X cycle, where X is 4/5/6/7 etc. CURRENTRELEASE is clearly only for niche cases by both the RHEL and Fedora definitions. RHEL: CURRENTRELEASE - The problem described has been fixed and only ever appeared in unsupported or unreleased products. Fedora: The resolution CURRENTRELEASE is to be used in the case where a bug is reported before a release is made, and subsequently discovered to be fixed in the final release. For instance, a bug is reported against Fedora 18 while it is still in the pre-release stages, and remains open when the release is made; however, when the final Fedora 18 is made, the reporter re-tests and discovers the bug was actually fixed. In this case, the CURRENTRELEASE resolution is used. Both of those make it pretty clear it's only to be used in specific, fairly unusual circumstances, not as the routine resolution for a bug filed through Bugzilla, accepted by the maintainer, and fixed in the normal course of events. (Though I think the name is a bit confusing if you're just trying to figure out what resolution to use based on the names alone). ERRATA is the 'correct' resolution for that case for both RHEL (post-release at least) and Fedora (post-Branched). -- 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
Retiring packages due to broken deps
Since the following packages seem to be unmaintained and have broken deps in Fedora 18, I propose that they be retired and blocked before release: libsyncml mod_pubcookie openvrml perl-OpenOffice-UNO pyfuzzy reciteword ruby-revolution rubygem-calendar_date_select znc-infobot These retirements would result in the following broken dependency: libopensync-plugin-syncml However, since nothing depends on libopensync-plugin-syncml, I propose that it also be retired and blocked. Additionally, these packages are already retired in Rawhide, I propose that they also be blocked in Fedora 18: rubygem-linecache rubygem-ruby-debug rubygem-ruby-debug-base tetex-tex4ht Blocking these in Fedora 18 will not result in any broken dependencies. Speak now, maintainers, or I'll process these as retired/blocked on Wednesday. (these packages have been broken a long time) ~tom == Fedora Project -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Crypt-PasswdMD5] Add license Beerware. Use DESTDIR rather than PERL_INSTALL_ROOT. Dont use macros for commands. Dont
commit 674d6e184bc7c1d6a4e7749ca4dce4ca9175835d
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Wed Nov 14 10:19:36 2012 +0100
Add license Beerware. Use DESTDIR rather than PERL_INSTALL_ROOT. Dont use
macros for commands. Dont need to remove empty directories from the buildroot.
Signed-off-by: Marcela Mašláňová mmasl...@redhat.com
perl-Crypt-PasswdMD5.spec | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
---
diff --git a/perl-Crypt-PasswdMD5.spec b/perl-Crypt-PasswdMD5.spec
index 98864b2..b38dd50 100644
--- a/perl-Crypt-PasswdMD5.spec
+++ b/perl-Crypt-PasswdMD5.spec
@@ -1,12 +1,12 @@
Name: perl-Crypt-PasswdMD5
Version: 1.3
-Release: 15%{?dist}
+Release: 16%{?dist}
Summary: Provides interoperable MD5-based crypt() functions
-License: GPL+ or Artistic
+License: (GPL+ or Artistic) and Beerware
Group: Development/Libraries
URL: http://search.cpan.org/dist/Crypt-PasswdMD5/
Source0:
http://search.cpan.org/CPAN/authors/id/L/LU/LUISMUNOZ/Crypt-PasswdMD5-%{version}.tar.gz
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
BuildArch: noarch
BuildRequires: perl(Digest::MD5)
BuildRequires: perl(Exporter)
@@ -22,13 +22,12 @@ This package provides MD5-based crypt() functions
%{__sed} -i -e 's/ISO-8859-1/UTF-8/' PasswdMD5.pm
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
+make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
-find %{buildroot} -type d -depth -exec rmdir {} 2/dev/null ';'
chmod -R u+w %{buildroot}/*
%check
@@ -40,6 +39,12 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Nov 13 2012 Jitka Plesnikova jples...@redhat.com - 1.3-16
+- Add license Beerware
+- Use DESTDIR rather than PERL_INSTALL_ROOT
+- Don't use macros for commands
+- Don't need to remove empty directories from the buildroot
+
* Thu Nov 01 2012 Jitka Plesnikova jples...@redhat.com - 1.3-15
- Add BR perl(Exporter)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTTP-Message] BuildRequire perl(Carp)
commit adb8d331a6db0f6bb498c2107fe48ddcc898ea85
Author: Petr Šabata con...@redhat.com
Date: Wed Nov 14 11:18:04 2012 +0100
BuildRequire perl(Carp)
perl-HTTP-Message.spec | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
---
diff --git a/perl-HTTP-Message.spec b/perl-HTTP-Message.spec
index 6bfd7d6..4cbd5d4 100644
--- a/perl-HTTP-Message.spec
+++ b/perl-HTTP-Message.spec
@@ -1,6 +1,6 @@
Name: perl-HTTP-Message
Version:6.06
-Release:1%{?dist}
+Release:2%{?dist}
Summary:HTTP style message
License:GPL+ or Artistic
Group: Development/Libraries
@@ -9,6 +9,7 @@ Source0:
http://www.cpan.org/authors/id/G/GA/GAAS/HTTP-Message-%{version}
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
# Run-time:
+BuildRequires: perl(Carp)
BuildRequires: perl(Compress::Raw::Zlib)
BuildRequires: perl(Encode) = 2.21
BuildRequires: perl(Encode::Locale) = 1
@@ -30,7 +31,7 @@ BuildRequires: perl(URI) = 1.10
BuildRequires: perl(Test)
BuildRequires: perl(Test::More)
# Testing requires Time::Local on MacOS only
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(Compress::Raw::Zlib)
Requires: perl(Encode) = 2.21
Requires: perl(Encode::Locale) = 1
@@ -62,13 +63,13 @@ requests, responses and the headers contained within them.
%setup -q -n HTTP-Message-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-make pure_install DESTDIR=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-%{_fixperms} $RPM_BUILD_ROOT/*
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+%{_fixperms} %{buildroot}/*
%check
make test
@@ -79,6 +80,10 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Nov 14 2012 Petr Šabata con...@redhat.com - 6.06-2
+- BuildRequire perl(Carp)
+- Modernize the spec and drop command macros
+
* Mon Oct 22 2012 Petr Pisar ppi...@redhat.com - 6.06-1
- 6.06 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-Leak] Clean specfile, apply perl_default_filter.
commit c927185bfa81bce3c326ed2012e98c7325d6
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Wed Nov 14 11:23:35 2012 +0100
Clean specfile, apply perl_default_filter.
perl-Devel-Leak.spec | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
---
diff --git a/perl-Devel-Leak.spec b/perl-Devel-Leak.spec
index 136852f..6127257 100644
--- a/perl-Devel-Leak.spec
+++ b/perl-Devel-Leak.spec
@@ -1,12 +1,11 @@
Name: perl-Devel-Leak
Version:0.03
-Release:19%{?dist}
+Release:20%{?dist}
Summary:Utility for looking for perl objects that are not reclaimed
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Devel-Leak/
Source0:
http://www.cpan.org/authors/id/N/NI/NI-S/Devel-Leak-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(ExtUtils::MakeMaker)
# Run-time:
BuildRequires: perl(base)
@@ -15,6 +14,8 @@ BuildRequires: perl(DynaLoader)
BuildRequires: perl(Test)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+%{?perl_default_filter}
+
%description
This module provides a basic way to discover if a piece of perl code
is allocating perl data and not releasing them again.
@@ -27,9 +28,7 @@ is allocating perl data and not releasing them again.
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
@@ -40,17 +39,21 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%check
make test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%files
-%defattr(-,root,root,-)
%doc README
%{perl_vendorarch}/auto/*
%{perl_vendorarch}/Devel*
%{_mandir}/man3/*
%changelog
+* Wed Nov 14 2012 Marcela Mašláňová mmasl...@redhat.com - 0.03-20
+- Remove BuildRoot definition.
+- Remove BuildRoot cleaning.
+- Replace PERL_INSTALL_ROOT with DESTDIR.
+- Remove cleaning empty directories.
+- Remove %defattr.
+- Do not export private library (Leak.so()).
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.03-19
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-No-Worries] Upgrade to latest version 0.7.
commit ae087a722593ad66e3018a63b9113f05301dbd0c
Author: Massimo massimo.pala...@gmail.com
Date: Wed Nov 14 11:37:16 2012 +0100
Upgrade to latest version 0.7.
.gitignore |1 +
perl-No-Worries.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5d258ed..1d87686 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
/No-Worries-0.4.tar.gz
/No-Worries-0.5.tar.gz
/No-Worries-0.6.tar.gz
+/No-Worries-0.7.tar.gz
diff --git a/perl-No-Worries.spec b/perl-No-Worries.spec
index 56c6bba..bbff335 100644
--- a/perl-No-Worries.spec
+++ b/perl-No-Worries.spec
@@ -1,5 +1,5 @@
Name: perl-No-Worries
-Version:0.6
+Version:0.7
Release:1%{?dist}
Summary:Perl coding without worries
License:GPL+ or Artistic
@@ -63,6 +63,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Nov 14 2012 Massimo Paladin massimo.pala...@gmail.com 0.7-1
+- Updating to latest upstream version.
+
* Thu Oct 04 2012 Massimo Paladin massimo.pala...@gmail.com 0.6-1
- Updating to latest upstream version.
diff --git a/sources b/sources
index cfecdff..26aae3a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-085eef94f3c253ec2e1220c95aed0549 No-Worries-0.6.tar.gz
+2392bf83b131ce4ee31f03da4b1f0b8e No-Worries-0.7.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-No-Worries/el5] Upgrade to latest version 0.7.
Summary of changes: ae087a7... Upgrade to latest version 0.7. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-No-Worries/el6] Upgrade to latest version 0.7.
Summary of changes: ae087a7... Upgrade to latest version 0.7. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-No-Worries/f16] Upgrade to latest version 0.7.
Summary of changes: ae087a7... Upgrade to latest version 0.7. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-No-Worries/f17] Upgrade to latest version 0.7.
Summary of changes: ae087a7... Upgrade to latest version 0.7. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-No-Worries/f18] Upgrade to latest version 0.7.
Summary of changes: ae087a7... Upgrade to latest version 0.7. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 875784] perl-CGI-3.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=875784 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC|mmasl...@redhat.com |ppi...@redhat.com Assignee|mmasl...@redhat.com |ppi...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 875784] perl-CGI-3.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=875784 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-CGI-3.62-1.fc19 Resolution|--- |RAWHIDE Last Closed||2012-11-14 05:06:15 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File MojoMojo-1.07.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for mojomojo: 457bf4e691a8c26f02d3c7e2d64611ad MojoMojo-1.07.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 876523] New: perl-Text-CSV_XS-0.92 is available
https://bugzilla.redhat.com/show_bug.cgi?id=876523 Bug ID: 876523 Keywords: FutureFeature, Triaged QA Contact: extras...@fedoraproject.org Severity: unspecified Version: rawhide Priority: unspecified CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Assignee: mmasl...@redhat.com Summary: perl-Text-CSV_XS-0.92 is available Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: upstream-release-monitor...@fedoraproject.org Type: --- Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: perl-Text-CSV_XS Product: Fedora Latest upstream release: 0.92 Current version in Fedora Rawhide: 0.91 URL: http://search.cpan.org/dist/Text-CSV_XS/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 861732] perlbrew-0.57 is available
https://bugzilla.redhat.com/show_bug.cgi?id=861732 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perlbrew-0.56 is available |perlbrew-0.57 is available -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 861732] perlbrew-0.57 is available
https://bugzilla.redhat.com/show_bug.cgi?id=861732 --- Comment #6 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 0.57 Current version in Fedora Rawhide: 0.50 URL: http://search.cpan.org/dist/App-perlbrew/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[mojomojo] update to 1.07
commit a6f060b380d9f127f34f301c04e8e3567ba9012c
Author: Iain Arnell iarn...@gmail.com
Date: Wed Nov 14 05:21:47 2012 -0700
update to 1.07
.gitignore |1 +
mojomojo-t-c-email.patch | 43
mojomojo-t-c-page_delete.patch | 21 ---
mojomojo.spec | 12 --
sources|2 +-
5 files changed, 7 insertions(+), 72 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index bcd40c1..f2ff086 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ MojoMojo-1.01.tar.gz
/MojoMojo-1.04.tar.gz
/MojoMojo-1.05.tar.gz
/MojoMojo-1.06.tar.gz
+/MojoMojo-1.07.tar.gz
diff --git a/mojomojo.spec b/mojomojo.spec
index c469e4a..d53dc9e 100644
--- a/mojomojo.spec
+++ b/mojomojo.spec
@@ -1,5 +1,5 @@
Name: mojomojo
-Version:1.06
+Version:1.07
Release:1%{?dist}
Summary:A Wiki with a tree
License:GPL+ or Artistic
@@ -13,10 +13,6 @@ Patch0: formatter-docbook.patch
# adjust paths
Patch2: mojomojo-paths.patch
-# https://github.com/mojomojo/mojomojo/issues/108
-Patch3: mojomojo-t-c-email.patch
-Patch4: mojomojo-t-c-page_delete.patch
-
BuildArch: noarch
# since it comes from CPAN, someone might expect to find
@@ -209,8 +205,6 @@ wiki page.
%setup -q -n MojoMojo-%{version}
%patch0 -p 1
%patch2 -p 1
-%patch3 -p 1
-%patch4 -p 1
# update the scripts for current catalyst
rm script/mojomojo_fastcgi_manage.pl
@@ -289,6 +283,10 @@ CATALYST_CONFIG=t/var/mojomojo.yml make test
%changelog
+* Wed Nov 14 2012 Iain Arnell iarn...@gmail.com 1.07-1
+- update to latest upstream version
+- drop email.t and page_delete.t patches
+
* Fri Nov 02 2012 Iain Arnell iarn...@gmail.com 1.06-1
- update to latest upstream version
- patch t/c/email.t and t/c/page_delete.t to work with current versions of
dependencies
diff --git a/sources b/sources
index e7c0c10..d6ed2f6 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f89931728a8ece0d82ff1d5f44729116 MojoMojo-1.06.tar.gz
+457bf4e691a8c26f02d3c7e2d64611ad MojoMojo-1.07.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 875603] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=875603 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-No-Worries-0.7-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-No-Worries-0.7-1.fc17 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
