Re: Chromium
Hi, On Tue, Mar 20, 2012 at 10:44 PM, Richard W.M. Jones rjo...@redhat.com wrote: which (right now) has precisely one other hit on Google. If you search for the demangled symbol, there are more references: v8::internal::I18NExtension::get() -Cam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 latest yum update hoses grub.cfg, grubby?
On Mar 20, 2012, at 11:53 PM, Adam Williamson wrote:
The yum update didn't update grub, but it did update the kernel. This is
the first time you have done a kernel update via yum with the new grub2.
grubby updates the grub.cfg file.
It seems reasonable to consider this a grubby bug, yes?
I think I found the problem in its grub.cfg (the one I named grub.cfg.bak). In
the two menuentry lines after ### BEGIN /etc/grub.d/10_linux; those menuentry
lines do not end with {. So everything after that is misinterpreted. Hence the
syntax errors and incorrect command.
The first menuentry that does end in { happens to be an entry for the old
kernel, a line that doesn't appear to have been modified by grubby or was
modified correctly.
Chris
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 latest yum update hoses grub.cfg, grubby?
On Mar 21, 2012, at 12:08 AM, Chris Murphy wrote: It seems reasonable to consider this a grubby bug, yes? Considering grub2-mkconfig -o /boot/grub2/grub.cfg produces the exact correct result, guess I'm not understanding the purpose of grubby. Are we in transition? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 latest yum update hoses grub.cfg, grubby?
On Wed, 2012-03-21 at 00:12 -0600, Chris Murphy wrote: On Mar 21, 2012, at 12:08 AM, Chris Murphy wrote: It seems reasonable to consider this a grubby bug, yes? Considering grub2-mkconfig -o /boot/grub2/grub.cfg produces the exact correct result, guess I'm not understanding the purpose of grubby. Are we in transition? grubby is less 'drastic' that grub2-mkconfig. it takes the existing config and appends a new entry to it. grub2-mkconfig blows away the config and starts over again each time. i don't recall whether we ever made a specific decision to keep using grubby over grub2-mkconfig or whether it's just inertia, though. pjones might. -- 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: H.264 in Fedora 17!
On Wed, Mar 21, 2012 at 2:58 AM, Simo Sorce s...@redhat.com wrote: [...] In the US instead patents have their root in a specific constitutional provision that says that this kind of monopoly can only be granted if it promotes innovation, this means there is no specific ban on software patents but given they arguably do not promote innovation they should naturally not be allowed, now you just need to wait for the US Congress to realize the Constitution tells them they cannot allow patents that do not promote innovation, good luck with that :) Unfortunately that does not matter ... what matters is who is sending the most bribes..^W donations. The software patent supporters send more of them so they win. Unless the supreme court does its job and tell them to stop (which it had many chances to do and refused). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 12:52:58PM -0700, Brendan Conoboy wrote: On 03/20/2012 12:44 PM, Chris Murphy wrote: Now the ultra ridiculous: How about secondary architecture requirements demoted as-is to tertiary. And create substantially more aggressive requirements for secondary architecture (in which ARM would be placed), yet are not identical requirements to primary architecture requirements? Yes, the all-or-nothing mindset between secondary and primary is almost certainly the root of the problem. We want more representation in Fedora than being a secondary connotes, Maybe you should begin by convincing package maintainers that ARM is a good platform (if it is; I do not know) and that they want to use it, instead of (figuratively speaking) shoving it down their throats by means of FESCo decision to promote ARM to primary arch. If you attract enough people, the transition may just happen naturally... D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, 2012-03-20 at 13:44 -0600, Chris Murphy wrote: Now the ultra ridiculous: How about secondary architecture requirements demoted as-is to tertiary. And create substantially more aggressive requirements for secondary architecture (in which ARM would be placed), yet are not identical requirements to primary architecture requirements? Yes, this might be actually the best short-term path. Or rather than demoting the other secondary architectures to tertiary status just have different scale for various secondary architectures in terms of official infrastructure support. I can see automatic spawning of secondary builds for ARM in the main koji instance, use of main bodhi, etc., etc. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: H.264 in Fedora 17!
Meanwhile, my Fedora post-installation instructions are quite popular on the Internet: http://avi.alkalay.net/2007/06/fedora-post-installation-configurations.html It is link #3 on a fedora h.264 Google search and I use to keep it updated. On 20/03/2012, at 23:11, Rahul Sundaram methe...@gmail.com wrote: On 03/21/2012 06:56 AM, Adam Williamson wrote: On Wed, 2012-03-21 at 01:46 +0100, Kevin Kofler wrote: Avi אבי Alkalay אלקלעי wrote: What are the legal tools that Ubuntu uses so it can ship H.264 ? It's based on the Isle of Man, not in the USA. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: H.264 in Fedora 17!
- Original Message - On Tue, 2012-03-20 at 22:29 -0400, Fedora Video wrote: In any case. This argument is moot. Fedora will distribute H.264 because it will be part of Firefox. No, it won't. You persist in misunderstanding this, though it has been explained to you. Firefox will take advantage of a system h264 codec where one is available. In the Fedora system, one will not be available. Firefox will not contain its own h264 codec. Even if Mozilla decides to ship theirs own bundled h264 decoding library, it will be against Fedora policies and it would have to be unbundled. The only thing we can do here is to make it easier for people to get these not nice codecs if they demand the support. Maybe in the same way as with Fluendo MP3 long time ago? If you want it, take the risks on you and pay the licence fees... But it brings us back to the do we want to support proprietary patented codecs and actually make them stronger by paying them? In the embedded world it's really more difficult - that's why FF mobile is going to adopt h264 - hw decoders as CPUs are not capable to decode the video on the fly. On desktops, we are able to decode WebM without hw support (even it's nice to have). R. -- 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: H.264 in Fedora 17!
On 20.3.2012 23:27, Kevin Kofler wrote: Even YouTube has adopted WebM. What the original author ignored to include was link to http://brendaneich.com/2012/03/video-mobile-and-the-open-web/ which explains the position of MoFo. What he completely missed is bug https://bugzilla.mozilla.org/show_bug.cgi?id=422540 around which we argued for years that MoFo should leave whole codecs business altogether and let platform systems (GStreamer, QuickTime, DirectShow) deal with it (as many WebKit-based browsers do now). If he read the bug and understood what it means, he would know that it has absolutely nothing to do with inclusion of H.264 in the Fedora proper. My system is perfectly capable of viewing H.264 movies now. Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution + bogofilter
On Tue, 2012-03-20 at 10:17 -0500, Mike Chambers wrote: Yes I understand it has to relearn. But it doesn't is the problem. I had to keep marking them as junk. Example, just reinstalled F16+updates on this very box. Started evo + the backup file as a restore, just as with F17. Soon as I marked the initial spam stuff in my inbox as junk, it started marking automatically. No, it doesn't get them all the time and have to relearn as I go, but it starts to immediately. F17 does NOT do it, almost none at all, even after a couple of days of marking them. Hi, try to run evolution from console like this: $ CAMEL_DEBUG=junk evolution which should tell you what evolution does when you mark message as junk/not-junk. It should print something when a new mail arrives too. This thread http://mail.gnome.org/archives/evolution-list/2011-November/msg00093.html is discussing similar issue with older evolution. It's rather long, but it contains some tests even for bogofilter database, checking how full it is and so on. Hope that helps, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: H.264 in Fedora 17!
On 21.3.2012 03:41, Adam Williamson wrote: Firefox will take advantage of a system h264 codec where one is available. In the Fedora system, one will not be available. Fedora as shipped from get.fedoraproject.org won't contain H.264 codec. Which doesn't mean that my computer won't be able to play H.264 movies as well as it does playing MP3s now. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On 03/20/2012 05:44 PM, Kevin Kofler wrote: Jon Masters wrote: On 03/20/2012 11:52 AM, Peter Jones wrote: 7) it can't be a serious maintenance burdon due to build related issues. We need a couple of groups to sign off that builds are fast enough, not just on a full distro rebuild (throughput) level, but also on a doesn't destroy my workflow due to waiting on it (latency) level. Sure. Absolutely is a concern for us, as you can see from my other comments above about the kernel, for example, but not just that. Sorry, but I don't think this is fixable any time soon. Come back when (if ever) you have hardware which has comparable speed to x86. I'm trying to figure out what this means. Do you mean that any primary architecture must be as fast as x86 is today, or that it must be as fast as its contemporary version of the x86? So, if the x86 got faster but ARM didn't, then ARM would be dropped? The way I see the CPU market developing over the next few years is that the x86 will continue to be the speed demon if you measure MIPS per core, but other competitors, especially ARM, will focus on cores per die. If we stick religiously to comparable speed to x86 (whatever that means) Fedora can never be a primary arch for anything other than x86. Even if we have builders with dozens or even hundreds of cores. This is wrong, in my view. If we have a great many parallel processors waiting for work, times waiting for build won't be so great. The future does not look like ever-increasing MIPS per core, but ever-increasing parallelism. If Fedora is the OS of the future, we'd better start to embrace that. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 10:58 PM, Matthew Garrett mj...@srcf.ucam.org wrote: I think you're looking at this in slightly the wrong way. Being a primary architecture isn't meant to be a benefit to the port - it's meant to be a benefit to Fedora. Adding arm to the PA list means you'll have to take on a huge number of additional responsibilities, deal with more people who are unhappy about the impact upon their packages and so on. You get very little out of it except that there's more people to tell you that something's broken. I don't think this is true: On a primary architecture, every package maintainer is be expected to handle their own packages; this should actually significantly decrease the load on the architecture maintainers. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 latest yum update hoses grub.cfg, grubby?
Dne 21.3.2012 03:56, Adam Williamson napsal: Properly, it ought to be versioned grub2-2.00-0.1.beta2.fc17. (Or possibly grub2-2.00-0.1.~beta2.fc17, I really dunno what that tilde is for). The tilde is a debianism to mark a pre-release. dpkg understands version 42~foo as lower than 42. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/share/applications weird error on koji
On Mon, Mar 19, 2012 at 4:44 PM, Alec Leamas leamas.a...@gmail.com wrote: On 03/19/2012 02:32 PM, Nikos Roussos wrote: On Mon, Mar 19, 2012 at 2:09 PM, Alec Leamas leamas.a...@gmail.comwrote: On 03/19/2012 12:50 PM, Nikos Roussos wrote: Hi, I'm trying to build a package. It's an update on SparkleSharehttps://admin.fedoraproject.org/updates/search/sparklesharepackage. I build it locally with mock and everything seems ok. Package is built successfully. But when I try to build it on koji I get an error and build fails on both f16 f17 targets: The databases in [/usr/share/applications] could not be updated. which I think has something to do with the desktop-file-validate on %install phase See the relevant koji task and build log for more: http://koji.fedoraproject.org/koji/taskinfo?taskID=3908835 Any help appreciated -- Nikos Roussos http://autoverse.net From the log, it looks like it fails in 'install-data-hook'. If so, the culprit might be some Makefile.am. Have upstream updated a Makefile.am to include 'desktop-file-install', failing when not making a real install int /usr? If this is right, you should be able to verify that the %install hasn't really begun when the error is triggered. If unsure, put some simple 'echo' statement in top of %install to verify that it hasn't been started. If this doesn't help, scanning the generated Makefiles for 'desktop-file-install' and/or '/usr/share/applications' might give a clue Actually there is an: install-data-hook: update-desktop-database $(datadir)/applications which seems to be the exact point that installation fails You must patch that, it will try to update /usr/share/applications when building the rpm which of course isn't acceptable. For Fedora, you could just remove the target and run automake; autoconf; ./configure, given that you run update-desktop-database as part of %install. However, this should really be resolved together with upstream. If they want to keep the functionality, one could possibly: - Move it from install-data-hook to a separate target such as 'install-desktop' and let users run this as part of installation into system dirs. - Only run update-desktop-database if $(datadir)/applications is writeable: Personally, I would prefer the first one. To mess with /usr/share/applications when DESTDIR is set is not really the way 'make install' is supposed to work. And updating $(DESTDIR)/$(datadir)/applications just doesn't make sense. But I'm just a newbie, maybe someone else has a better piece of advice here? I wrote a small patch to comment out this line and it worked just fine. I'll file a bug upstream. Thanks for the help. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-Perl-Critic] Drop tests subpackage and clean up
commit fc4da8936ee6341a05420a021b5488d960df0417
Author: Paul Howarth p...@city-fan.org
Date: Wed Mar 21 10:59:45 2012 +
Drop tests subpackage and clean up
- Drop -tests subpackage (general lack of interest in this), but include
them as documentation for the main package
- Drop redundant BR: perl(ExtUtils::MakeMaker)
- Drop redundant unversioned explicit requires
- Drop %defattr, redundant since rpm 4.4
- Make %files list more explicit
- Don't use macros for commands
- Run the author tests in %check
- BR: perl(Test::Pod) and perl(Test::Pod::Coverage)
- Use tabs
perl-Test-Perl-Critic.spec | 155 ++--
1 files changed, 78 insertions(+), 77 deletions(-)
---
diff --git a/perl-Test-Perl-Critic.spec b/perl-Test-Perl-Critic.spec
index 3a2a9d5..638ef13 100644
--- a/perl-Test-Perl-Critic.spec
+++ b/perl-Test-Perl-Critic.spec
@@ -1,35 +1,34 @@
-Name: perl-Test-Perl-Critic
-Summary:Use Perl::Critic in test programs
-Version:1.02
-Release:6%{?dist}
-License:GPL+ or Artistic
-Group: Development/Libraries
-Source0:
http://search.cpan.org/CPAN/authors/id/T/TH/THALJEF/Test-Perl-Critic-%{version}.tar.gz
-URL:http://search.cpan.org/dist/Test-Perl-Critic/
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-BuildArch: noarch
-
-BuildRequires: perl(Carp)
-BuildRequires: perl(English)
-BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(Module::Build) = 0.35
-BuildRequires: perl(Perl::Critic) = 1.105
-BuildRequires: perl(Perl::Critic::Utils) = 1.105
-BuildRequires: perl(Perl::Critic::Violation) = 1.105
-BuildRequires: perl(Test::Builder)
-BuildRequires: perl(Test::More)
-
-Requires: perl(Carp)
-Requires: perl(English)
-Requires: perl(Perl::Critic) = 1.105
-Requires: perl(Perl::Critic::Utils) = 1.105
-Requires: perl(Perl::Critic::Violation) = 1.105
-Requires: perl(Test::Builder)
-
-
+Name: perl-Test-Perl-Critic
+Summary: Use Perl::Critic in test programs
+Version: 1.02
+Release: 7%{?dist}
+Group: Development/Libraries
+License: GPL+ or Artistic
+URL: http://search.cpan.org/dist/Test-Perl-Critic/
+Source0:
http://search.cpan.org/CPAN/authors/id/T/TH/THALJEF/Test-Perl-Critic-%{version}.tar.gz
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
+BuildArch: noarch
+BuildRequires: perl(Carp)
+BuildRequires: perl(English)
+BuildRequires: perl(Module::Build) = 0.35
+BuildRequires: perl(Perl::Critic) = 1.105
+BuildRequires: perl(Perl::Critic::Utils) = 1.105
+BuildRequires: perl(Perl::Critic::Violation) = 1.105
+BuildRequires: perl(Test::Builder)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(Perl::Critic) = 1.105
+Requires: perl(Perl::Critic::Utils) = 1.105
+Requires: perl(Perl::Critic::Violation) = 1.105
+
+# Avoid doc-file dependencies from tests
%{?perl_default_filter}
-%{?perl_default_subpackage_tests}
+
+# Obsolete/provide old -tests subpackage (can be removed in F19 development
cycle)
+Obsoletes: %{name}-tests %{version}-%{release}
+Provides: %{name}-tests = %{version}-%{release}
%description
Test::Perl::Critic wraps the Perl::Critic engine in a convenient
@@ -38,40 +37,42 @@ framework. This makes it easy to integrate coding-standards
enforcement
into the build process. For ultimate convenience (at the expense of some
flexibility), see the criticism pragma.
-
%prep
%setup -q -n Test-Perl-Critic-%{version}
-
%build
-%{__perl} Build.PL installdirs=vendor
+perl Build.PL installdirs=vendor
./Build
-
%install
-rm -rf $RPM_BUILD_ROOT
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
-%{_fixperms} $RPM_BUILD_ROOT/*
-
+rm -rf %{buildroot}
+./Build install destdir=%{buildroot} create_packlist=0
+%{_fixperms} %{buildroot}
%check
-# Tests are failing with odd unpack errors.
-# TEST_AUTHOR=1 ./Build test
-./Build test
-
+TEST_AUTHOR=1 ./Build test
%clean
-rm -rf $RPM_BUILD_ROOT
-
+rm -rf %{buildroot}
%files
-%defattr(-,root,root,-)
-%doc Changes LICENSE README
+%doc Changes LICENSE README %{?perl_default_filter:t/ xt/}
%{perl_vendorlib}/Test/
-%{_mandir}/man3/*.3pm*
-
+%{_mandir}/man3/Test::Perl::Critic.3pm*
%changelog
+* Wed Mar 21 2012 Paul Howarth p...@city-fan.org - 1.02-7
+- Drop -tests subpackage (general lack of interest in this), but include
+ them as documentation for the main package
+- Drop redundant BR: perl(ExtUtils::MakeMaker)
+- Drop redundant unversioned explicit requires
+- Drop %%defattr, redundant since rpm 4.4
+- Make %%files list more explicit
+- Don't use macros for commands
+- Run
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 10:41:33AM +0100, Miloslav Trmač wrote: On Tue, Mar 20, 2012 at 10:58 PM, Matthew Garrett mj...@srcf.ucam.org wrote: I think you're looking at this in slightly the wrong way. Being a primary architecture isn't meant to be a benefit to the port - it's meant to be a benefit to Fedora. Adding arm to the PA list means you'll have to take on a huge number of additional responsibilities, deal with more people who are unhappy about the impact upon their packages and so on. You get very little out of it except that there's more people to tell you that something's broken. I don't think this is true: On a primary architecture, every package maintainer is be expected to handle their own packages; this should actually significantly decrease the load on the architecture maintainers. The expectation would be that the architecture maintainers have fixed everything before moving to being a primary architecture, so this should only be an issue if maintainers or upstream manage to come up with new breakage. But yes, it forces people to care about something they might previously have ignored, so I guess that's an advantage. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 11:07 AM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - Maybe it's worth to ask them (or look at for example Mer builds) what's the difference in build times. A few statistics from build.meego.com - using the OBS and building in qemu. These are really just approximate numbers, built in different times with probably a different load... I took Qt as an example as it's a package I know. -- build.meego.com --- http://build.meego.com/package/show?package=qtproject=Trunk armv8el build19 started build qt.spec at Sat Nov 5 02:09:33 UTC 2011. build19 finished build qt.spec at Sat Nov 5 03:01:43 UTC 2011. approx. 1 hour i586 build17 started build qt.spec at Fri Nov 4 23:33:24 UTC 2011. build17 finished build qt.spec at Sat Nov 5 00:05:03 UTC 2011. approx. half hour (1/2) armv8el vs i586 factor of 2 http://build.meego.com/package/show?package=qtproject=home%3Arrojfors%3Abranches%3AMeeGo%3A1.1%3ACore armv7el build42 started build qt.spec at Thu May 12 08:49:50 UTC 2011. build42 finished build qt.spec at Thu May 12 10:42:21 UTC 2011. approx. 2 hours i586 build11 started build qt.spec at Thu May 12 08:49:48 UTC 2011. build11 finished build qt.spec at Thu May 12 09:09:47 UTC 2011. approx. armv7el vs i586 factor of 4 -- Fedora -- i686 2012-02-20 14:31:51,510 - Mock Version: 1.1.18 2012-02-20 15:05:21,089 - State Changed: end approx. half hour armv7hl 2012-03-18 17:58:09,566 - Mock Version: 1.1.18 2012-03-19 04:53:07,593 - State Changed: end better not calculating... So probably using Qemu could speed it up quite a lot. Also OBS offers Those numbers look way better then Kevin's 50x slower without any citation ... thanks for getting this numbers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 latest yum update hoses grub.cfg, grubby?
The yum update didn't update grub, but it did update the kernel. This is the first time you have done a kernel update via yum with the new grub2. grubby updates the grub.cfg file. seems reproducible. My grub config is pretty empty, too. During update, I get something an error: grubby fatal error; unable to find a suitable template -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, 2012-03-21 at 05:04 -0400, Jaroslav Reznik wrote: - Original Message - just a side note - I was told by an OpenSUSE on ARM person that they use x86 boxes with the user-space qemu virtual machine. It works quite fast, but still needs some hacking eg. in test-suites Yep, OpenSUSE uses qemu - it's sometimes not as stable as it should be, I saw a few strange random crashes in qemu but usually it works. I talked with them once, they were surprised by our native builds policy. Maybe it's worth to ask them (or look at for example Mer builds) what's the difference in build times. Fully-emulated actually fits into the Native Builds guideline, but it hasn't been economical to use this approach because there's no hardware support for ARM emulation on x86 (the way that there is hardware acceleration for x86 virtualization on x86) and it therefore requires a very fast/expensive x86 box to emulate a slow/cheap ARM box. -Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Tue, Mar 20, 2012 at 11:31 PM, Kevin Kofler kevin.kof...@chello.at wrote: Peter Jones wrote: In yesterday's FESCo meeting I told you I'd make a list of specific issues I have with the current proposal for ARM as a primary archictecture. There are some places where I think the current proposal fails to deal with some necessary aspects of becoming a primary architecture, and some places where I don't think the approach is quite right. How about: support for the main hardware features on commonly-used hardware is Free Software, and included in the upstream software (kernel, X.Org X11, CUPS, SANE etc.) where appropriate? Right now, this is clearly NOT the case for OpenGL on ARM, so by promoting ARM, we'd promote proprietary (graphics) driver use. No, we've never said that ever! But then there are a lot of desktops that run just fine without OpenGL. 3D really wasn't in a great state even in x86 until Fedora 15 with a lot of drivers only doing it partially or not at all, even now there's only really 3 well supported sets of HW that are well supported with 3D in Fedora... ie Intel, AMD/ATI and nVidia and even those aren't perfect yet. I don't see how full OpenGL support should be an argument because there's still really on a subset of x86 hardware that currently supports it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, Mar 21, 2012 at 1:26 PM, Peter Robinson pbrobin...@gmail.com wrote: On Tue, Mar 20, 2012 at 11:31 PM, Kevin Kofler kevin.kof...@chello.at wrote: Peter Jones wrote: In yesterday's FESCo meeting I told you I'd make a list of specific issues I have with the current proposal for ARM as a primary archictecture. There are some places where I think the current proposal fails to deal with some necessary aspects of becoming a primary architecture, and some places where I don't think the approach is quite right. How about: support for the main hardware features on commonly-used hardware is Free Software, and included in the upstream software (kernel, X.Org X11, CUPS, SANE etc.) where appropriate? Right now, this is clearly NOT the case for OpenGL on ARM, so by promoting ARM, we'd promote proprietary (graphics) driver use. No, we've never said that ever! But then there are a lot of desktops that run just fine without OpenGL. Even though I disagree with Kevin that we should block on does not have 3D drivers .. OpenGL is imo even more important on ARM (non server systems) then on x86. A tablet or smartphone without hardware accelerated rendering is just useless (slow, short battery life). But this should get better over time as more general purpose distributions try to run on such devices. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, Mar 21, 2012 at 12:12:25PM +, Peter Robinson wrote: How was this handled in the case of PPC? My understanding is that due to legal reasons the Fedora Project never officially provided access to PPC machines. There were a number of machines that users could get access to that were provided by individuals but these were never officially provided by the Fedora project. It was very unsatisfactory. I had an account on David Woodhouse's PPC64 machine -- I think it was a PS3 -- but there was no root access so I couldn't install packages or test anything that needed root. There's a number of cheap hardware becoming available such as the Raspberry Pi as well as development boards that are available for either purchase or people can apply to be part of a developer program to get either discount or free hardware. How was this supported with PPC? The PPC hardware was a lot more expensive (either Apple devices or IBM) than the readily available ARM devices. PPC hardware was expensive. Even the Playstation 3 was an order of magnitude more expensive than the upcoming ARM hardware. Of course, as of *right now*, ARM hardware is also expensive (£250 for a minimal server). We are still waiting to see if Raspberry Pi really becomes mass-produced and available to all for cheap as chips. 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: Mass deduplication and reassignment of ABRT bugs
On Tue, Mar 20, 2012 at 08:58:36PM +0100, Michael Schwendt wrote: Here's another suspicious action: https://bugzilla.redhat.com/714364#3 Is anybody from the ABRT team watching these actions? The bot closed bug 714364 (gtk2) as duplicate of bug 701926 (rhythmbox) and did the same for the other mentioned tickets. That only makes sense if somebody then performs the rhythmbox-gtk2 reassignment. I've done it here, but what about other tickets where maybe nobody is pays attention? This can happen when the script can't find a common component for the bugs, so the component of the bug which will remain open is random. I think in most cases that wouldn't be a problem, the maintainer would at least see the bug was reported in other components, but here one of the closed bugs was already assigned to the right component. The reason gtk2 was not found is that the backtraces from the totem and transmission bugs contained paths to shared libraries which were not found in our database. One option is to ignore such backtraces, another is to try to get the components corresponding to the backtraces harder. We'll work on that. Thanks, -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass deduplication and reassignment of ABRT bugs
On Tue, Mar 20, 2012 at 02:56:40PM -0500, Michael Cronenworth wrote: Miroslav Lichvar wrote: If you find a suspicious action, please let us know at crash-catc...@lists.fedorahosted.org or file a ticket at https://fedorahosted.org/abrt. What about bugs that your script did not catch? Bug 752238[1] has about 100 dupes against it that I just wore out after a handful of setting DUPLICATE by hand. I set the dupes to bug 734442[2] before I realized 752238[1] had more CCs. [1] https://bugzilla.redhat.com/show_bug.cgi?id=752238 [2] https://bugzilla.redhat.com/show_bug.cgi?id=734442 We don't try to deduplicate python bugs yet. (only by the abrt_hash field in bugzilla) -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, Mar 21, 2012 at 8:12 AM, Peter Robinson pbrobin...@gmail.com wrote: 1) mechanisms need to be in place to get package maintainers access to fix arm-specific bugs in their packages So we have a tracker bug at the moment. Is that sufficient? If so, we obviously should make sure that it is included in the proposal docs that we have this in place and are using it. A tracker bug is certainly not sufficient. It would be for a SA, but not PA. Typically our users have a PA at their disposal, or failing that have ready access to a shared PA provided by the Fedora Project that they can log into and do their testing. How was this handled in the case of PPC? My understanding is that due to legal reasons the Fedora Project never officially provided access to PPC machines. There were a number of machines that users could get access to that were provided by individuals but these were never officially provided by the Fedora project. That is correct. Without ARM systems available for all the releases our maintainers have to support this is a non-starter. I will also note that having to resort to using a remote system because the arch isn't generally locally at a maintainer's disposal /is/ going to introduce a delay in getting bugs resolved and builds out the door. If the arch was ubiquitous in a way that lent itself to easy debugging and use that'd be a different matter, but I just don't see it as being there right now. There's a number of cheap hardware becoming available such as the Raspberry Pi as well as development boards that are available for either purchase or people can apply to be part of a developer program to get either discount or free hardware. How was this supported with PPC? The PPC hardware was a lot more expensive (either Apple devices or IBM) than the readily available ARM devices. We can also put a means escalation in place too for those that don't want to purchase or can't get ready access to HW for testing. I think you're really asking the wrong question, or maybe taking the wrong approach. There are a number of reasons PPC was _demoted_ to a secondary arch, and this is one of them. Asking how it was done while PPC was a PA is just spinning your wheels. It doesn't matter. 2) excludearch is not an option. This is fundamentally contrary to being a primary arch. In fact this is one of the defining characteristics of a secondary arch. Let's think about this some. ARM (32-bit) doesn't do Intel-style microcode, MCE, or many other things that x86 does. I don't think that means we should build packages that are x86-specific for ARM systems. We generally believe that we're starting from a point of good momentum, but there are some packages that won't ever be appropriate for ARM, and there are others where the FTBFS has been longstanding, or there are other (IMO valid) reasons why it might initially be Exclude. That doesn't mean that there would be many such cases. Nonetheless, I think it would be unreasonable to set the entry bar so high that there can be no things left to fix. That basically retains the x86 monopoly. Perhaps Peter can clarify or soften this requirement a bit. EXCLUDEARCH as a default action when a build fails on ARM is certainly not an option. What would help your situation is generating a few lists of packages. One list would be packages that you feel just don't make sense on ARM. Another list would be the FTBFS you mention. These lists can be debated and decided upon /before/ the migration to PA and the ExcludeArches can be in place before the switch is pulled. There's a couple of different categories here. 1) x86 only hardware. There's things like dmidecode, cpuid, various ACPI, numa, EFI and other HW specific things like intel GPU drivers where it just doesn't make sense to build on ARM, just like it didn't make sense to build the various PPC utils etc on x86. In some cases it might be a short term exclusion as it's expected that the support will come to ARM, EFI is the classic case here. Others like intel GPUs never will. Yes. All good. 2) packages that have x86 dependent code. spice comes into this category and I've discovered a few others. This would need work from someone, either the Fedora maintainer or upstream. Er... I think you forgot or the Fedora ARM team. Seriously, if you are counting on getting the Fedora package maintainer to fix something like that, you are going to be disappointed. You cannot force them to fix it and ExcludeArch is often the resolution until the arch team comes along and fixes it. Ultimately as the person that has done 98% of the builds and lead the building of rawhide the vast majority of the packages where we've added ExcludeArch are where they are x86 or PPC only for a reason, in fact in a lot of cases I've removed excludes (icedtea-web and a number of other packages) to ensure we run on ARM. Where it's FTBFS on ARM there's been
Re: ARM as a primary architecture
On Wed, Mar 21, 2012 at 8:33 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Mar 21, 2012 at 12:12:25PM +, Peter Robinson wrote: How was this handled in the case of PPC? My understanding is that due to legal reasons the Fedora Project never officially provided access to PPC machines. There were a number of machines that users could get access to that were provided by individuals but these were never officially provided by the Fedora project. It was very unsatisfactory. I had an account on David Woodhouse's PPC64 machine -- I think it was a PS3 -- but there was no root access so I couldn't install packages or test anything that needed root. David's machines were usually Apple G5s. If he gave you access to a PS3, he must have disliked you at that particular moment. Those were some of the worst machines I have ever worked with because of their hardware limitations. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass deduplication and reassignment of ABRT bugs
Miroslav Lichvar wrote: We don't try to deduplicate python bugs yet. (only by the abrt_hash field in bugzilla) Every dupe bug has the same abrt_hash in the Whiteboard: abrt_hash:01acb9e5787833cdbc03832f71e787ef531f1cd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 7:39 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Wed, Mar 21, 2012 at 10:41:33AM +0100, Miloslav Trmač wrote: On Tue, Mar 20, 2012 at 10:58 PM, Matthew Garrett mj...@srcf.ucam.org wrote: I think you're looking at this in slightly the wrong way. Being a primary architecture isn't meant to be a benefit to the port - it's meant to be a benefit to Fedora. Adding arm to the PA list means you'll have to take on a huge number of additional responsibilities, deal with more people who are unhappy about the impact upon their packages and so on. You get very little out of it except that there's more people to tell you that something's broken. I don't think this is true: On a primary architecture, every package maintainer is be expected to handle their own packages; this should actually significantly decrease the load on the architecture maintainers. The expectation would be that the architecture maintainers have fixed everything before moving to being a primary architecture, so this should only be an issue if maintainers or upstream manage to come up with new breakage. But yes, it forces people to care about something they might previously have ignored, so I guess that's an advantage. Except when people are forced to look at it, their solution was often ExcludeArch for PPC. As I said in the other thread, you cannot force people to care about an architecture they don't know or want to learn. That's not to say there weren't a large number of people that _did_ try and fix things. It's just not a clear cut this arch is primary so package maintainers will fix arch issues. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tue, Mar 20, 2012 at 11:46 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-03-20 at 12:08 -0400, Josh Boyer wrote: 2) Updates. Submitting updates requires the entire build to be complete which means you have to wait for the slowest thing to finish. Having to wait for 12 hours effectively means you can't even test your update until the next day, and then after you test it you can submit it. Again, this is mostly compounded for large packages, but it does impact workflow. From a QA perspective, there's a fairly important instance of this case. We sometimes wind up working on very compressed timescales in validation sprints. We don't get very long to do validation. So it's not unusual for me to be bugging, say, the kernel team to give us a new kernel build that fixes a blocker bug, so we can do a new release candidate, so we can test the release candidate in twelve hours, so we can make the go/no-go meeting deadline the next morning. If builds get significantly slower, that could have a concrete impact on the release validation process: it's plausible that we'd either need to extend the validation period somewhat - earlier freezes - or we would have to eat a somewhat higher likelihood of release slippages. Thanks Adam, this is the first real use case where speed of builds is important for something other than keeping the developer happy. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 11:39 AM, Matthew Garrett mj...@srcf.ucam.org wrote: On Wed, Mar 21, 2012 at 10:41:33AM +0100, Miloslav Trmač wrote: On Tue, Mar 20, 2012 at 10:58 PM, Matthew Garrett mj...@srcf.ucam.org wrote: I think you're looking at this in slightly the wrong way. Being a primary architecture isn't meant to be a benefit to the port - it's meant to be a benefit to Fedora. Adding arm to the PA list means you'll have to take on a huge number of additional responsibilities, deal with more people who are unhappy about the impact upon their packages and so on. You get very little out of it except that there's more people to tell you that something's broken. I don't think this is true: On a primary architecture, every package maintainer is be expected to handle their own packages; this should actually significantly decrease the load on the architecture maintainers. The expectation would be that the architecture maintainers have fixed everything before moving to being a primary architecture, so this should only be an issue if maintainers or upstream manage to come up with new breakage. But yes, it forces people to care about something they might previously have ignored, so I guess that's an advantage. And we've already being doing that with the vast majority of issues already fixed and committed to mainline. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 10:07 AM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - Maybe it's worth to ask them (or look at for example Mer builds) what's the difference in build times. A few statistics from build.meego.com - using the OBS and building in qemu. These are really just approximate numbers, built in different times with probably a different load... I took Qt as an example as it's a package I know. -- build.meego.com --- http://build.meego.com/package/show?package=qtproject=Trunk armv8el build19 started build qt.spec at Sat Nov 5 02:09:33 UTC 2011. build19 finished build qt.spec at Sat Nov 5 03:01:43 UTC 2011. approx. 1 hour i586 build17 started build qt.spec at Fri Nov 4 23:33:24 UTC 2011. build17 finished build qt.spec at Sat Nov 5 00:05:03 UTC 2011. approx. half hour (1/2) armv8el vs i586 factor of 2 http://build.meego.com/package/show?package=qtproject=home%3Arrojfors%3Abranches%3AMeeGo%3A1.1%3ACore armv7el build42 started build qt.spec at Thu May 12 08:49:50 UTC 2011. build42 finished build qt.spec at Thu May 12 10:42:21 UTC 2011. approx. 2 hours i586 build11 started build qt.spec at Thu May 12 08:49:48 UTC 2011. build11 finished build qt.spec at Thu May 12 09:09:47 UTC 2011. approx. armv7el vs i586 factor of 4 -- Fedora -- i686 2012-02-20 14:31:51,510 - Mock Version: 1.1.18 2012-02-20 15:05:21,089 - State Changed: end approx. half hour armv7hl 2012-03-18 17:58:09,566 - Mock Version: 1.1.18 2012-03-19 04:53:07,593 - State Changed: end better not calculating... So probably using Qemu could speed it up quite a lot. Also OBS offers quite a lot of flexibility to decouple arch builds, disable selected archs etc. But I'm not sure about the processes for chain builds, updates, how they make the builds consistent (if one arch fails)... All sorts of things can speed it up, most of the Fedora builders are currently loopback ext4 over NFS over 100Mb ethernet over USB. Not optimal. Add to that 1Gb of RAM and swap the problem gets worse. The devices we're looking at have proper SATA ports (not over USB) and quad core 4GB RAM and the time to build is an order of magnitude faster, and those boards aren't overly stable as they're not production level HW so once we get our hands on production level versions of that HW we can start to properly test the difference in large packages such as gcc, qt, libreoffice and the kernel and will be able to much better ascertain the impact. I believe that should be soon although I'm not in direct contact. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 7:13 AM, David Tardon dtar...@redhat.com wrote: On Tue, Mar 20, 2012 at 12:52:58PM -0700, Brendan Conoboy wrote: On 03/20/2012 12:44 PM, Chris Murphy wrote: Now the ultra ridiculous: How about secondary architecture requirements demoted as-is to tertiary. And create substantially more aggressive requirements for secondary architecture (in which ARM would be placed), yet are not identical requirements to primary architecture requirements? Yes, the all-or-nothing mindset between secondary and primary is almost certainly the root of the problem. We want more representation in Fedora than being a secondary connotes, Maybe you should begin by convincing package maintainers that ARM is a good platform (if it is; I do not know) and that they want to use it, instead of (figuratively speaking) shoving it down their throats by means of FESCo decision to promote ARM to primary arch. If you attract enough people, the transition may just happen naturally... There is no doubt it is a good platform, it's not about shoving it down people's throats, it's about making Fedora available on millions of devices that are cheap and low power. The transition is happening already and it happening due to cost and power, whether that be in the data centre running on servers or in the developing world. You just have to look at the millions of ARM based devices being sold in China, India and other parts of Asia. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass deduplication and reassignment of ABRT bugs
On Wed, Mar 21, 2012 at 08:08:13AM -0500, Michael Cronenworth wrote: Miroslav Lichvar wrote: We don't try to deduplicate python bugs yet. (only by the abrt_hash field in bugzilla) Every dupe bug has the same abrt_hash in the Whiteboard: abrt_hash:01acb9e5787833cdbc03832f71e787ef531f1cd Hm, that would be a bug, possibly in the bugzilla reporter plugin. Thanks, -- Miroslav Lichvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 01:26:58PM +, Peter Robinson wrote: On Wed, Mar 21, 2012 at 11:39 AM, Matthew Garrett mj...@srcf.ucam.org wrote: The expectation would be that the architecture maintainers have fixed everything before moving to being a primary architecture, so this should only be an issue if maintainers or upstream manage to come up with new breakage. But yes, it forces people to care about something they might previously have ignored, so I guess that's an advantage. And we've already being doing that with the vast majority of issues already fixed and committed to mainline. Agreed. I just mean that it's not a terribly significant benefit to becoming a primary architecture. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass deduplication and reassignment of ABRT bugs
On 03/21/2012 02:32 PM, Miroslav Lichvar wrote: On Wed, Mar 21, 2012 at 08:08:13AM -0500, Michael Cronenworth wrote: Miroslav Lichvar wrote: We don't try to deduplicate python bugs yet. (only by the abrt_hash field in bugzilla) Every dupe bug has the same abrt_hash in the Whiteboard: abrt_hash:01acb9e5787833cdbc03832f71e787ef531f1cd Hm, that would be a bug, possibly in the bugzilla reporter plugin. Thanks, Hi, noted here, we'll get to it asap: https://fedorahosted.org/abrt/ticket/492 Mike, next time please don't hesitate and report this to bz against abrt, we really don't want to upset developers by filling duplicates (even tho it seems like the opposite ;)) Jirka -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass deduplication and reassignment of ABRT bugs
Michael Cronenworth m...@cchtml.com writes: Miroslav Lichvar wrote: We don't try to deduplicate python bugs yet. (only by the abrt_hash field in bugzilla) Every dupe bug has the same abrt_hash in the Whiteboard: abrt_hash:01acb9e5787833cdbc03832f71e787ef531f1cd which is very, very odd. what we first do, is search sha1 hash in bugzilla and if we found that hash (no matter how many times) we clame reporting bug as duplicate. I will look at it. -- Nikola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SPDY in F18 (was Re: F17 httpd 2.4?)
W dniu 13 marca 2012 21:59 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: 2012/2/21 Jon Ciesla limburg...@gmail.com: 2012/2/21 Michał Piotrowski mkkp...@gmail.com: Hi, Is there a chance to get httpd 2.4 in Fedora 17 http://www.apache.org/dist/httpd/Announcement2.4.html ? This is the first major release from a few years and has some nice features. Not likely this late in the cycle, though the timing is great for f18. How about SPDY support? http://code.google.com/p/mod-spdy/ Firefox supports SPDY http://hacks.mozilla.org/2012/02/spdy-brings-responsive-and-scalable-transport-to-firefox-11/ If there are any work in progress packages for mod_spdy I would like to help test them :) From now Jetty server also supports SPDY http://webtide.intalio.com/2012/03/spdy-support-in-jetty/ -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/21/2012 09:21 AM, Josh Boyer wrote: Except when people are forced to look at it, their solution was often ExcludeArch for PPC. As I said in the other thread, you cannot force people to care about an architecture they don't know or want to learn. That suggests we need a FTBFS-like nightly test that lets us know about new, unexpected ExcludeArches in the distro. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, Mar 21, 2012 at 1:04 PM, Josh Boyer jwbo...@gmail.com wrote: On Wed, Mar 21, 2012 at 8:12 AM, Peter Robinson pbrobin...@gmail.com wrote: 1) mechanisms need to be in place to get package maintainers access to fix arm-specific bugs in their packages So we have a tracker bug at the moment. Is that sufficient? If so, we obviously should make sure that it is included in the proposal docs that we have this in place and are using it. A tracker bug is certainly not sufficient. It would be for a SA, but not PA. Typically our users have a PA at their disposal, or failing that have ready access to a shared PA provided by the Fedora Project that they can log into and do their testing. How was this handled in the case of PPC? My understanding is that due to legal reasons the Fedora Project never officially provided access to PPC machines. There were a number of machines that users could get access to that were provided by individuals but these were never officially provided by the Fedora project. That is correct. Without ARM systems available for all the releases our maintainers have to support this is a non-starter. I will also note that having to resort to using a remote system because the arch isn't generally locally at a maintainer's disposal /is/ going to introduce a delay in getting bugs resolved and builds out the door. If the arch was ubiquitous in a way that lent itself to easy debugging and use that'd be a different matter, but I just don't see it as being there right now. There's a number of cheap hardware becoming available such as the Raspberry Pi as well as development boards that are available for either purchase or people can apply to be part of a developer program to get either discount or free hardware. How was this supported with PPC? The PPC hardware was a lot more expensive (either Apple devices or IBM) than the readily available ARM devices. We can also put a means escalation in place too for those that don't want to purchase or can't get ready access to HW for testing. I think you're really asking the wrong question, or maybe taking the wrong approach. There are a number of reasons PPC was _demoted_ to a secondary arch, and this is one of them. Asking how it was done while PPC was a PA is just spinning your wheels. It doesn't matter. No, I was using it as a point and it's certainly not the approach I'm taking. 2) excludearch is not an option. This is fundamentally contrary to being a primary arch. In fact this is one of the defining characteristics of a secondary arch. Let's think about this some. ARM (32-bit) doesn't do Intel-style microcode, MCE, or many other things that x86 does. I don't think that means we should build packages that are x86-specific for ARM systems. We generally believe that we're starting from a point of good momentum, but there are some packages that won't ever be appropriate for ARM, and there are others where the FTBFS has been longstanding, or there are other (IMO valid) reasons why it might initially be Exclude. That doesn't mean that there would be many such cases. Nonetheless, I think it would be unreasonable to set the entry bar so high that there can be no things left to fix. That basically retains the x86 monopoly. Perhaps Peter can clarify or soften this requirement a bit. EXCLUDEARCH as a default action when a build fails on ARM is certainly not an option. What would help your situation is generating a few lists of packages. One list would be packages that you feel just don't make sense on ARM. Another list would be the FTBFS you mention. These lists can be debated and decided upon /before/ the migration to PA and the ExcludeArches can be in place before the switch is pulled. There's a couple of different categories here. 1) x86 only hardware. There's things like dmidecode, cpuid, various ACPI, numa, EFI and other HW specific things like intel GPU drivers where it just doesn't make sense to build on ARM, just like it didn't make sense to build the various PPC utils etc on x86. In some cases it might be a short term exclusion as it's expected that the support will come to ARM, EFI is the classic case here. Others like intel GPUs never will. Yes. All good. 2) packages that have x86 dependent code. spice comes into this category and I've discovered a few others. This would need work from someone, either the Fedora maintainer or upstream. Er... I think you forgot or the Fedora ARM team. Seriously, if you are counting on getting the Fedora package maintainer to fix something like that, you are going to be disappointed. You cannot force them to fix it and ExcludeArch is often the resolution until the arch team comes along and fixes it. Nope, not forgotten, the Fedora ARM team component was a given, but ultimately there has to be some form of involvement from both levels of maintainers because otherwise everytime a patch doesn't rebase
[perl-Test-Perl-Critic] Remove unused patch
commit 0a5b90bb2f3179fb463d66e196a77fce930ed142 Author: Paul Howarth p...@city-fan.org Date: Wed Mar 21 13:59:13 2012 + Remove unused patch .gitignore |2 +- perl-Test-Perl-Critic-1.01-fixtest.patch | 21 - 2 files changed, 1 insertions(+), 22 deletions(-) --- diff --git a/.gitignore b/.gitignore index 250f8c7..93c70c9 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1 @@ -Test-Perl-Critic-1.02.tar.gz +/Test-Perl-Critic-[0-9.]*.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: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 1:52 PM, Peter Jones pjo...@redhat.com wrote: On 03/21/2012 09:21 AM, Josh Boyer wrote: Except when people are forced to look at it, their solution was often ExcludeArch for PPC. As I said in the other thread, you cannot force people to care about an architecture they don't know or want to learn. That suggests we need a FTBFS-like nightly test that lets us know about new, unexpected ExcludeArches in the distro. TBH we need someone to take over the FTBFS things that Matt use to do, there's still 400+ packages that are FTBFS on x86 primary arch post the F-17 gcc 4.7 mass rebuild and even some going all the way back to the F-12 mass rebuilt (yes 3 mass rebuilds ago!). that number was actually much closer to 600 but the ARM team have fixed well over 100 of those on mainline because they were blocking what we were doing on ARM. Then once that is in place a means of tracking ExcludeArch/ExclusiveArch would be an excellent and very useful tool for all arches, primary or otherwise IMO. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SPDY in F18 (was Re: F17 httpd 2.4?)
2012/3/13 Michał Piotrowski mkkp...@gmail.com: 2012/2/21 Jon Ciesla limburg...@gmail.com: 2012/2/21 Michał Piotrowski mkkp...@gmail.com: Hi, Is there a chance to get httpd 2.4 in Fedora 17 http://www.apache.org/dist/httpd/Announcement2.4.html ? This is the first major release from a few years and has some nice features. Not likely this late in the cycle, though the timing is great for f18. How about SPDY support? http://code.google.com/p/mod-spdy/ Firefox supports SPDY http://hacks.mozilla.org/2012/02/spdy-brings-responsive-and-scalable-transport-to-firefox-11/ If there are any work in progress packages for mod_spdy I would like to help test them :) There's nothing stopping you from packaging up mod_spdy or any other modules that add support for the protocol. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 9:52 AM, Peter Jones pjo...@redhat.com wrote: On 03/21/2012 09:21 AM, Josh Boyer wrote: Except when people are forced to look at it, their solution was often ExcludeArch for PPC. As I said in the other thread, you cannot force people to care about an architecture they don't know or want to learn. That suggests we need a FTBFS-like nightly test that lets us know about new, unexpected ExcludeArches in the distro. Possibly. There are ExcludeArch trackers that people are supposed to make their bugs block and that was normally sufficient to give the arch team a heads up. However, I'm sure there were packages that didn't have bugs filed like that. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SPDY in F18 (was Re: F17 httpd 2.4?)
2012/3/21 Peter Robinson pbrobin...@gmail.com: 2012/3/13 Michał Piotrowski mkkp...@gmail.com: 2012/2/21 Jon Ciesla limburg...@gmail.com: 2012/2/21 Michał Piotrowski mkkp...@gmail.com: Hi, Is there a chance to get httpd 2.4 in Fedora 17 http://www.apache.org/dist/httpd/Announcement2.4.html ? This is the first major release from a few years and has some nice features. Not likely this late in the cycle, though the timing is great for f18. How about SPDY support? http://code.google.com/p/mod-spdy/ Firefox supports SPDY http://hacks.mozilla.org/2012/02/spdy-brings-responsive-and-scalable-transport-to-firefox-11/ If there are any work in progress packages for mod_spdy I would like to help test them :) There's nothing stopping you from packaging up mod_spdy or any other modules that add support for the protocol. I will try tomorrow - I've got mod_fcgid package sources for reference. Who can mod_spdy if I make the spec file for this? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, 2012-03-21 at 12:26 +, Peter Robinson wrote: No, we've never said that ever! But then there are a lot of desktops that run just fine without OpenGL. 3D really wasn't in a great state even in x86 until Fedora 15 with a lot of drivers only doing it partially or not at all, even now there's only really 3 well supported sets of HW that are well supported with 3D in Fedora... ie Intel, AMD/ATI and nVidia and even those aren't perfect yet. I don't see how full OpenGL support should be an argument because there's still really on a subset of x86 hardware that currently supports it. Not to be overly picky, but only three is a bit misleading. When you look at how the driver support actually breaks down in terms of generational similarity, you get something more like: - Intel gen2 (8xx) - Intel gen3 (915, 945, G33, Atom) - Intel gen4 (Core and Core 2) - Intel gen5+ (Core i3 and up) - Radeon R100-R200 - Radeon R300-R500 - Radeon R600-R700 - Radeon R800+ - NVIDIA pre-NV30 - NVIDIA NV30-NV40 - NVIDIA NV50 - NVIDIA NVC0+ Even if you're going by the more strict criteria of good enough to run gnome-shell you only cut out four of those (should only be three, tbh). And if we're going by _that_ metric, the list of other x86 hardware in the world where we could have drivers but don't yet is, as far as I know: - VIA Chrome9 - Matrox P- and M-series Which, in terms of market share, are sort of the two-dollar-bills of the world. So it's a little like saying we only support x86 chips from Intel, AMD, and VIA. Okay, yeah, maybe that's fair, but those are actually all there is to care about. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, 2012-03-21 at 13:32 +0100, drago01 wrote: Even though I disagree with Kevin that we should block on does not have 3D drivers .. OpenGL is imo even more important on ARM (non server systems) then on x86. A tablet or smartphone without hardware accelerated rendering is just useless (slow, short battery life). But this should get better over time as more general purpose distributions try to run on such devices. ITYM as more people finally get around to reverse-engineering the hardware. Honestly distributions have very little impact here. They just increase demand. The only thing that gets drivers written is writing the damn driver. If you think this is an important thing to have, Mesa would love to have your contribution. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, Mar 21, 2012 at 2:23 PM, Adam Jackson a...@redhat.com wrote: On Wed, 2012-03-21 at 12:26 +, Peter Robinson wrote: No, we've never said that ever! But then there are a lot of desktops that run just fine without OpenGL. 3D really wasn't in a great state even in x86 until Fedora 15 with a lot of drivers only doing it partially or not at all, even now there's only really 3 well supported sets of HW that are well supported with 3D in Fedora... ie Intel, AMD/ATI and nVidia and even those aren't perfect yet. I don't see how full OpenGL support should be an argument because there's still really on a subset of x86 hardware that currently supports it. Not to be overly picky, but only three is a bit misleading. When you look at how the driver support actually breaks down in terms of generational similarity, you get something more like: - Intel gen2 (8xx) - Intel gen3 (915, 945, G33, Atom) - Intel gen4 (Core and Core 2) - Intel gen5+ (Core i3 and up) - Radeon R100-R200 - Radeon R300-R500 - Radeon R600-R700 - Radeon R800+ - NVIDIA pre-NV30 - NVIDIA NV30-NV40 - NVIDIA NV50 - NVIDIA NVC0+ Even if you're going by the more strict criteria of good enough to run gnome-shell you only cut out four of those (should only be three, tbh). And if we're going by _that_ metric, the list of other x86 hardware in the world where we could have drivers but don't yet is, as far as I know: - VIA Chrome9 - Matrox P- and M-series Which, in terms of market share, are sort of the two-dollar-bills of the world. So it's a little like saying we only support x86 chips from Intel, AMD, and VIA. Okay, yeah, maybe that's fair, but those are actually all there is to care about. What about all the other xorg-x11-drv* video cards, admittedly they're generally considered legacy but there are a lot that don't do 3D at all there. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, Mar 21, 2012 at 02:28:10PM +, Peter Robinson wrote: What about all the other xorg-x11-drv* video cards, admittedly they're generally considered legacy but there are a lot that don't do 3D at all there. Of the hardware still produced, they're either things Adam listed as unsupported, don't have 3D engines or they're powervr. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, Mar 21, 2012 at 3:24 PM, Adam Jackson a...@redhat.com wrote: On Wed, 2012-03-21 at 13:32 +0100, drago01 wrote: Even though I disagree with Kevin that we should block on does not have 3D drivers .. OpenGL is imo even more important on ARM (non server systems) then on x86. A tablet or smartphone without hardware accelerated rendering is just useless (slow, short battery life). But this should get better over time as more general purpose distributions try to run on such devices. ITYM as more people finally get around to reverse-engineering the hardware. Honestly distributions have very little impact here. They just increase demand. Which is what I meant by that. There is basically zero demand right now. The only devices that ship currently pretty much all run android which has drivers (and does not care about open vs. closed). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, Mar 21, 2012 at 2:24 PM, Adam Jackson a...@redhat.com wrote: On Wed, 2012-03-21 at 13:32 +0100, drago01 wrote: Even though I disagree with Kevin that we should block on does not have 3D drivers .. OpenGL is imo even more important on ARM (non server systems) then on x86. A tablet or smartphone without hardware accelerated rendering is just useless (slow, short battery life). But this should get better over time as more general purpose distributions try to run on such devices. ITYM as more people finally get around to reverse-engineering the hardware. Honestly distributions have very little impact here. They just increase demand. The only thing that gets drivers written is writing the damn driver. If you think this is an important thing to have, Mesa would love to have your contribution. I'm hoping soon we can add the MALI chipset with the lima driver effort [1] into this list, it's been reverse engineered and it's a good target as it's the ARM developed GPU that is a check box option for those that don't want to make their own so is relatively wide spread. Marvell might even come to the party through it's involvement with OLPC. A lot of the others I'm not sure of, I don't hold up much hope for any derived from the SGX stuff as even with intel and the gma* ones there's not been a lot of movement with an open source 3D driver, but ultimately the company that owns the IP has no incentive as they're selling their cores for iOS devices hand over fist. Since the beginning of the year there has been at least some positive movement in this regard, even if in some cases it's only an open KMS kernel driver to do some form of 2D. Peter [1] http://limadriver.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, Mar 21, 2012 at 2:31 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Wed, Mar 21, 2012 at 02:28:10PM +, Peter Robinson wrote: What about all the other xorg-x11-drv* video cards, admittedly they're generally considered legacy but there are a lot that don't do 3D at all there. Of the hardware still produced, they're either things Adam listed as unsupported, don't have 3D engines or they're powervr. That's my point, I don't believe that working 3D should be a blocker to primary arch because like mainline it will likely come with both time and demand. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
Peter Robinson (pbrobin...@gmail.com) said: That's my point, I don't believe that working 3D should be a blocker to primary arch because like mainline it will likely come with both time and demand. Is llvmpipe not 'working'? (Admittedly, on low-power CPUs like ARM, it might be more of a burden.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, Mar 21, 2012 at 3:38 PM, Bill Nottingham nott...@redhat.com wrote: Peter Robinson (pbrobin...@gmail.com) said: That's my point, I don't believe that working 3D should be a blocker to primary arch because like mainline it will likely come with both time and demand. Is llvmpipe not 'working'? (Admittedly, on low-power CPUs like ARM, it might be more of a burden.) It is rather pointless on devices that really on low power footprint. They need the GPU to work to be useful. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, 2012-03-21 at 14:31 +, Matthew Garrett wrote: On Wed, Mar 21, 2012 at 02:28:10PM +, Peter Robinson wrote: What about all the other xorg-x11-drv* video cards, admittedly they're generally considered legacy but there are a lot that don't do 3D at all there. Of the hardware still produced, they're either things Adam listed as unsupported, don't have 3D engines or they're powervr. Oh, yeah, fair, I totally forgot to bitch about Poulsbo there. Insert standard bitching about Poulsbo here. Of hardware not currently in production - where, again, we're talking about whether a 3D driver could usefully be written to enable gnome-shell on the hardware - it's still a remarkably short list. Via did some DX8 parts, XGI before they went out of business, possibly a few SiS parts before they did the same. I should emphasize that I don't think hardware 3D needs to be a blocker for a primary arch either. My beef was just with the phrasing that implied that only 3 GPUs was somehow inadequate. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, 2012-03-21 at 10:38 -0400, Bill Nottingham wrote: Peter Robinson (pbrobin...@gmail.com) said: That's my point, I don't believe that working 3D should be a blocker to primary arch because like mainline it will likely come with both time and demand. Is llvmpipe not 'working'? (Admittedly, on low-power CPUs like ARM, it might be more of a burden.) llvmpipe should work on arm - I've not tried - but I suspect it needs a modest amount of surgery to perform adequately. Much of its performance on x86 comes from swizzling the pixel layout around internally so it nicely matches up with SSE2's register layout, which probably isn't quite what arm gives you to work with. Oh, yeah, and software floating point would be brutal. Nobody is surprised. The ARM GPUs are pretty simple though. The nice thing about not pretending to implement full GL is you don't have to implement all the garbage parts of GL. And you're really going to be much happier with an RE'd driver than with llvmpipe. Like I say, mesa-dev@ is - that way. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: Re: Release Notes Update
From the docs@ list, FYI, in case someone has some time in which they can contribute to release notes for desktop, system daemons, web servers, or for that matter any other existing beats: - Forwarded message from John J. McDonough wb8...@arrl.net - On Tue, 2012-03-20 at 23:27 -0400, Christopher R. Antila wrote: Hi: I have some unexpected extra time today, so I'll finish the Desktop beat. That would be much appreciated. I need to get cracking on the RPM or it won't make it into beta. I see we have KDE there but no GNOME. Without some help there will be no mention of GNOME 3.4 in the RNs (other than a word in Overview). Also, there are some minimal notes in Musicians. Do they need to be embellished or will we leave that beat blank? On https://fedoraproject.org/wiki/Documentation_Beats I have marked as empty those beats that I think will be empty in the release notes. If anyone feels like that is a problem you only have a few hours to fix it. I'm going to get working on the Multimedia beat. If anyone could grab the Daemons beat it would be much appreciated. Or the other way around, if someone wants to take Multimedia while I work on Daemons that would work, too. Also, Yuri made some notes in Web Servers. If he or someone else could embellish those it would be good. I anticipate building the RPM around 1800Z. I will then be looking for folks to quickly give it some karma. --McD - End forwarded message - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
Peter Jones (pjo...@redhat.com) said: In yesterday's FESCo meeting I told you I'd make a list of specific issues I have with the current proposal for ARM as a primary archictecture. There are some places where I think the current proposal fails to deal with some necessary aspects of becoming a primary architecture, and some places where I don't think the approach is quite right. So without further ado: 1) mechanisms need to be in place to get package maintainers access to fix arm-specific bugs in their packages 2) excludearch is not an option. This is fundamentally contrary to being a primary arch. In fact this is one of the defining characteristics of a secondary arch. 3) arm must be integrated to the formal release criteria 4) when milestones occur, arm needs to be just as testible as other primary architectures 5) installation methods must be in place. I'm not saying it has to be using the same model as x86, but when we get to beta, if it can't be installed, it can't meet similar release criteria to existing or prior primary arches. Where possible, we should be using anaconda for installation, though I'd be open to looking at using it to build installed images for machines with severe resource constraints. 6) supported platforms must be fully integrated into building and installation. If you need a special build procedure to make this happen for kernel, we need to have rel-eng signing off saying they've approved of whatever method that is, and QE signing off that they think it'll result in a something they can claim is tested enough to release as a primary arch. 7) it can't be a serious maintenance burdon due to build related issues. We need a couple of groups to sign off that builds are fast enough, not just on a full distro rebuild (throughput) level, but also on a doesn't destroy my workflow due to waiting on it (latency) level. So, the thing I'm seeing over and over in the discussion (well, aside from Kevin), is these list of requirements that must be in place. However, none of these requirements require being a primary arch to do. In essence, if ARM is a primary arch in practice, then it should be able to become one in designation. Stating at an organization level ARM is a primary arch pending on meeting criteria A, B, and C seems backwards. We should continue on threads like this figuring out what makes a primary arch viable, and then table the discussion of whether ARM should be primary until it meets these viability standards. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 01:27:04PM +, Peter Robinson wrote: All sorts of things can speed it up, most of the Fedora builders are currently loopback ext4 over NFS over 100Mb ethernet over USB. Not optimal. Just switching them to ext2 would save a ton of IO. The buildroots get regenerated every time anyway, so journalling isn't really getting you anything. If a builder crashes, you probably want to throw the old buildroot away and start over anyway. out of curiousity, Is the setup of the builders documented somewhere ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 latest yum update hoses grub.cfg, grubby?
On Tue, 2012-03-20 at 20:30 -0700, John Reiser wrote: On 03/20/2012 06:24 PM, Chris Murphy wrote: After a yum update a few minutes ago, GRUB's kinda messed up. Anyone else? Yes, it happened to me, too, after booting an up-to-the-minute anaconda install DVD for _update_ (not fresh install). I built the DVD to test the changes that are claimed to fix the problems of last weekend. This is on bare metal real hardware (including physical DVD) with no virtualization of any kind. I recovered by re-running a complete fresh install, because I had only a short time invested in the originally-installed system. Eventually it boots, but uname -r indicates 3.3.0-0.rc7.git0.3 not 3.3.0-1. Yes. So is this a problem with grubby? Or is this ... wait. Why does the GRUB2 menu says it's GRUB version 2.00~beta2, and yet yum says what's installed is 1.99-19 from repo koji-override-1? grubby is 8.10-1. Yes, I see the same versions. Saw same errors (yesterday I think) when I had F17 running and did an update. Has this been fixed anytime soon or whatever? -- Mike Chambers Madisonville, KY Best little town on Earth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 latest yum update hoses grub.cfg, grubby?
On 03/21/2012 02:27 AM, Adam Williamson wrote: On Wed, 2012-03-21 at 00:12 -0600, Chris Murphy wrote: On Mar 21, 2012, at 12:08 AM, Chris Murphy wrote: It seems reasonable to consider this a grubby bug, yes? Considering grub2-mkconfig -o /boot/grub2/grub.cfg produces the exact correct result, guess I'm not understanding the purpose of grubby. Are we in transition? grubby is less 'drastic' that grub2-mkconfig. it takes the existing config and appends a new entry to it. grub2-mkconfig blows away the config and starts over again each time. i don't recall whether we ever made a specific decision to keep using grubby over grub2-mkconfig or whether it's just inertia, though. pjones might. We definitely want to keep using grubby instead of running grub2-mkconfig and clobbering whatever's in your config file every time. Has somebody filed a bz about this issue? I haven't seen one referenced in the thread. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 2:58 PM, Dave Jones da...@redhat.com wrote: On Wed, Mar 21, 2012 at 01:27:04PM +, Peter Robinson wrote: All sorts of things can speed it up, most of the Fedora builders are currently loopback ext4 over NFS over 100Mb ethernet over USB. Not optimal. Just switching them to ext2 would save a ton of IO. The buildroots get regenerated every time anyway, so journalling isn't really getting you anything. If a builder crashes, you probably want to throw the old buildroot away and start over anyway. out of curiousity, Is the setup of the builders documented somewhere ? I believe it is somewhere, the reference I had is completely out of date. The current configuration would not be the configuration used in primary arch but ultimately it was the best we could do with the platforms that were available 12-18 months ago. A lot has changed in that time. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, Mar 21, 2012 at 2:43 PM, Adam Jackson a...@redhat.com wrote: On Wed, 2012-03-21 at 14:31 +, Matthew Garrett wrote: On Wed, Mar 21, 2012 at 02:28:10PM +, Peter Robinson wrote: What about all the other xorg-x11-drv* video cards, admittedly they're generally considered legacy but there are a lot that don't do 3D at all there. Of the hardware still produced, they're either things Adam listed as unsupported, don't have 3D engines or they're powervr. Oh, yeah, fair, I totally forgot to bitch about Poulsbo there. Insert standard bitching about Poulsbo here. Of hardware not currently in production - where, again, we're talking about whether a 3D driver could usefully be written to enable gnome-shell on the hardware - it's still a remarkably short list. Via did some DX8 parts, XGI before they went out of business, possibly a few SiS parts before they did the same. Yea, I've even heard recent rumours of Via releasing their 3D specs for an actual real open driver! I should emphasize that I don't think hardware 3D needs to be a blocker for a primary arch either. My beef was just with the phrasing that implied that only 3 GPUs was somehow inadequate. Sorry, by only 3 I meant 3 core GPU platforms ie ATI / Intel / nVidia. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, Mar 21, 2012 at 2:49 PM, Adam Jackson a...@redhat.com wrote: On Wed, 2012-03-21 at 10:38 -0400, Bill Nottingham wrote: Peter Robinson (pbrobin...@gmail.com) said: That's my point, I don't believe that working 3D should be a blocker to primary arch because like mainline it will likely come with both time and demand. Is llvmpipe not 'working'? (Admittedly, on low-power CPUs like ARM, it might be more of a burden.) llvmpipe should work on arm - I've not tried - but I suspect it needs a modest amount of surgery to perform adequately. Much of its performance on x86 comes from swizzling the pixel layout around internally so it nicely matches up with SSE2's register layout, which probably isn't quite what arm gives you to work with. I think it could be made to work but it would need optimisation for NEON (one of ARM's equiv of SSE) but that wouldn't work on all devices but it would certainly be a good start but obviously needs someone in the know to implement it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Wx-0.9905.tar.gz uploaded to lookaside cache by spot
A file has been added to the lookaside cache for perl-Wx: 757f337a14869a3fdfa8ebd3444159b1 Wx-0.9905.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-Wx] 0.9905
commit d69eb2b96252d3a54d531a551b37ecbb91a9d94e
Author: Tom Callaway s...@fedoraproject.org
Date: Wed Mar 21 11:29:39 2012 -0400
0.9905
.gitignore |1 +
perl-Wx.spec |7 ++-
sources |2 +-
3 files changed, 8 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index c66493c..ceb260f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ Wx-0.92.tar.gz
/Wx-0.9902.tar.gz
/Wx-0.9903.tar.gz
/Wx-0.9904.tar.gz
+/Wx-0.9905.tar.gz
diff --git a/perl-Wx.spec b/perl-Wx.spec
index ac89a9c..43f2d9e 100644
--- a/perl-Wx.spec
+++ b/perl-Wx.spec
@@ -9,7 +9,7 @@
# for i in `grep -r PACKAGE= * | cut -d -f 2 | sed 's|PACKAGE=|perl(|g'
| grep Wx:: | sort -n |uniq`; do printf Provides: $i)\\n; done
Name: perl-Wx
-Version:0.9904
+Version:0.9905
Release:1%{?dist}
Summary:Interface to the wxWidgets cross-platform GUI toolkit
Group: Development/Libraries
@@ -253,11 +253,13 @@ Provides: perl(Wx::PrintPreview)
Provides: perl(Wx::Process)
Provides: perl(Wx::ProcessEvent)
Provides: perl(Wx::ProgressDialog)
+Provides: perl(Wx::PropertyGrid)
Provides: perl(Wx::RadioBox)
Provides: perl(Wx::RadioButton)
Provides: perl(Wx::Rect)
Provides: perl(Wx::RegConfig)
Provides: perl(Wx::Region)
+Provides: perl(Wx::Ribbon)
Provides: perl(Wx::RichText)
Provides: perl(Wx::SashEvent)
Provides: perl(Wx::SashWindow)
@@ -385,6 +387,9 @@ chmod -R u+w $RPM_BUILD_ROOT/*
%{_mandir}/man3/*.3pm*
%changelog
+* Wed Mar 21 2012 Tom Callaway s...@fedoraproject.org - 0.9905-1
+- update to 0.9905
+
* Fri Mar 2 2012 Tom Callaway s...@fedoraproject.org - 0.9904-1
- update to 0.9904
diff --git a/sources b/sources
index 9a4886c..266d560 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e7422f7d25c1d44ef4fe1ca2a728d6a9 Wx-0.9904.tar.gz
+757f337a14869a3fdfa8ebd3444159b1 Wx-0.9905.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: RFC: Primary architecture promotion requirements
So probably using Qemu could speed it up quite a lot. Also OBS offers quite a lot of flexibility to decouple arch builds, disable selected archs etc. But I'm not sure about the processes for chain builds, updates, how they make the builds consistent (if one arch fails)... All sorts of things can speed it up, most of the Fedora builders are currently loopback ext4 over NFS over 100Mb ethernet over USB. Not optimal. Add to that 1Gb of RAM and swap the problem gets worse. The devices we're looking at have proper SATA ports (not over USB) and quad core 4GB RAM and the time to build is an order of magnitude faster, and those boards aren't overly stable as they're not production level HW so once we get our hands on production level versions of that HW we can start to properly test the difference in large packages such as gcc, qt, libreoffice and the kernel and will be able to much better ascertain the impact. I believe that should be soon although I'm not in direct contact. It was more argument about real qemu speed from real deployment. Not bashing the current setup. It's better to have real data over just talking here :) R. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/21/2012 10:58 AM, Dave Jones wrote: On Wed, Mar 21, 2012 at 01:27:04PM +, Peter Robinson wrote: All sorts of things can speed it up, most of the Fedora builders are currently loopback ext4 over NFS over 100Mb ethernet over USB. Not optimal. Just switching them to ext2 would save a ton of IO. You could also turn off the journal in ext4. That'd lose the journal IO and stalls waiting for it and you'd still get the block mapping IO savings of delalloc and extents. - z -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: H.264 in Fedora 17!
On Wed, 2012-03-21 at 09:55 +0100, Matej Cepl wrote: On 21.3.2012 03:41, Adam Williamson wrote: Firefox will take advantage of a system h264 codec where one is available. In the Fedora system, one will not be available. Fedora as shipped from get.fedoraproject.org won't contain H.264 codec. Which doesn't mean that my computer won't be able to play H.264 movies as well as it does playing MP3s now. Sure. Your system is not the Fedora system. It is the Fedora+RPMFusion system (or whatever). :) -- 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: ARM as a primary architecture
On Wed, Mar 21, 2012 at 2:52 PM, Bill Nottingham nott...@redhat.com wrote: Peter Jones (pjo...@redhat.com) said: In yesterday's FESCo meeting I told you I'd make a list of specific issues I have with the current proposal for ARM as a primary archictecture. There are some places where I think the current proposal fails to deal with some necessary aspects of becoming a primary architecture, and some places where I don't think the approach is quite right. So without further ado: 1) mechanisms need to be in place to get package maintainers access to fix arm-specific bugs in their packages 2) excludearch is not an option. This is fundamentally contrary to being a primary arch. In fact this is one of the defining characteristics of a secondary arch. 3) arm must be integrated to the formal release criteria 4) when milestones occur, arm needs to be just as testible as other primary architectures 5) installation methods must be in place. I'm not saying it has to be using the same model as x86, but when we get to beta, if it can't be installed, it can't meet similar release criteria to existing or prior primary arches. Where possible, we should be using anaconda for installation, though I'd be open to looking at using it to build installed images for machines with severe resource constraints. 6) supported platforms must be fully integrated into building and installation. If you need a special build procedure to make this happen for kernel, we need to have rel-eng signing off saying they've approved of whatever method that is, and QE signing off that they think it'll result in a something they can claim is tested enough to release as a primary arch. 7) it can't be a serious maintenance burdon due to build related issues. We need a couple of groups to sign off that builds are fast enough, not just on a full distro rebuild (throughput) level, but also on a doesn't destroy my workflow due to waiting on it (latency) level. So, the thing I'm seeing over and over in the discussion (well, aside from Kevin), is these list of requirements that must be in place. However, none of these requirements require being a primary arch to do. In essence, if ARM is a primary arch in practice, then it should be able to become one in designation. Stating at an organization level ARM is a primary arch pending on meeting criteria A, B, and C seems backwards. We should continue on threads like this figuring out what makes a primary arch viable, and then table the discussion of whether ARM should be primary until it meets these viability standards. Exactly! Ultimately what we need is FESCo to document what are the requirements of being promoted to a primary architecture and then it's the ARM SIGs job of ensuring they adhere to the requirements, provide viable workable alternatives that are acceptable to FESCo, or provide proof that the requirement will be met within an agreed time frame. Ultimately the ARM SIG knew there would be issues and discussions, ultimately there has never really been an architecture promoted to primary in the current project guidelines since core/extras were merged so there's no criteria for promotion and it was always envisioned that the creation of generic promotion criteria would be part of the requirements of the eventual promotion of ARM. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 latest yum update hoses grub.cfg, grubby?
On Wed, 2012-03-21 at 11:20 +0100, Michal Schmidt wrote: Dne 21.3.2012 03:56, Adam Williamson napsal: Properly, it ought to be versioned grub2-2.00-0.1.beta2.fc17. (Or possibly grub2-2.00-0.1.~beta2.fc17, I really dunno what that tilde is for). The tilde is a debianism to mark a pre-release. dpkg understands version 42~foo as lower than 42. Ahh. Thanks. So we wouldn't use it. -- 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: /usr/share/applications weird error on koji
On Tue, 2012-03-20 at 19:10 -0700, Adam Williamson wrote: The usual way to make this selectable is with a parameter for the package's configure script, something like --disable-desktop-update . These days, it seems like very few packages need this any more. I don't know if upstreams have just stopped doing update-desktop-database at install time, or if they mostly somehow dynamically detect whether to do this or not. The best way is to test in the Makefile(.am) for $(DESTDIR), and skip the call if it's set. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Wed, 2012-03-21 at 14:28 +, Peter Robinson wrote: So it's a little like saying we only support x86 chips from Intel, AMD, and VIA. Okay, yeah, maybe that's fair, but those are actually all there is to care about. What about all the other xorg-x11-drv* video cards, admittedly they're generally considered legacy but there are a lot that don't do 3D at all there. Their existence, at this point, is pretty much theoretical. :) Years of data - Smolt, Smolt-type tools, Phoronix surveys, general (non-Linux) industry surveys - agree very strongly that somewhere between 95% and 99% of x86 systems (I'd pin it at the high end of that range, myself) are using Intel, AMD, or NVIDIA graphics. Those really are all it's honestly worth caring about on x86. -- 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: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 11:32:04AM -0400, Zach Brown wrote: On 03/21/2012 10:58 AM, Dave Jones wrote: On Wed, Mar 21, 2012 at 01:27:04PM +, Peter Robinson wrote: All sorts of things can speed it up, most of the Fedora builders are currently loopback ext4 over NFS over 100Mb ethernet over USB. Not optimal. Just switching them to ext2 would save a ton of IO. You could also turn off the journal in ext4. That'd lose the journal IO and stalls waiting for it and you'd still get the block mapping IO savings of delalloc and extents. Yes, that would be even better. (Hi Zab!) Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 latest yum update hoses grub.cfg, grubby?
On Wed, 2012-03-21 at 11:17 -0400, Peter Jones wrote: On 03/21/2012 02:27 AM, Adam Williamson wrote: On Wed, 2012-03-21 at 00:12 -0600, Chris Murphy wrote: On Mar 21, 2012, at 12:08 AM, Chris Murphy wrote: It seems reasonable to consider this a grubby bug, yes? Considering grub2-mkconfig -o /boot/grub2/grub.cfg produces the exact correct result, guess I'm not understanding the purpose of grubby. Are we in transition? grubby is less 'drastic' that grub2-mkconfig. it takes the existing config and appends a new entry to it. grub2-mkconfig blows away the config and starts over again each time. i don't recall whether we ever made a specific decision to keep using grubby over grub2-mkconfig or whether it's just inertia, though. pjones might. We definitely want to keep using grubby instead of running grub2-mkconfig and clobbering whatever's in your config file every time. Has somebody filed a bz about this issue? I haven't seen one referenced in the thread. https://bugzilla.redhat.com/show_bug.cgi?id=805310 I haven't yet managed to reproduce, though. I'm running grub2 '1.99-19', I installed a kernel package, got no errors, rebooted, and the new kernel was booted. So it seems this doesn't hit every config, we'll have to figure out what the busted configs have in common. Can those experiencing issues with the new grub please take a look at the bug, check their symptoms match the reporter's symptoms, and provide as much info as possible? Thanks. -- 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: /usr/share/applications weird error on koji
On Wed, 2012-03-21 at 12:51 +0200, Nikos Roussos wrote: I wrote a small patch to comment out this line and it worked just fine. I'll file a bug upstream. A patch to simply remove the update-desktop-database call is unlikely to be accepted upstream, as people building for themselves want the call. What you'd want to send upstream is a patch either to make the call optional - enabled by default, but add a ./configure parameter to disable it - or to make the call happen or not depending on whether $(DESTDIR) is set. See the discussion between me and Colin Walters elsewhere in the thread. -- 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
[Bug 804420] perl-Wx-0.9905 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=804420 --- Comment #1 from Tom spot Callaway tcall...@redhat.com 2012-03-21 12:13:23 EDT --- 0.9905 is in rawhide. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 804420] perl-Wx-0.9905 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=804420 Tom spot Callaway tcall...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE Last Closed||2012-03-21 12:13:36 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rawhide report: 20120321 changes
Compose started at Wed Mar 21 08:15:05 UTC 2012 Broken deps for x86_64 -- [HippoDraw] HippoDraw-devel-1.21.3-2.fc17.i686 requires python-numarray HippoDraw-devel-1.21.3-2.fc17.x86_64 requires python-numarray HippoDraw-python-1.21.3-2.fc17.x86_64 requires python-numarray [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc18.noarch requires ruby-nokogiri [alexandria] alexandria-0.6.8-2.fc17.1.noarch requires ruby(abi) = 0:1.8 [ballz] ballz-1.0.2-4.fc18.x86_64 requires libguichan_allegro-0.8.2.so.1()(64bit) ballz-1.0.2-4.fc18.x86_64 requires libguichan-0.8.2.so.1()(64bit) [catfish] catfish-engines-0.3.2-4.fc17.1.noarch requires pinot [comoonics-cdsl-py] comoonics-cdsl-py-0.2-19.noarch requires comoonics-base-py [comoonics-cluster-py] comoonics-cluster-py-0.1-25.noarch requires comoonics-base-py [contextkit] contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) [converseen] converseen-0.4.9-2.fc17.x86_64 requires libMagickWand.so.4()(64bit) converseen-0.4.9-2.fc17.x86_64 requires libMagickCore.so.4()(64bit) converseen-0.4.9-2.fc17.x86_64 requires libMagick++.so.4()(64bit) [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [dmapd] dmapd-0.0.45-1.fc16.i686 requires libMagickWand.so.4 dmapd-0.0.45-1.fc16.i686 requires libMagickCore.so.4 dmapd-0.0.45-1.fc16.x86_64 requires libMagickWand.so.4()(64bit) dmapd-0.0.45-1.fc16.x86_64 requires libMagickCore.so.4()(64bit) [dustmite] dustmite-1-1.20111218git84c0e08.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [eruby] eruby-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) eruby-libs-1.0.5-17.fc17.i686 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.i686 requires libruby.so.1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 [gearmand] gearmand-0.23-2.fc17.x86_64 requires libtcmalloc.so.0()(64bit) gearmand-0.23-2.fc17.x86_64 requires libmemcached.so.8()(64bit) gearmand-0.23-2.fc17.x86_64 requires libboost_program_options-mt.so.1.47.0()(64bit) [genius] genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) gnome-genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) [gnome-phone-manager] gnome-phone-manager-0.66-9.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [gnome-user-share] gnome-user-share-3.0.1-3.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [gorm] gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23 gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-gui.so.0.20()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-base.so.1.23()(64bit) [gscribble] gscribble-0.1.2-2.fc17.noarch requires gnome-python2-gtkhtml2 [i3] i3-4.0.1-2.fc17.x86_64 requires libxcb-property.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-keysyms.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-icccm.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-event.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-aux.so.0()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-atom.so.1()(64bit) [ibus-unikey] ibus-unikey-0.6.1-1.fc18.x86_64 requires libibus-1.0.so.0()(64bit) [inkscape] inkscape-0.48.2-4.fc17.x86_64 requires libMagickCore.so.4()(64bit) inkscape-0.48.2-4.fc17.x86_64 requires libMagick++.so.4()(64bit) inkscape-view-0.48.2-4.fc17.x86_64 requires libMagickCore.so.4()(64bit) inkscape-view-0.48.2-4.fc17.x86_64 requires libMagick++.so.4()(64bit) [kazehakase] kazehakase-ruby-0.5.8-11.svn3873_trunk.fc17.x86_64 requires ruby(abi) = 0:1.8 kazehakase-ruby-0.5.8-11.svn3873_trunk.fc17.x86_64 requires libruby.so.1.8()(64bit) [matreshka] matreshka-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnarl-4.6.so
Re: F17 bogus could not detect partitions error
On Mar 20, 2012, at 12:52 PM, Chris Murphy wrote: Proposed as blocker, F17 Final. https://bugzilla.redhat.com/show_bug.cgi?id=805272 Does anyone know how GRUB2 (bootloader+core, grub2-install, grub2-mkconfig) will behave in a case where there is a valid legacy MBR and a stale GPT remains behind? The present patch does not blank the stale GPT. While I agree with bcl that the less changed the better, there may be unintended consequences. I asked this question on grub-devel@ but no replies so far. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reminder. Please build ImageMagick dependencies until March 23
On 03/21/2012 04:33 PM, Pavel Alexeev wrote: Hello All. As was announced before ImageMagick-6.7.5.6-3.fc17 now in build overrides. Please build your package against it (and answer there if it not so hard). 23 march I'll push one update for Fedora 17. -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru Hi, could you post the list of packages, which should be rebuild? It's quite hard to find from CC who should build which package. Thanks, Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: parcellite
Am Mittwoch, den 21.03.2012, 12:52 + schrieb build...@fedoraproject.org: parcellite has broken dependencies in the rawhide tree: On i386: parcellite-1.0.2-0.1.rc5.fc17.i686 requires libpango-1.0.so.0()(64bit) parcellite-1.0.2-0.1.rc5.fc17.i686 requires libgtk-x11-2.0.so.0()(64bit) parcellite-1.0.2-0.1.rc5.fc17.i686 requires libgobject-2.0.so.0()(64bit) parcellite-1.0.2-0.1.rc5.fc17.i686 requires libglib-2.0.so.0()(64bit) parcellite-1.0.2-0.1.rc5.fc17.i686 requires libgdk-x11-2.0.so.0()(64bit) parcellite-1.0.2-0.1.rc5.fc17.i686 requires libc.so.6(GLIBC_2.3.4)(64bit) parcellite-1.0.2-0.1.rc5.fc17.i686 requires libX11.so.6()(64bit) Please resolve this as soon as possible. I resolved this on March 10th with 1.0.2-0.2.rc5 http://koji.fedoraproject.org/koji/buildinfo?buildID=306351 but still I keep getting these mails. Why? And why is the script complaining about the F17 package when there is a F18 one in rawhide? Kind regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: parcellite
On Wed, Mar 21, 2012 at 6:02 PM, Christoph Wickert christoph.wick...@googlemail.com wrote: Am Mittwoch, den 21.03.2012, 12:52 + schrieb build...@fedoraproject.org: parcellite has broken dependencies in the rawhide tree: On i386: parcellite-1.0.2-0.1.rc5.fc17.i686 requires libpango-1.0.so.0()(64bit) parcellite-1.0.2-0.1.rc5.fc17.i686 requires libgtk-x11-2.0.so.0()(64bit) parcellite-1.0.2-0.1.rc5.fc17.i686 requires libgobject-2.0.so.0()(64bit) parcellite-1.0.2-0.1.rc5.fc17.i686 requires libglib-2.0.so.0()(64bit) parcellite-1.0.2-0.1.rc5.fc17.i686 requires libgdk-x11-2.0.so.0()(64bit) parcellite-1.0.2-0.1.rc5.fc17.i686 requires libc.so.6(GLIBC_2.3.4)(64bit) parcellite-1.0.2-0.1.rc5.fc17.i686 requires libX11.so.6()(64bit) Please resolve this as soon as possible. I resolved this on March 10th with 1.0.2-0.2.rc5 http://koji.fedoraproject.org/koji/buildinfo?buildID=306351 but still I keep getting these mails. Why? And why is the script complaining about the F17 package when there is a F18 one in rawhide? Looks like the script looks for fc17, but says it's rawhide... (There are still broken deps in fc17, because your update is not yet stable: https://admin.fedoraproject.org/updates/FEDORA-2012-3933/parcellite-1.0.2-0.2.rc5.fc17 ) Greetings, Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/21/2012 05:25 AM, Chris Tyler wrote: Fully-emulated actually fits into the Native Builds guideline, but it hasn't been economical to use this approach because there's no hardware support for ARM emulation on x86 (the way that there is hardware acceleration for x86 virtualization on x86) and it therefore requires a very fast/expensive x86 box to emulate a slow/cheap ARM box. The main place I see ARM emulation being useful is in allowing any packager with an x86 host to boot a simulated ARM host to resolve build failures in their package. That's not ideal- ideal is every package owner has an ARM system they can use, but it's perhaps a starting point. If other people have feedback on this point I'd be interested to hear their take on it. I think a combination of ARM emulation and providing a network-accessible set of test machines will go along way toward giving packagers what they need and plan to update the proposal to say so, subject to the feedback we get on this point. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reminder. Please build ImageMagick dependencies until March 23
21.03.2012 20:31, Marcela Mašláňová написал:
On 03/21/2012 04:33 PM, Pavel Alexeev wrote:
Hello All.
As was announced before ImageMagick-6.7.5.6-3.fc17 now in build
overrides. Please build your package against it (and answer there if it
not so hard).
23 march I'll push one update for Fedora 17.
--
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me use jabber: hubbi...@jabber.ru
Hi,
could you post the list of packages, which should be rebuild? It's
quite hard to find from CC who should build which package.
Off course:
$ repoquery --repoid=rawhide --whatrequires --alldeps --qf %{NAME}
ImageMagick\* | sort -u
a2ps
ale
autotrace
autotrace-devel
calibre
cuneiform
dblatex
drawtiming
dx
dx-libs
emacs
fbida
freewrl
fvwm
gallery2-imagemagick
gdl
gdl-python
geeqie
gnome-exe-thumbnailer
gpsdrive
gscan2pdf
gyachi
hdrprep
html2ps
icewm-clearlooks
imageinfo
k3d
kipi-plugins
kxstitch
latex2rtf
libdmtx-utils
libpst
lyx
mediawiki-imagemap
mediawiki-nomath
mtpaint
nautilus-image-converter
perl-GD-SecurityImage
perl-Image-Size
perl-Panotools-Script
perl-WebService-Rajce
pfstools
pfstools-imgmagick
phatch-cli
php-magickwand
php-pecl-imagick
plowshare
publican
RabbIT
ruby-RMagick
shutter
techne
tetex-tex4ht
vips-devel
w3m-img
xastir
xine-lib-extras
zbar
There may be some excessive list, but I hope nothing forgotten.
Thanks,
Marcela
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 3/21/12 6:52 AM, Peter Jones wrote: On 03/21/2012 09:21 AM, Josh Boyer wrote: Except when people are forced to look at it, their solution was often ExcludeArch for PPC. As I said in the other thread, you cannot force people to care about an architecture they don't know or want to learn. That suggests we need a FTBFS-like nightly test that lets us know about new, unexpected ExcludeArches in the distro. This sounds like the perfect use case for a SCM feature I haven't had the time to work on. If all commit diffs are sent to a message bus by way of a git hook, then one consumer on the bus could be canning for additions of ExcludeArch. When these are discovered a bug could be filed automatically, or some group would get notified, basically something would happen, and we wouldn't depend on a human noticing the change or following policy to file a bug. In the short term, if this is something we see high value in tracking, we can just add another git hook to do this directly, rather than relying on a message bus. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 latest yum update hoses grub.cfg, grubby?
On Mar 21, 2012, at 9:17 AM, Peter Jones wrote: We definitely want to keep using grubby instead of running grub2-mkconfig and clobbering whatever's in your config file every time. *shrug* I think grubby makes for an increasingly cluttered grub.cfg. With the latest behavior I'm seeing with 2.00~beta2's grub2-mkconfig, it cleans up after itself nicely. The grub.cfg pretty clearly indicates it can be clobbered, by design. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-IO-InSitu/f17] Initial import (#605674).
Summary of changes: 42abd26... Initial import (#605674). (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: RFC: Primary architecture promotion requirements
On 3/21/12 10:36 AM, Brendan Conoboy wrote: The main place I see ARM emulation being useful is in allowing any packager with an x86 host to boot a simulated ARM host to resolve build failures in their package. That's not ideal- ideal is every package owner has an ARM system they can use, but it's perhaps a starting point. If other people have feedback on this point I'd be interested to hear their take on it. I think a combination of ARM emulation and providing a network-accessible set of test machines will go along way toward giving packagers what they need and plan to update the proposal to say so, subject to the feedback we get on this point. Arm emulation would go a long way toward validating produced install images too. Those of us that validate x86 images depend heavily on KVM and the like. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On 03/21/2012 06:26 AM, Peter Robinson wrote: Thanks Adam, this is the first real use case where speed of builds is important for something other than keeping the developer happy. Other points raised on the list are: 1. The nature of chainbuilds would feel slowed build times particularly. This is more of a multi-developer happy item. 2. Total turnaround time on security updates. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Mar 2012 06:07:57 -0400 (EDT) Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - Maybe it's worth to ask them (or look at for example Mer builds) what's the difference in build times. A few statistics from build.meego.com - using the OBS and building in qemu. These are really just approximate numbers, built in different times with probably a different load... I have spoken with the OpenSUSE guys they dont use qemu-system-arm but rather qemu-arm and lay out things and build using a hybrid environment thats also how they build ppc s390 and other arches. the only build hardware they have is x86. doing full system emulation will be slower. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9qGdQACgkQkSxm47BaWfcQ3gCfWys0mvR6MOKZRTj9hcopT92C OMgAn1/jXyJdJ7tvJAVsZiLZCU7MvJTk =6tKT -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Mar 2012 10:12:58 -0400 Josh Boyer jwbo...@gmail.com wrote: On Wed, Mar 21, 2012 at 9:52 AM, Peter Jones pjo...@redhat.com wrote: On 03/21/2012 09:21 AM, Josh Boyer wrote: Except when people are forced to look at it, their solution was often ExcludeArch for PPC. As I said in the other thread, you cannot force people to care about an architecture they don't know or want to learn. That suggests we need a FTBFS-like nightly test that lets us know about new, unexpected ExcludeArches in the distro. Possibly. There are ExcludeArch trackers that people are supposed to make their bugs block and that was normally sufficient to give the arch team a heads up. However, I'm sure there were packages that didn't have bugs filed like that. the main issue is that we need to have tracking in place that doesnt require people do anything. because people dont do what they should. I see it all the time when dealing with mass rebuilds etc people do one or 2 of the steps to remove a package, but quite often do not do all 3. We do have plans to redo it to make it a single step. the more we can automate the tracking of it the better we will nknow the full extent of where things are. if we can cut down on what people have to do the more likely it will be that we have true representation of the data. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9qG08ACgkQkSxm47BaWfcgZwCfUKuV7OhzKPIqvVQGMAmKb/Hf dPgAoKD8T6bqeLYKMXxvJJHQiINoxOFQ =pYET -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Wed, Mar 21, 2012 at 7:11 PM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Mar 2012 06:07:57 -0400 (EDT) Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - Maybe it's worth to ask them (or look at for example Mer builds) what's the difference in build times. A few statistics from build.meego.com - using the OBS and building in qemu. These are really just approximate numbers, built in different times with probably a different load... I have spoken with the OpenSUSE guys they dont use qemu-system-arm but rather qemu-arm and lay out things and build using a hybrid environment thats also how they build ppc s390 and other arches. the only build hardware they have is x86. doing full system emulation will be slower. Which is exactly what I proposed ... i.e use cross compilers and really on qemu to run stuff that gets generated and run during build. But there seems to be a huge oppositions against that in Fedora. How does Ubuntu build there ARM builds? Native or using cross compilers? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reminder. Please build ImageMagick dependencies until March 23
On 03/21/2012 11:42 AM, Pavel Alexeev wrote:
21.03.2012 20:31, Marcela Mašláňová написал:
On 03/21/2012 04:33 PM, Pavel Alexeev wrote:
Hello All.
As was announced before ImageMagick-6.7.5.6-3.fc17 now in build
overrides. Please build your package against it (and answer there if it
not so hard).
23 march I'll push one update for Fedora 17.
--
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me use jabber: hubbi...@jabber.ru
Hi,
could you post the list of packages, which should be rebuild? It's quite
hard to find from CC who should build which package.
Off course:
$ repoquery --repoid=rawhide --whatrequires --alldeps --qf %{NAME}
ImageMagick\* | sort -u
There may be some excessive list, but I hope nothing forgotten.
This may be more accurate:
# repoquery --whatrequires libMagickCore.so.4 --qf '%{NAME}'
ale
autotrace
calibre
converseen
dmapd
drawtiming
dx
dx-libs
emacs
gdl
gdl-python
imageinfo
inkscape
inkscape-view
k3d
kxstitch
libdmtx-utils
nip2
oxine
pfstools
pfstools-imgmagick
php-magickwand
php-pecl-imagick
psiconv
q-magick
rss-glx
ruby-RMagick
techne
vips
vips-python
vips-tools
xastir
xine-lib-extras
zbar
--
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
File IO-InSitu-0.0.2.tar.gz uploaded to lookaside cache by wfp
A file has been added to the lookaside cache for perl-IO-InSitu: 69e55eda0c3d0e5597b88a9ccf9fbfc3 IO-InSitu-0.0.2.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-IO-InSitu] Initial import (#605674).
commit 42abd2609be3ccfdd50e0907237849fa163624fd
Author: Bill Pemberton wf...@virginia.edu
Date: Wed Mar 21 13:05:24 2012 -0400
Initial import (#605674).
.gitignore |1 +
perl-IO-InSitu.spec | 83 +++
sources |1 +
3 files changed, 85 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..c2933eb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/IO-InSitu-0.0.2.tar.gz
diff --git a/perl-IO-InSitu.spec b/perl-IO-InSitu.spec
new file mode 100644
index 000..e2e40a7
--- /dev/null
+++ b/perl-IO-InSitu.spec
@@ -0,0 +1,83 @@
+Name: perl-IO-InSitu
+Version: 0.0.2
+Release: 6%{?dist}
+Summary: Avoid clobbering files opened for both input and output
+License: GPL+ or Artistic
+Group: Development/Libraries
+URL: http://search.cpan.org/dist/IO-InSitu/
+Source0:
http://www.cpan.org/authors/id/D/DC/DCONWAY/IO-InSitu-%{version}.tar.gz
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
+BuildArch: noarch
+BuildRequires: perl(Module::Build)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(version)
+BuildRequires: perl(base)
+BuildRequires: perl(Carp)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(IO::File)
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+
+# Filter from provides
+%global __provides_exclude ^perl\\((IO::File::SE)\\)
+
+
+%description
+This module provides a function called open_rw(), that is passed two
+file names and returns two handles, one open for reading and the other
+for writing. It's like doing two separate open() calls, except that it
+detects cases where the input and output file are the same, and avoids
+clobbering the input file when reopening it for output.
+
+%prep
+%setup -q -n IO-InSitu-%{version}
+
+# Filter out bogus provides (prior to rpm 4.9)
+%global provfilt /bin/sh -c %{__perl_provides} | grep -Evx
'perl(IO::File::SE)'
+%define __perl_provides %{provfilt}
+
+%build
+perl Build.PL installdirs=vendor
+./Build
+
+%install
+rm -rf $RPM_BUILD_ROOT
+
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+./Build test
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(-,root,root,-)
+%doc Changes README
+%{perl_vendorlib}/IO/
+%{_mandir}/man3/IO::InSitu.3pm*
+
+%changelog
+* Wed Mar 21 2012 Bill Pemberton wf...@virginia.eduu - 0.0.2-6
+- Remove command macro from MODULE_COMPAT
+
+* Wed Mar 21 2012 Bill Pemberton wf...@virginia.edu - 0.0.2-5
+- Add provides filters that work with all supported distributions
+- Add BuildRequires for dual-lived modules
+- Don't remove empty directories from the buildroot as it's uneeded
+- Remove use of command macros
+
+* Wed Dec 1 2010 Bill Pemberton wf...@virginia.edu 0.0.2-4
+- Fix rpmlint warning about mixed spaces and tabs
+
+* Tue Nov 30 2010 Bill Pemberton wf...@virginia.edu 0.0.2-3
+- Add perl(version) back to BuildRequires
+
+* Tue Nov 30 2010 Bill Pemberton wf...@virginia.edu 0.0.2-2
+- Clean up spec file to address suggestions from Paul Howarth
+
+* Fri May 28 2010 Bill Pemberton wf...@virginia.edu 0.0.2-1
+- Initial specfile based on version generated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..dc30e6c 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+69e55eda0c3d0e5597b88a9ccf9fbfc3 IO-InSitu-0.0.2.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: Reminder. Please build ImageMagick dependencies until March 23
On 03/21/2012 02:19 PM, Orion Poplawski wrote:
On 03/21/2012 11:42 AM, Pavel Alexeev wrote:
21.03.2012 20:31, Marcela Mašláňová написал:
On 03/21/2012 04:33 PM, Pavel Alexeev wrote:
Hello All.
As was announced before ImageMagick-6.7.5.6-3.fc17 now in build
overrides. Please build your package against it (and answer there if it
not so hard).
23 march I'll push one update for Fedora 17.
--
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me use jabber: hubbi...@jabber.ru
Hi,
could you post the list of packages, which should be rebuild? It's quite
hard to find from CC who should build which package.
Off course:
$ repoquery --repoid=rawhide --whatrequires --alldeps --qf %{NAME}
ImageMagick\* | sort -u
There may be some excessive list, but I hope nothing forgotten.
This may be more accurate:
# repoquery --whatrequires libMagickCore.so.4 --qf '%{NAME}'
Passing --source there may also simplify things.
~tom
==
Fedora Project
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reminder. Please build ImageMagick dependencies until March 23
On 03/21/2012 12:34 PM, Tom Callaway wrote:
On 03/21/2012 02:19 PM, Orion Poplawski wrote:
On 03/21/2012 11:42 AM, Pavel Alexeev wrote:
21.03.2012 20:31, Marcela Mašláňová написал:
On 03/21/2012 04:33 PM, Pavel Alexeev wrote:
Hello All.
As was announced before ImageMagick-6.7.5.6-3.fc17 now in build
overrides. Please build your package against it (and answer there if it
not so hard).
23 march I'll push one update for Fedora 17.
--
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me use jabber: hubbi...@jabber.ru
Hi,
could you post the list of packages, which should be rebuild? It's quite
hard to find from CC who should build which package.
Off course:
$ repoquery --repoid=rawhide --whatrequires --alldeps --qf %{NAME}
ImageMagick\* | sort -u
There may be some excessive list, but I hope nothing forgotten.
This may be more accurate:
# repoquery --whatrequires libMagickCore.so.4 --qf '%{NAME}'
Passing --source there may also simplify things.
Keeps forgetting about that. Messes up --qf though:
# repoquery --whatrequires libMagickCore.so.4 --source --qf '%{NAME}' | sort -u
ale-0.9.0.3-6.fc17.src.rpm
autotrace-0.31.1-26.fc15.1.src.rpm
calibre-0.8.39-1.fc17.src.rpm
converseen-0.4.9-2.fc17.src.rpm
dmapd-0.0.45-1.fc16.src.rpm
drawtiming-0.7.1-5.fc17.src.rpm
dx-4.4.4-21.fc17.src.rpm
emacs-24.0.94-1.fc17.src.rpm
gdl-0.9.2-3.fc17.src.rpm
imageinfo-0.05-14.fc17.src.rpm
ImageMagick-6.7.1.9-3.fc17.src.rpm
inkscape-0.48.2-4.fc17.src.rpm
k3d-0.8.0.2-6.fc17.src.rpm
kxstitch-0.8.4.1-8.fc17.src.rpm
libdmtx-0.7.2-6.fc17.src.rpm
nip2-7.26.4-1.fc17.src.rpm
oxine-0.7.1-13.fc17.src.rpm
pfstools-1.8.3-5.fc17.src.rpm
php-magickwand-1.0.9-2.fc17.src.rpm
php-pecl-imagick-3.1.0-0.1.RC1.fc17.src.rpm
psiconv-0.9.8-9.fc17.src.rpm
q-7.11-12.fc17.2.src.rpm
rss-glx-0.9.1.p-10.fc17.src.rpm
ruby-RMagick-2.13.1-9.fc17.src.rpm
techne-0.2.1-3.fc17.src.rpm
vips-7.26.7-1.fc17.src.rpm
xastir-2.0.0-3.fc17.src.rpm
xine-lib-1.1.20.1-2.fc17.src.rpm
zbar-0.10-10.fc17.src.rpm
--
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: F17 latest yum update hoses grub.cfg, grubby?
On Wed, 2012-03-21 at 12:02 -0600, Chris Murphy wrote: On Mar 21, 2012, at 9:17 AM, Peter Jones wrote: We definitely want to keep using grubby instead of running grub2-mkconfig and clobbering whatever's in your config file every time. *shrug* I think grubby makes for an increasingly cluttered grub.cfg. With the latest behavior I'm seeing with 2.00~beta2's grub2-mkconfig, it cleans up after itself nicely. The grub.cfg pretty clearly indicates it can be clobbered, by design. yeah, I have to admit I get the feeling we're kind of swimming against the tide, now. I'm not sure it would be so terrible to just decide to go with the upstream design, run grub2-mkconfig any time grub2.cfg needs updating, and tell people to do customization in the /etc/grub.d stuff as upstream intends. The whole point of going with grub2 was to get closer to upstream and reduce our maintenance burden, right? grubby feels like a substantial chunk of maintenance burden too. -- 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
