Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 01/03/10 00:06, Kevin Kofler wrote: (Sorry, I reordered the replies a bit so I can reply to them without referring back and forth.) It's also called political licence Frank Murphy wrote: On 02/27/2010 04:30 PM, Mail Lists wrote: an 1: I do want updates. Kernel updates, for example, are very important - they carry many improvements - not just drivers but functionality as well. The ones that are less obvious are the bugs that happen rarely but that can be nasty (an occasional file system glitch for example). As as enduser. I would agree with this. So you claim to agree with the parent poster… If you mean these points from Mail Lists then yes. These kind of non-user-demand driven fixes should not be ignored in any noone-is-asking so dont release approach. If it's not broken, don't fix it. … yet you actually don't, and… The rare-but-nasty bug fixes will seldom have user demand - but nonetheless once identified and fixed should be shared. Bug fixes would also be applied. … so which is it now? Do you now think bugfixes which don't fix a bug in our Bugzilla should be pushed or not? The why\how is it a bug? Who decided? Handshake? If it's a bug and you (generic) know about it, please refrence it in bugzilla, even if only providing a link to upstream Bugzilla\Similar FWIW, I think they should indeed be pushed, as the fact that the bug is not in our Bugzilla does not mean it doesn't affect Fedora users (and so the package IS in fact broken and should be fixed)! Thats what Bugzilla is for. If people so not report bugs, they should be educated to do so. Whether user\dev\packager\ etc.. No one is a mind reader. And in addition: On the everyday boxes there is FedoraN + F13\Rawhide Kernel(s). … so the stable Fedora kernels aren't upgraded often enough for you, but … As 1 above. (fixes things for me) I do report bugs. I also read Koji notes. But it's not a repo. If it's not broken, don't fix it. Thats what the F13/Rawhide boxes are for. … you seem to advocate an even more conservative upgrade policy? Semantics. You want embellishment go Rawhide. otherwise stick with Security\Bugs as updates. I must say I don't understand your position at all. Kevin Kofler It's still the same. Security\Bugfixes(BZ'ed ones). So there is a refrence point. -- Regards, Frank Murphy UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Friday 26 February 2010 16:22:37 Kevin Kofler wrote: Jaroslav Reznik wrote: Maybe some package rating included in PackageKit would be nice - for stable packages it's indicator that this package is worth to install, for testing package it would mean it's working (but again - who's going to rate it in pkgkit once installed). That won't solve the problem that people aren't using updates-testing in the first place. We can't force them to. One problem of updates-testing is - it takes so much time to be pushed and then mirrored. More rawhide approach should be used here. Users who are really interested in testing usually downloads from Koji directly. And for follow up thread - we can't force users to be testers but as Adam pointed out - any help for people who'd like test is great. This should be first step before changing stable/testing policy. In case of fail - whole system has to be changed (and I don't have any idea how - right now). Jaroslav Kevin Kofler -- Jaroslav Řezník jrez...@redhat.com Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 3/1/2010 10:44 AM, Jaroslav Reznik wrote: One problem of updates-testing is - it takes so much time to be pushed and then mirrored. More rawhide approach should be used here. Users who are really interested in testing usually downloads from Koji directly. It is not so simple. When I am working with a maintainer to solve a problem, of course I will pull from Koji. But I don't track Koji. I scan testing to see if it has something that interests me. Otherwise I stay with stable. So updates-testing is useful for anything that I want cutting edge and the delay doesn't bother me because I wasn't waiting for the update. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Config-Any/F-13 perl-Config-Any.spec, 1.12, 1.13 sources, 1.8, 1.9
Author: cweyl
Update of /cvs/extras/rpms/perl-Config-Any/F-13
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv26990
Modified Files:
perl-Config-Any.spec sources
Log Message:
* Mon Mar 01 2010 Chris Weyl cw...@alumni.drew.edu 0.19-1
- update by Fedora::App::MaintainerTools 0.004
- PERL_INSTALL_ROOT = DESTDIR
- added a new br on perl(ExtUtils::MakeMaker) (version 6.42)
- dropped old BR on perl(JSON::Syck)
- added manual BR on perl(JSON::XS)
- added a new req on perl(Module::Pluggable) (version 3.01)
- dropped old requires on perl(JSON::Syck)
- added manual requires on perl(JSON::XS)
Index: perl-Config-Any.spec
===
RCS file: /cvs/extras/rpms/perl-Config-Any/F-13/perl-Config-Any.spec,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -p -r1.12 -r1.13
--- perl-Config-Any.spec11 Jan 2010 05:23:26 - 1.12
+++ perl-Config-Any.spec1 Mar 2010 08:59:00 - 1.13
@@ -1,40 +1,40 @@
Name: perl-Config-Any
-Version:0.18
-Release:1%{?dist}
Summary:Load configuration from different file formats, transparently
+Version:0.19
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
+Source0:
http://search.cpan.org/CPAN/authors/id/B/BR/BRICAS/Config-Any-%{version}.tar.gz
URL:http://search.cpan.org/dist/Config-Any/
-Source0:
http://search.cpan.org/CPAN/authors/id/B/BR/BRICAS/Config-Any-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+BuildArch: noarch
+BuildRequires: perl(Config::General)
+BuildRequires: perl(Config::Tiny)
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
+BuildRequires: perl(JSON::XS)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Module::Pluggable) = 3.01
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
BuildRequires: perl(version)
-BuildRequires: perl(JSON::Syck)
-BuildRequires: perl(Config::General)
-BuildRequires: perl(Config::Tiny)
+BuildRequires: perl(XML::LibXML)
BuildRequires: perl(XML::Simple)
BuildRequires: perl(YAML::XS)
-# tests
-BuildRequires: perl(Test::More)
-BuildRequires: perl(Scalar::Util)
-BuildRequires: perl(XML::LibXML)
-
-# optional tests
-BuildRequires: perl(Test::Pod), perl(Test::Pod::Coverage)
-
-# not picked up
-Requires: perl(JSON::Syck)
Requires: perl(Config::General)
Requires: perl(Config::Tiny)
+Requires: perl(JSON::XS)
+Requires: perl(Module::Pluggable) = 3.01
Requires: perl(XML::Simple)
Requires: perl(YAML::XS)
+%{?perl_default_filter}
+%{?perl_default_subpackage_tests}
+
%description
Config::Any provides a facility for Perl applications and libraries to
load configuration data from multiple different file formats. It supports
@@ -44,39 +44,14 @@ Perl code.
%prep
%setup -q -n Config-Any-%{version}
-# make rpmlint happy :)
-find t/ -type f -exec sed -i 's/\r//' {} \;
-perl -pi -e 's|^#!perl|#!/usr/bin/perl|' t/*.t
-
-# Filter unwanted Provides:
-cat \EOF %{name}-prov
-#!/bin/sh
-%{__perl_provides} $* |\
- sed -e '/perl(MockApp)/d'
-EOF
-
-%define __perl_provides %{_builddir}/Config-Any-%{version}/%{name}-prov
-chmod +x %{__perl_provides}
-
-# Filter unwanted Requires:
-cat \EOF %{name}-req
-#!/bin/sh
-%{__perl_requires} $* |\
- sed -e '/perl(Test::More)/d; /perl(Scalar::Util)/d'
-EOF
-
-%define __perl_requires %{_builddir}/Config-Any-%{version}/%{name}-req
-chmod +x %{__perl_requires}
-
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
-
%install
rm -rf %{buildroot}
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
+make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
@@ -91,11 +66,21 @@ rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
# conf/ for examples of different config types
-%doc Changes README t/
+%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Mon Mar 01 2010 Chris Weyl cw...@alumni.drew.edu 0.19-1
+- update by Fedora::App::MaintainerTools 0.004
+- PERL_INSTALL_ROOT = DESTDIR
+- added a new br on perl(ExtUtils::MakeMaker) (version 6.42)
+- dropped old BR on perl(JSON::Syck)
+- added manual BR on perl(JSON::XS)
+- added a new req on perl(Module::Pluggable) (version 3.01)
+- dropped old requires on perl(JSON::Syck)
+- added manual requires on perl(JSON::XS)
+
* Mon Jan 11 2010 Iain Arnell iarn...@gmail.com 0.18-1
- update to latest upstream version
- prefer YAML::XS over YAML::Syck
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Config-Any/F-13/sources,v
retrieving revision 1.8
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Le Dim 28 février 2010 17:24, Adam Williamson a écrit : On Sun, 2010-02-28 at 11:43 +0100, Nicolas Mailhot wrote: There are things only packagers can fix. Everything else should be handled by tools so packagers can focus on the parts where they add real value. If a process change puts more burden on all packagers because it's easier to ask packagers to do stuff than fix tools, it's a bad process change. And yes I accept than in some cases not burdening packagers means increasing the chance for some problems. Perfection is the ennemy of good. This is a wonderful sentiment. How does it apply to the current situation, exactly? What 'tools' is it you're saying are not fixed? Clearly, bohdi/bugzilla/pk interaction is not good enough to collect the kind of feedback needed for the karma system to work. And bohdi should get smarter about identifying packages that need this feedback. Critical path is a good first approximation but what would really help is some heuristic about how much breakage a bad package can cause : how many other packages depend on it (dependency metrics), how long is has lived (has it been in Fedora for years of imported the week before), was it even in the default install for some people, etc. testing is not really operational right now so the main value of forcing people to use testing is to make the process painful enough they are less update-happy. I don't think we should ever aim to make any part of the process painful. This is an anti-feature. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
James Antill wrote: Mike didn't say that, Mike said that if a user was intentionally not updating to Fedora 12 due to the newer KDE ... you've just removed that choice from them. And for no real gain, as anyone who wanted to the KDE update could easily move to Fedora 12 to get it. That argument sorta holds for the second KDE upgrade in the release cycle, but not for the first. If I want 4.4.0 now, there's no F13 to upgrade to, it's not even in alpha yet. KDE schedules aren't aligned to Fedora schedules. The usefulness of the second update in the cycle is more debatable and in fact some people in KDE SIG are considering to stop doing that one. My arguments against that (i.e. in favor of keeping the second update) are: * Users will feel treated like second-class citizens. Either a release is supported or it's not, I don't like this half-supported state. * KDE doesn't ship bugfix releases from the old branch after the new branch is released, so we'd either have to backport all those patches ourselves, which doesn't look feasible to me (it would require massive manpower which frankly NO distro has, I'm really not looking forward to spending day and night on backporting KDE bugfixes!) or our users would be stuck with no more bugfixes, which frankly looks like a degraded experience to me (see the point about second-class citizens above). * We'd have to maintain the old and new release at the same time, leading to extra work. (The more bugfixes we backport, the more work. Security only would be trivial, but the worst user experience. Anything better requires extra work as opposed to just building the same thing for the 2 supported releases at the same time.) But after changing the question to one you think you do better at, you are still wrong. The current state of play is (taking a random kde example): kdeutils F11 GA 4.2.2-4.fc11 kdeutils F11 Updates 4.4.0-1.fc11 kdeutils F12 GA 4.3.2-1.fc12 kdeutils F12 Updates 4.4.0-1.fc12 ...so if someone tries to update from F11 (with updates) using an F12 GA release DVD, it'll be an older version and I very much doubt you've tested how well that works. Upgrading using the DVD is broken by design and just cannot work. It goes far beyond KDE, we also do version upgrades for things like security fixes. For F10 to F11, you'd even end up with a broken yum when upgrading using the DVD! And for KDE, it'd still break even if we pushed only 4.3.x bugfix releases. We'd have had to stick to 4.2.x to make that work, and that'd really suck as explained in the first paragraph. (And it wouldn't solve the problem for all the other version upgrades anyway, and doing away with those is no option, it'd require us to always backport bug and security fixes which goes very much against our follow upstream policy.) The DVD needs to be fixed to pull in the updates repository during upgrades, which it currently doesn't support (and it shouldn't even be optional, but mandatory, because the upgrade option is completely useless without that). IMHO the DVD should be discontinued entirely. Fresh installs should use the live CDs, upgrades should use preupgrade or plain yum upgrade. Those are the only options that work. (Fresh installing from the DVD sucks because the package selection is not desktop-environment-aware.) But if the DVD is to be kept, it ought to be fixed: * upgrades MUST include the updates repository, * fresh installs need a desktop selection screen like in openSUSE and then comps needs to be conditionalized based on the desktop, so that if you select that Graphical Internet group, you get Firefox (and/or Epiphany) and Evolution if you picked GNOME, Konqueror (kdebase) and kdepim if you picked KDE, lynx and mutt if you picked no desktop (or Graphical Internet could even be hidden entirely in favor of Text-based Internet in that case) etc. Until/unless that happens, it's completely illusory to try to support the DVD. All it does is provide a very substandard and broken experience to our users. Now sure, Fedora is forced to do this sometimes because we don't have the manpower to backport all fixes ... As I said, we definitely don't have the manpower to backport all KDE bugfixes and I really don't think any distro in the world does. but there's a _big_ difference between being forced to do it some of the time and guaranteeing that the firehose breaks it _every_ release for _every_ user. But our policy is to stay close to upstream and we even recommend upgrading rather than backporting for security fixes. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Frank Murphy wrote: It's also called political licence No, it's not really the same thing. ;-) I didn't try to distort your viewpoint, just highlight the contradictions. But this time I'm replying in order. :-) If you mean these points from Mail Lists then yes. Yes, that's what I mean. The why\how is it a bug? Who decided? Handshake? Upstream? Whoever reported it there? If it's a bug and you (generic) know about it, please refrence it in bugzilla, even if only providing a link to upstream Bugzilla\Similar So I should file bugs against my own packages just to link to an already existing and already fixed upstream bug report? What kind of useless bureaucracy would THAT be? :-/ Thats what Bugzilla is for. If people so not report bugs, they should be educated to do so. Whether user\dev\packager\ etc.. No one is a mind reader. It doesn't take a mind reader to realize that an upstream BUGFIX release, well, FIXES BUGS! ;-) Semantics. You want embellishment go Rawhide. otherwise stick with Security\Bugs as updates. I don't think that's a good plan. Running Rawhide is NOT something an average user should have to do. A voluntary tester, sure, but not a user who just wants to use the system and needs the latest kernel, e.g. for his hardware to work. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Alexander Boström wrote: It could install a file in /etc/foo.d that causes something that loads /etc/foo.d/* to break. That's not automatic breakage, you'd still have to install the package (or get it installed through one of the already discussed mechanisms: Obsoletes, Provides collision, added dependency in another package) to get that breakage. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 01/03/10 11:17, Kevin Kofler wrote: Frank Murphy wrote: It's also called political licence No, it's not really the same thing. ;-) I didn't try to distort your viewpoint, just highlight the contradictions. But this time I'm replying in order. :-) If you mean these points from Mail Lists then yes. Yes, that's what I mean. The why\how is it a bug? Who decided? Handshake? Upstream? Whoever reported it there? Therefor whover reported it will know. If it's a bug and you (generic) know about it, please refrence it in bugzilla, even if only providing a link to upstream Bugzilla\Similar So I should file bugs against my own packages just to link to an already existing and already fixed upstream bug report? What kind of useless bureaucracy would THAT be? :-/ Well, I have to agree, if only you have the bug. If's it's an upstram bug, that affects more Fedora users than the packager then yes refrence it, Because most Fedora users will go redhat.bugzilla first to check for existing. Thats what Bugzilla is for. If people so not report bugs, they should be educated to do so. Whether user\dev\packager\ etc.. No one is a mind reader. It doesn't take a mind reader to realize that an upstream BUGFIX release, well, FIXES BUGS! ;-) It does if it fixes problems in Fedora, if it doesn't is it needed? Semantics. You want embellishment go Rawhide. otherwise stick with Security\Bugs as updates. I don't think that's a good plan. Running Rawhide is NOT something an average user should have to do. A voluntary tester, sure, but not a user who just wants to use the system and needs the latest kernel, e.g. for his hardware to work. On that I would agree. With the exception, that if the update fixes a problem he doesn't have, why should it be pushed on him. And package logs to the system user, well. Thats' where the description would come in handy. Links to bz are fine, but some updates at first glance, have no need to be pushed. No bz, nothing only it's got a new icon (etc.). -- Regards, Frank Murphy UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 11:47 +0100, Kevin Kofler wrote: Jon Masters wrote: One thing I would suggest being considered in an alternative proposal is a compromise policy for specific stacks or non-critical path packages. For example, if the standard policy affecting me as a GNOME user is that major changes will be confined to new releases (my very strong personal preference) then I don't personally much care if it is official policy that KDE is allowed an exception to rebase on some other schedule. Well, IMHO GNOME should get the same treatment KDE is already getting, but I don't care all that much about GNOME, so I could probably agree to such a compromise. Still, don't you want to run an actually maintained GNOME where bugs are still being fixed rather than being stuck with them forever? Does GNOME continue releasing bugfixes for the old branch after the new release? (KDE definitely doesn't.) GNOME has bug-fix releases (e.g. 2.28.1, 2.28.2, etc) and we do package those as updates for Fedora releases. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100301 changes
Compose started at Mon Mar 1 08:15:14 UTC 2010 Broken deps for i386 -- blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28 easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5 emotion-0.1.0.042-5.fc12.i686 requires libecore_job.so.0 emotion-0.1.0.042-5.fc12.i686 requires libevas.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_fb.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_x.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_txt.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_job.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libevas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_fb.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_file.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet_mime.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_con.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_ipc.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedbus.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libehal.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_x.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedje.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_evas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libedje.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet_mime.so.0 ewl-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_evas.so.0 gnome-python2-totem-2.29.1-4.fc13.i686 requires libtotem-plparser.so.12 gnucash-2.3.10-1.fc13.i686 requires libgoffice-0.8.so.7 koan-2.0.3.1-1.fc13.noarch requires mkinitrd linphone-2.1.1-4.fc12.i686 requires libortp.so.7 mrpt-apps-0.8.0-0.2.20100102svn1398.fc13.i686 requires libhighgui.so.4 mrpt-apps-0.8.0-0.2.20100102svn1398.fc13.i686 requires libcv.so.4 mrpt-apps-0.8.0-0.2.20100102svn1398.fc13.i686 requires libcxcore.so.4 mrpt-core-0.8.0-0.2.20100102svn1398.fc13.i686 requires libcxcore.so.4 mrpt-core-0.8.0-0.2.20100102svn1398.fc13.i686 requires libhighgui.so.4 mrpt-core-0.8.0-0.2.20100102svn1398.fc13.i686 requires libcv.so.4 openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas_hg.so.2 openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas.so.2 php-facedetect-1.0.0-3.fc13.i686 requires libcxcore.so.4 php-facedetect-1.0.0-3.fc13.i686 requires libhighgui.so.4 php-facedetect-1.0.0-3.fc13.i686 requires libcv.so.4 php-facedetect-1.0.0-3.fc13.i686 requires libcvaux.so.4 qmf-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel
Fight bugs, not FESCo
tl;dr version: Empower, rather than restrict, maintainers. Encourage them to test by increasing test accuracy, coverage, unique configurations, and visibility. I don't think FESCo wishes to destroy the freedom of package maintainers. I also don't think package maintainers want to release broken packages. I believe that both have acted and will continue to act in good faith. That being said, I'm not a package maintainer or a member of FESCo. I use updates-testing, test packages when I can, and report them when I can. I make no claim to be good at any of these. ;) That being said, here's what I propose: * Retain the current policy of deferring to maintainers (AKA: Thank god I don't run KDE) I, maybe naively, believe that maintainers know their packages best. If they believe their package should (and will) be tested, then they'll keep it in testing. If they believe it's stable, then I feel like that's their prerogative as maintainers. Maintainers know if their package is mission-critical, and they ought to base their decisions on that knowledge. Plus, if they push a bad patch, they'll remember it long after the rest of us forget. I don't think you can enforce this, though, for the following reasons: a.) Minimum values, whether time or karma, will either be too short for some or too long for others b.) Minimum values will not feasibly scale based on how risky a change is. A new feature may be riskier than a bugfix, but it might not. A policy will have difficulty accounting for this. c.) An override mechanism, such as an emergency meeting, a security flag, or approval by some third party, does not necessarily increase chances of correctness. A member of QA, FESCo, releng, etc. may not be familiar with a given package or a given patch. But I don't think we should stop here. I like the idea of changes being tested before they're shipped. It puts less burden on the maintainer to ensure his change is correct, and less risk since his change is exposed to a small sample before being widely distributed. Here's what I think we can do to encourage maintainers to test and release: * Minimize time spent in updates-testing, while not sacrificing quality Time spent in updates-testing incurs a cost on everyone. Users are forced to use a worse product, and maintainers get frustrated as their package stays unbroken or un-updated. But that's not even the worst thing about eating up time in updates-testing! The worst thing is this: it doesn't actually decrease the likelihood of bugs. Only passed tests do. What time gives you, is users. As time goes on, more users (presumably) use and test your package. But how many users have tested my package? Are they reporting, or just ignoring, bugs? Are they even testing the right things? The only indicators you have are time spent in updates-testing and karma comments. I believe these are either wrong or inaccurate measurements. Look at it this way: In a perfect scenario, every user of a package runs every test the moment it hits updates-testing. That means that a package only needs to stay in updates-testing for however long the package tests take. Barely any time at all! We don't live in an ideal world, though, but I think the formula looks something like this: Quality of Product = Quality of Testing Quality of Testing = Test Coverage * Number of Configurations Configurations are your users, and coverage is depth. Coverage is also accuracy: If I spend 30 minutes testing every preference even though you didn't change any preferences, then I just wasted my time on your package. The goal is to make tests easy and specific for the tester, and you'll find more testers and better test coverage. * Increase coverage through Bodhi As a tester, I love Bodhi. It shows me new things to test. If I have a list of bugs that were fixed in this build, they're all test-cases. If I have a changelog that shows features that were added, each change is a test-case. Unfortunately, if I have neither, then I can only really do a smoke test. Here's a few concrete ideas to encourage better coverage through Bodhi: - Allow test cases to be added to Bodhi. These already exist for the RCs, they could optionally be written by maintainers too. It doesn't have to be formal, though. Test the printing stuff is sufficient. - Integrate changelogs where available. Since these show what changed, testers can use them to be more efficient and thorough with their tests, increasing coverage. - Further integrate Bugzilla and Bodhi. If I'm able to see what bugs are open for a package through Bodhi, I can check if those bugs were affected by the build I'm testing. I could also see if a bug is already open for this build without having to search through Bugzilla, increasing my efficiency. - Tweak karma. I feel bad leaving negative karma and I shouldn't! Bug reports are healthy. Also, positive karma is rare and subjective. I think they should either be plain comments, or a per-user checkbox for a given test-case.
dual lived modules
Hello, I'd like to ask on your opinion on dual lived modules in our distro. I knew that Mandriva has the main perl package and also provide rpms of sub-packages, which are easier to update. They are using patch that allows them override the core modules. Also debian has perl core and sub-packages as separated modules. This question was raised again in [1]. I suppose there would be conflicts after every update of main perl package, which could complicate it. So I'd like to hear pros and cons on this issue. Thanks. [1] https://bugzilla.redhat.com/show_bug.cgi?id=569361 -- Marcela Mašláňová BaseOS team Brno -- 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: Impasse on packaging JOGL and Gluegen
On Sun, 2010-02-28 at 15:49 +0100, Hans de Goede wrote: On 02/28/2010 03:39 PM, Henrique Junior wrote: As Chen Lei said, the fact that JOGL needs this code may mean that it will be blocked forever for packaging, but I do not particularly see a big problem. For more details, please, read the log in bugzilla and give your ideas regarding this question. AFAIK we have had problems like this before with various bits of Xorg (iirc) needing the sources of other bits to build. The usual solution for this, is to give a package a -source subpackage, which contains the extracted sources (and installs them under /usr/src So I think the best way to handle this is to package gluegen, and include gluegen's sources as a gluegen-source subpackage, and then make jogl BuildRequire gluegen-source. Yeah, we did this for Mesa from FC5 through F9. Certainly not ideal, but such is life. I wouldn't consider this a blocker for packaging, though I'd like to see it fixed eventually. Usually when this kind of source build dependency exists it's not a trivial thing to fix. - 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: Directory ownership bugs
On Mon, Mar 01, 2010 at 03:57:06PM +0100, Jaroslav Reznik wrote: see bug footer - This is autogenerated bugzilla, I'm sorry if the problem is already fixed or reported. Additionally I apologize if that directory ownership was requested earlier by some bugzilla (some directories were probably added into filesystem package later, so your package should no longer own that directory). If it's already fixed - then feel free to close it. Yet the bug entry is missing important information, the NVR of the tested package and also IMHO this is not something that should checked in a stable release, but Rawhide or maybe branched-Rawhide, because this simple change does imho not justify a package update. Regards Till pgpS9oMTmDHpU.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 01:16:43PM +0100, Kevin Kofler wrote: I would like to collect feedback on this issue. If you want to disable direct stable pushes, why? Could there be a less radical solution to that problem (e.g. a policy discouraging direct stable pushes for some specific types of changes rather than a blanket ban)? On the other hand, if (like me) you DON'T want that feature to go away, please provide valid use cases. Stable pushes are useful for new packages, particularly non-core new packages. Also many, many packages get precisely no comments in Bodhi, even allowing for two weeks of so-called testing. In general, FESCo should trust packagers to do the right thing, and encourage people to test the packages in updates-testing and provide feedback to Bodhi. 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: Fight bugs, not FESCo
On Mon, Mar 01, 2010 at 03:48:15PM +0100, Thomas Janssen wrote: On Mon, Mar 1, 2010 at 3:22 PM, Aaron Faanes dafr...@gmail.com wrote: I agree to almost everything you wrote. snip - Allow maintainers to see number of downloads by users who have opted-in to share that data. If not number, then a simple range. snap *That* would be awesome. Because besides of bugs and some guys in IRC who tell you that they like the software you package, you have no feedback if your software is in use at all. Of course speaking of maintainers like me who owns not the big desktops. I have some smaller packages and the E17 chain. Debian has a thing called PopCon: http://popcon.debian.org/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fight bugs, not FESCo
Bruno Wolff III br...@wolff.to writes: A couple of problems. Which packages are downloaded from mirrors is not currently available to Fedora. [...] Would it be crazy to reorganize the mirror system in such a way that normally download http requests come to fedoraproject.org, but are redirected at the http-301 level to mirrors? That way, we'd get to keep logs of downloads, but not necessarily supply the actual bits? - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
perl-Nmap-Parser license changed from GPLv2+ to MIT
Whilst cleaning up some recently adopted orphans, I discovered that perl-Nmap-Parser has been tagged with the wrong license since August 2008. Upstream changed the license from GPLv2+ to MIT sometime back in 2007 and I've just corrected it in rawhide (and will do on all branches too in the near future). Presumably this isn't a problem for anyone since it's less restrictive now. -- Iain. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 2010-02-27 at 02:52 +0100, Kevin Kofler wrote: Adam Jackson wrote: By my count, that's three misrepresentations in one paragraph. I certainly hope they were not deliberate. I'm not deliberately misrepresenting anything or anyone, I just stated my perception of the facts. It may well be that I missed some details in the hectic and chaotic discussion. But you did not state your perception of facts. You stated your perception _as_ fact. And as a result, you generated yet more chaotic discussion. Nice work. A more parsimonious explanation is that Matthew's simply been busy the last few days and hasn't gotten around to it yet. Again, this may or may not be true, but Occam's Razor suggests it's more likely. The problem is, when will it be ready? If it's ready on Tuesday afternoon and the vote gets done on Tuesday evening, that's too short a notice to gather appropriate feedback. If it's ready on Tuesday afternoon, what makes you think anyone's going to have time to read it thoroughly enough to be able to vote on it? Are you implying you're the only one on fesco that actually considers the proposal they're asked to vote on? You create package A. Someone else has created package B, with a triggerin script on A, unbeknownst to you, and you don't have B installed. Your testing of A will not reflect the experience of anyone with B installed. B's triggerin script might rm -rf /, for example. Uh, why do we even allow triggers without explicit FESCo approval (including notification to the maintainers of the packages being triggered on)? They're much more dangerous than linking a static library or bundling a library! No disagreement here. But that's sort of my point. Packaging is subtle, and putting controls in place to minimize disruption for consumers is a broadly positive thing. We should be monitoring for new scriptlets and reviewing suspicious ones. We should also not skip updates-testing just because we think we're not going to break anything. Slipping through testing is itself the problem. It means that testers aren't using testing! We should fix the technical and UX problems that make testing hard to consume. Even if you fix all the fixable problems, testing will still not be a silver bullet! I didn't claim it would be. And I also don't see how that's relevant. I mean, your argument here is it doesn't matter how good our infrastructure for testing fixes is, it'll still not catch everything; therefore we should allow people to bypass it if they want. By that argument, no prophylactic is 100% effective against diseases, therefore people should be free to not use them if they don't want to. You're positing A = B here. A might be true. B might be true. They might both be true! But it's not at all clear that A implies B. If I had a dollar for every obviously correct one-line fix that broke something, I could probably quit this software game. X11 is particularly dangerous for this kind of changes, given how low it is in the software stack and how some code necessarily looks like (hardware drivers in particular are always scary stuff). The average leaf package is much less propice to breakage induced by minimal changes. While I understand the temptation to rank package importance and fragility by position in the dependency tree, remember that leaf packages are why people use the OS in the first place. No one runs Fedora just because they think coreutils is really neat. - 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, Mar 1, 2010 at 4:44 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Fri, Feb 26, 2010 at 01:16:43PM +0100, Kevin Kofler wrote: I would like to collect feedback on this issue. If you want to disable direct stable pushes, why? Could there be a less radical solution to that problem (e.g. a policy discouraging direct stable pushes for some specific types of changes rather than a blanket ban)? On the other hand, if (like me) you DON'T want that feature to go away, please provide valid use cases. Stable pushes are useful for new packages, particularly non-core new packages. Also many, many packages get precisely no comments in Bodhi, even allowing for two weeks of so-called testing. In general, FESCo should trust packagers to do the right thing, and encourage people to test the packages in updates-testing and provide feedback to Bodhi. Indeed. But maybe packaging (contributing) will be made that awful that people stop to continue. If there're some packagers, doing stupid or bad things, then remove them if they cant/wont learn to do it right. But IIRC that was already mentioned. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fight bugs, not FESCo
On Mon, Mar 1, 2010 at 4:59 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Mar 01, 2010 at 03:57:11PM +, Richard W.M. Jones wrote: On Mon, Mar 01, 2010 at 03:48:15PM +0100, Thomas Janssen wrote: On Mon, Mar 1, 2010 at 3:22 PM, Aaron Faanes dafr...@gmail.com wrote: I agree to almost everything you wrote. snip - Allow maintainers to see number of downloads by users who have opted-in to share that data. If not number, then a simple range. snap *That* would be awesome. Because besides of bugs and some guys in IRC who tell you that they like the software you package, you have no feedback if your software is in use at all. Of course speaking of maintainers like me who owns not the big desktops. I have some smaller packages and the E17 chain. Debian has a thing called PopCon: http://popcon.debian.org/ This might be a better link to see the sort of stats they are generating: http://popcon.debian.org/by_inst Thank you. Yes, that's something i had in mind. Very nice to have. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: perl-Nmap-Parser license changed from GPLv2+ to MIT
On Mon, 1 Mar 2010, Iain Arnell wrote: Whilst cleaning up some recently adopted orphans, I discovered that perl-Nmap-Parser has been tagged with the wrong license since August 2008. Upstream changed the license from GPLv2+ to MIT sometime back in 2007 and I've just corrected it in rawhide (and will do on all branches too in the near future). Presumably this isn't a problem for anyone since it's less restrictive now. Assuming the author asked all their contributors permission as well, if there were any. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: perl-Nmap-Parser license changed from GPLv2+ to MIT
On 03/01/2010 11:48 AM, Paul Wouters wrote: On Mon, 1 Mar 2010, Iain Arnell wrote: Whilst cleaning up some recently adopted orphans, I discovered that perl-Nmap-Parser has been tagged with the wrong license since August 2008. Upstream changed the license from GPLv2+ to MIT sometime back in 2007 and I've just corrected it in rawhide (and will do on all branches too in the near future). Presumably this isn't a problem for anyone since it's less restrictive now. Assuming the author asked all their contributors permission as well, if there were any. As a general rule, we assume upstream relicensing actions are done appropriately unless there is obvious evidence to the contrary. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 02/26/2010 08:55 AM, Kevin Kofler wrote: Michael Schwendt wrote: That would be a ridiculous decision. It would be much better to disable that feature only for those update submitters who really have been dilettantish enough to use it inappropriately more than once. Yeah, that's a good idea. We really need to avoid punishing everyone for the few incompetent maintainers who screw up! These constant insinuations that anybody who makes a mistake is incompetent are really starting to bug me. The idea isn't that we want to punish *anybody*. When you're at the circus watching the clown ride a bicycle across a high-wire, he's got a safety net. It's not because the circus thinks he's an incompetent high-wire cyclist - it's because people occasionally make mistakes, and the circus would rather have him around to do his act again when he falls. Fedora is no different; there are many very competent maintainers out there, and all of us will eventually make a mistake. These mistakes sometimes have repercussions that are fairly serious, and when they do, it's important that the safety net is already there. The goal of the discussion in FESCo is to make sure there's an adequate safety net, so that when maintainers make simple mistakes, they should have to deal with them - not with exponentially large consequences and 4am phone calls. Right now, the only proposal for doing so is to restrict what can be released without spending some time in testing. The discussion has included the concept of criteria for merit-based expedited testing, so if anything truly is urgent it can be *tested* and released quickly. Admittedly this needs to be fleshed out further. In this thread there's been some negative response and some support for the idea, and there's no clear winner. That said, what you've given us in response is strongly vitriolic, and frankly it's becoming tiresome. If you don't think the proposal is very good, that's fine - give us another one that attempts to accomplish the goal. You weren't elected FESCo Monitor; the guy who comes and tells the mailing list whenever FESCo is discussing something you think is scary. You were elected to FESCo because people thought you might have good ideas you could contribute. If you think this isn't the right way to provide a safety net for package maintainers - what is? -- Peter First things first -- but not necessarily in that order. -- The Doctor -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 03/01/2010 11:52 AM, Peter Jones wrote: If you think this isn't the right way to provide a safety net for package maintainers - what is? With the understanding that you're not specifically asking me that question, I'd say that I'd prefer to first try to automate checks for the most frequent update issues: * Causes broken deps * Breaks clean upgrade path between releases * Has ABI/API change (and is a Critical Path package) * Fails to pass any package specific sanity tests (as written by either the maintainer, QA, rel-eng, or qualified contributors) AutoQA has the potential to do this. I'd rather see energy and effort spent on taking out these low hanging fruit. If, after that, we're still having broken updates pushed directly to stable, then I'd be willing to consider a policy with an enforced delay in testing. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[OFF TOPIC] Brazil may be punished due to government support to Open Software
This is off topic, but important to open software developers supporters Brazil may be punished because government supports free software... IIPA is willing to put Brazil in the black list of copyrights because Federal State governments support free software. According to IIPA, by supporting free software it shows Brazil has an inadequate policy against violations on intellectual property. IIPA... its gangster supporters must be denounced now. Not only to local authorities but also to international organizations like the ICO. Full article (in Portuguese) can be found here: http://bit.ly/cxbqJO signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [OFF TOPIC] Brazil may be punished due to government support to Open Software
On Mon, 1 Mar 2010, Casimiro de Almeida Barreto wrote: This is off topic, but important to open software developers supporters Yes - this is definitely off-topic. Please do not continue this thread. Thank You. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 03/01/2010 05:52 PM, Peter Jones wrote: On 02/26/2010 08:55 AM, Kevin Kofler wrote: Michael Schwendt wrote: That would be a ridiculous decision. It would be much better to disable that feature only for those update submitters who really have been dilettantish enough to use it inappropriately more than once. Yeah, that's a good idea. We really need to avoid punishing everyone for the few incompetent maintainers who screw up! ... The goal of the discussion in FESCo is to make sure there's an adequate safety net, so that when maintainers make simple mistakes, they should have to deal with them - not with exponentially large consequences and 4am phone calls. Right now, the only proposal for doing so is to restrict what can be released without spending some time in testing. The issues that at least I have been trying to point out: * Is testing an adequate safety net? * Is karma an adequate means to assure quality * Is banning a direct pushes an adequate means to improve quality ? My answer to all: Neither of them are. The solution to actually improve quality are along the lines of * maintainers to acting more carefully and think twice about what they are pushing. * rel-eng to implement automated procedures to catch at least the worst mistakes (e.g. dep breakages, SONAME-breakages). Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 03/01/2010 11:57 AM, Tom spot Callaway wrote: On 03/01/2010 11:52 AM, Peter Jones wrote: If you think this isn't the right way to provide a safety net for package maintainers - what is? With the understanding that you're not specifically asking me that question, I'd say that I'd prefer to first try to automate checks for the most frequent update issues: * Causes broken deps * Breaks clean upgrade path between releases * Has ABI/API change (and is a Critical Path package) * Fails to pass any package specific sanity tests (as written by either the maintainer, QA, rel-eng, or qualified contributors) AutoQA has the potential to do this. I'd rather see energy and effort spent on taking out these low hanging fruit. If, after that, we're still having broken updates pushed directly to stable, then I'd be willing to consider a policy with an enforced delay in testing. I *absolutely* agree that we need something like autoqa to let maintainers know when they've made an error with the (relatively) simple things it can detect. I'd also like a policy in place to help us avoid situations like the recent dnssec unpleasantness. -- Peter RFC 882 put the dots in .com. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Peter Jones pjo...@redhat.com writes: [...] You weren't elected FESCo Monitor; the guy who comes and tells the mailing list whenever FESCo is discussing something you think is scary. [...] One need not be elected to do that. Anyone reading the public fesco irc logs may do the same without special dispensation. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100301 changes
Compose started at Mon Mar 1 09:15:14 UTC 2010 Broken deps for i386 -- anaconda-13.32-1.fc13.i686 requires python-urlgrabber = 0:3.9.1-5 blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28 doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5 edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0 fusecompress-2.6-3.fc12.i686 requires libboost_serialization-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_system-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_program_options-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_filesystem-mt.so.5 fusecompress-2.6-3.fc12.i686 requires libboost_iostreams-mt.so.5 gnome-python2-totem-2.29.1-4.fc13.i686 requires libtotem-plparser.so.12 koan-2.0.3.1-1.fc13.noarch requires mkinitrd libvirt-qpid-0.2.17-3.fc12.i686 requires qpidc = 0:0.5.790661 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 matahari-0.0.4-7.fc13.i686 requires qpidc = 0:0.5.819819 ovaldi-5.5.25-2.fc13.i686 requires libxerces-c.so.28 ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc qmf-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-rdma-0.5.819819-4.fc13.i686 requires qpidc-client-rdma = 0:0.5.819819-4.fc13 qpidc-server-ssl-0.5.819819-4.fc13.i686 requires qpidc-client-ssl = 0:0.5.819819-4.fc13 sugar-tamtam-common-0-0.3.20100201git.fc13.i686 requires sugar-tamtam = 0:0-0.3.20100201git.fc13 zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2 Broken deps for x86_64 -- anaconda-13.32-1.fc13.x86_64 requires python-urlgrabber = 0:3.9.1-5 blahtexml-0.6-5.fc12.x86_64 requires libxerces-c.so.28()(64bit) doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 doodle-0.6.7-5.fc12.x86_64 requires libextractor.so.1()(64bit) easystroke-0.5.2-1.fc13.x86_64 requires libboost_serialization-mt.so.5()(64bit) edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0 edje-0.9.9.050-6.fc12.x86_64 requires libembryo.so.0()(64bit) fusecompress-2.6-3.fc12.x86_64 requires libboost_system-mt.so.5()(64bit) fusecompress-2.6-3.fc12.x86_64 requires libboost_program_options-mt.so.5()(64bit) fusecompress-2.6-3.fc12.x86_64 requires libboost_iostreams-mt.so.5()(64bit) fusecompress-2.6-3.fc12.x86_64 requires libboost_filesystem-mt.so.5()(64bit) fusecompress-2.6-3.fc12.x86_64 requires libboost_serialization-mt.so.5()(64bit) gnome-python2-totem-2.29.1-4.fc13.x86_64 requires libtotem-plparser.so.12()(64bit) koan-2.0.3.1-1.fc13.noarch requires mkinitrd libvirt-qpid-0.2.17-3.fc12.x86_64 requires qpidc = 0:0.5.790661 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) matahari-0.0.4-7.fc13.x86_64 requires qpidc = 0:0.5.819819 ovaldi-5.5.25-2.fc13.x86_64 requires libxerces-c.so.28()(64bit) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc qmf-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qmf-devel-0.5.819819-4.fc13.x86_64 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-devel-0.5.819819-4.fc13.x86_64 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-rdma-0.5.819819-4.fc13.x86_64 requires qpidc-client-rdma = 0:0.5.819819-4.fc13 qpidc-server-ssl-0.5.819819-4.fc13.x86_64 requires qpidc-client-ssl = 0:0.5.819819-4.fc13 sugar-tamtam-common-0-0.3.20100201git.fc13.x86_64 requires sugar-tamtam = 0:0-0.3.20100201git.fc13 zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2 New package gource Software version control visualization New package libeina Data Type Library New package sugar-tamtam A suite of four music and sound related activities New package sugar-typing-turtle A multilingual animated touch typing trainer Updated Packages: PySolFC-2.0-2.fc13 -- * Mon Feb 22 2010 Stewart Adam s.adam at diffingo.com - 2.0-2 - Patch desktop file to use pysol and not pysol.py for exec - Force pygame as sound mod, makes PySolFC work with PulseAudio balsa-2.4.7-2.fc13 -- * Sat Feb 20 2010 Pawel Salek sa...@kth.se - 2.4.7-2 - add a gmime-2.5.1 port patch with gpgme support. * Sat Feb 13 2010 Pawel Salek sa...@kth.se -
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 03/01/2010 12:52 PM, Frank Ch. Eigler wrote: Peter Jones pjo...@redhat.com writes: [...] You weren't elected FESCo Monitor; the guy who comes and tells the mailing list whenever FESCo is discussing something you think is scary. [...] One need not be elected to do that. Anyone reading the public fesco irc logs may do the same without special dispensation. A fair point; I'd even encourage them to do so. In this paragraph, most of which has been omitted here, I was trying to solicit more of the *other* behavior. I'm not trying to say that bringing discussion to f-d-l is a bad thing; it's clearly not. -- Peter RFC 882 put the dots in .com. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 03/01/2010 12:48 PM, Peter Jones wrote: I'd also like a policy in place to help us avoid situations like the recent dnssec unpleasantness. Sure. I'm just not at all convinced that if those packages had sit in testing for $ARBITRARY_PERIOD_OF_TIME that they would have been tested and fixed. In EPEL, where there is a mandatory period of testing for updates, I almost never get Bodhi karma, and if I do, it is only because I have been aggressively harassing users to test and give karma. If there was an eager pool of qualified and able testers for all packages, I wouldn't blink at a forced delay for testing (that could be overridden by karma), but I don't think that exists. (I do think that such a pool could be built up with the proper deployment of intelligent and user-friendly tools, but I digress.) ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 569568] New: Please rev perl-RRD-Simple to latest release
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Please rev perl-RRD-Simple to latest release https://bugzilla.redhat.com/show_bug.cgi?id=569568 Summary: Please rev perl-RRD-Simple to latest release Product: Fedora Version: 13 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: perl-RRD-Simple AssignedTo: ska...@redhat.com ReportedBy: gbar...@redhat.com QAContact: extras...@fedoraproject.org CC: ska...@redhat.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Target Release: --- The latest release of perl-RRD-Simple is 1.44 released 24th Janurary 2008: http://search.cpan.org/~nicolaw/RRD-Simple/ The version included with Fedora 12 is 1.43 released 5th March 2007. Please included the latest version in upcoming fedora release -- 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
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 1 Mar 2010, Will Woods wrote: * Has ABI/API change (and is a Critical Path package) This should be handled by the current rpmguard test: https://fedorahosted.org/autoqa/wiki/rpmguard since changing the ABI/API should generally change the soname/version, thus changing the package Provides. Furthermore there's plans to actually diff the symbol tables themselves, for extra safety: https://fedorahosted.org/autoqa/ticket/75 tricky with accidental ABI/API breakage - like in the yum api, for example. So I think it would be shortsighted for FESCo to refuse to even discuss a policy about what manual testing is currently required, since any plan for improving the quality of the distribution will always require some amount of manual testing. agreed. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants a more sane updates policy (feedback requested)
Thankyou for starting all this hard work with the certainty that it *will* be blamed by some people. As an end User I extremely like that Fedora does not ban newer packages from Stable releases. At the same time I can see how direct pushes can sometimes create unforseen bugs. I however do not see both scenarios as mutually exclusive - even a tool issue may fix things - have an option to set have a default push to stable (offset) date and then packagers can fire away their packages, do their testing and forget about taking any other actions unless there is a need to fix some more bugs (or a security issue to force the date closer). Good luck. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fight bugs, not FESCo
For anyone who wants to attempt this, there is a very basic and seemingly abandonded popcon for rpm written in perl for opensuse at: http://gitorious.org/opensuse/popcorn (although gitorious.org seems down right now from here). I agree with Mike that you would really need to figure out a efficent way to store this data and/or cut way down on what it's reporting. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, 26 Feb 2010 16:59:40 -0500 (EST) Paul Wouters p...@xelerance.com wrote: On Fri, 26 Feb 2010, Kevin Fenzi wrote: A quicker way of seeing if a bug report was alread made, and more quickly being able to report bugs then spending 15-30 with bugzilla would help me in reporting more bugs. I like the automated crash reporting, though I'm not sure where they go, as I havent received a single report from them on any of my +/- 30 packages. http://bugz.fedoraproject.org/packagename Will show you a list of open bugs on a package. Oh, that is somewhat useful. Though I did not see a way in the interface to list all bugs in the packages I maintain. If I go to my packages then there is no bugs I can click except the generic one. Well, there is the bugzilla front page: https://bugzilla.redhat.com/frontpage.cgi Does that have the info you are looking for? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 13:01 -0500, Tom spot Callaway wrote: On 03/01/2010 12:48 PM, Peter Jones wrote: I'd also like a policy in place to help us avoid situations like the recent dnssec unpleasantness. Sure. I'm just not at all convinced that if those packages had sit in testing for $ARBITRARY_PERIOD_OF_TIME that they would have been tested and fixed. But that's mostly self-fullfilling, at the moment I doubt anyone keep up with the numbers of packages hitting updates ... so expecting people to keep up with that _and_ test a significant portion of updates-testing is just asking too much. It would also help if we cut down on the number of updates for each package, and had better update descriptions for each package. So I did my proposal, which I think will motivate packagers to do the right thing (giving lots of choice to the users and a reasonable number of packages to test) and not removing the ability of packagers to do what they want (and have the stable firehose): https://fedoraproject.org/wiki/Release_Lifecycle(draft)#Choice_.28james.29 -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, Mar 01, 2010 at 01:30:18PM -0500, Seth Vidal wrote: On Mon, 1 Mar 2010, Will Woods wrote: So I think it would be shortsighted for FESCo to refuse to even discuss a policy about what manual testing is currently required, since any plan for improving the quality of the distribution will always require some amount of manual testing. agreed. What kind of tests need to be done always manually? The only ones I can think are tests for the appearance of applications or tests that require specific hardware. But in the general case, I do not think that for every package manual testing will always be required, except while creating new automatic tests. E.g. if you have a library package with good unit test and behaviour test coverage and tests for RPM metadata, what do you want to test manually? Regards Till pgpblmGdpFSYu.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 1 Mar 2010 12:11:20 -0600 (CST) Mike McGrath mmcgr...@redhat.com wrote: On Mon, 1 Mar 2010, Tom spot Callaway wrote: On 03/01/2010 12:48 PM, Peter Jones wrote: I'd also like a policy in place to help us avoid situations like the recent dnssec unpleasantness. Sure. I'm just not at all convinced that if those packages had sit in testing for $ARBITRARY_PERIOD_OF_TIME that they would have been tested and fixed. In EPEL, where there is a mandatory period of testing for updates, I almost never get Bodhi karma, and if I do, it is only because I have been aggressively harassing users to test and give karma. This has been my experience too. While I like the ability to have a karma / feedback system. In reality it doesn't seem to actually be part of our package release workflow. I will note again that 0 karma doesn't mean that it's not been tested. I run here with updates-testing enabled, but often only report -karma when things break. There are just so many things in updates-testing, that I usually don't have time or energy to +1 all of them that work. I have reported -karma on about 4-5 things in the f12 cycle and also actively asked others to do so, preventing these things from being pushed, so I don't agree that updates-testing is not useful. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Thrashing between updates-testing and updates
Currently I am following F13 and I have been noticing a lot of packages disappearing from updates-testing before showing up in the branched release (but similar things happen with normal updates, just less often). When things disappear from updates-testing it isn't immediately obvious if this is because the updates are bad or because the update has been pushed to stable. Since I have a local mirror and the packages disappear between syncs, I end up downloading them twice. When stuff ends up having the same key regardless of testing status, this is especially wasteful. What I'd like to see is stuff stay in updates-testing for a while so that the hard link feature of rsync can be used to avoid downloading the data twice. And so that I don't get false alarms for stuff that may need to get downgraded. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 27 Feb 2010 22:45:12 +0100 Michael Schwendt mschwe...@gmail.com wrote: On Sat, 27 Feb 2010 13:17:43 -0800, Adam wrote: On Sat, 2010-02-27 at 20:18 +0100, Michael Schwendt wrote: Three times Could. Let's talk about it when you know something definite, please, but before it will become another hurdle. That's ironic - given that that's exactly what the people defending this proposal wanted to do, while it's someone who's opposed to the proposal who decided to start a premature argument about it. Then let's see this thread as the updates-testing push of a proposal FESCo might have given its blessing to, if this thread had not been started. Except it's more like a scratch build that someone built quickly, then decided that a more detailed approach was needed, so they didn't even submit an update. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 1 Mar 2010, Till Maas wrote: On Mon, Mar 01, 2010 at 01:30:18PM -0500, Seth Vidal wrote: On Mon, 1 Mar 2010, Will Woods wrote: So I think it would be shortsighted for FESCo to refuse to even discuss a policy about what manual testing is currently required, since any plan for improving the quality of the distribution will always require some amount of manual testing. agreed. What kind of tests need to be done always manually? The only ones I can think are tests for the appearance of applications or tests that require specific hardware. But in the general case, I do not think that for every package manual testing will always be required, except while creating new automatic tests. E.g. if you have a library package with good unit test and behaviour test coverage and tests for RPM metadata, what do you want to test manually? I have a series of basic functionality tests that I run before each yum release to make sure that there is nothing unforeseen in an update. I don't think such a set of tests is ridiculous, but I do admit it is complicated. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, Mar 01, 2010 at 13:16:09 -0500, Will Woods wwo...@redhat.com wrote: That's an interesting test case, actually. I'm not sure we currently check packages against the corresponding versions *other* releases. You'd want to also check obsoltess. Packages that are dropped without be obsoleted can also be a problem, as they can pin dependencies so as to block a yum update to a new release. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
OT: fas-username vs. local username for fedora-cvs
Hi all! My username on my private pc is josephine, my username on my workstation is josephine.tannhauser, but my fas-username is tannhauser. how can I use fedora-cvs on these machines? It seems that fedora-cvs want to use the local username. How can I change this behavior with editing a configfile in my home-dir? I don't want to edit the fedora-cvs package-files. Currently i have a alternate user on my private pc, but this is not a good solution. :-) -- Josephine Tannhäuser Fedora release 12 (Constantine) | 2.6.31.12-174.2.3.fc12.i686 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OT: fas-username vs. local username for fedora-cvs
On 03/01/2010 11:05 AM, Josephine Tannhäuser wrote: Hi all! My username on my private pc is josephine, my username on my workstation is josephine.tannhauser, but my fas-username is tannhauser. how can I use fedora-cvs on these machines? It seems that fedora-cvs want to use the local username. How can I change this behavior with editing a configfile in my home-dir? I don't want to edit the fedora-cvs package-files. Currently i have a alternate user on my private pc, but this is not a good solution. :-) From a glance at the source, it appears to get the username from the CN in ~/.fedora.cert -- so it should just work... Josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Tom spot Callaway (tcall...@redhat.com) said: * Causes broken deps * Breaks clean upgrade path between releases * Has ABI/API change (and is a Critical Path package) Actually, I'd say that any ABI change should block a stable push until it's fixed, period - critical path or not. If someone thinks their ABI change is that important in a stable release, then they need to chip in to fix all the users thereof. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 1 Mar 2010, Bill Nottingham wrote: Kevin Kofler (kevin.kof...@chello.at) said: For most bugfixes, the user doesn't notice at all. When a user gets a bugfix on something they've hit, they think oh, that's nice, Fedora fixed it, but they don't really care whether it cam Monday or Friday. For every regression they hit, they think ARRGH, this Fedora crap. All I did is update and now it's broken and I can't do what I want! The impact on the user's productivity and attitude isn't the same, and they can't be treated the same. One thing to consider: while from a psychological standpoint, a regression is indeed perceived as much worse than an unfixed bug, from a technical / practical standpoint it's actually the smaller issue: you can rollback to the version of the package before the regression, you can't rollback an unfixed bug as there's nothing to roll back to! Given that we don't provide an easily accessible user-friendly rollback mechanism, I don't know that that's actually applicable to the general case, though. yum history undo works pretty well. Not flawless, to be sure - but it's not bad for the simple-ish cases. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 03/01/2010 11:46 AM, Seth Vidal wrote: One thing to consider: while from a psychological standpoint, a regression is indeed perceived as much worse than an unfixed bug, from a technical / practical standpoint it's actually the smaller issue: you can rollback to the version of the package before the regression, you can't rollback an unfixed bug as there's nothing to roll back to! Given that we don't provide an easily accessible user-friendly rollback mechanism, I don't know that that's actually applicable to the general case, though. yum history undo works pretty well. Not flawless, to be sure - but it's not bad for the simple-ish cases. I think the yum-history-undo is great when I just want to try out a new package -- install something with all dependencies, try it, and then I can easily remove everything that was just installed. But for rolling back an update, yum requires that the old package is still available. We only keep the very latest version in the updates, so unless your previous version was from the initial release, you're out of luck. My last yum-update hit 19 packages, and only 7 can be downgraded by yum-history-undo. Josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OT: fas-username vs. local username for fedora-cvs
mån 2010-03-01 klockan 20:13 +0100 skrev Till Maas: But I wonder, how do you access CVS without this? You shouldn't need it. What happens if you don't have it? CVS records the root location in the checked out copy, so you only need to supply a CVS root when doing cvs checkout and even then you don't need to set CVSROOT, you can just do cvs -d :ext:f...@bar:/baz checkout gazonk. The fedora-cvs tool does set CVSROOT but it could just as well use -d instead. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OT: fas-username vs. local username for fedora-cvs
On Mon, Mar 01, 2010 at 09:09:08PM +0100, Alexander Boström wrote: mån 2010-03-01 klockan 20:13 +0100 skrev Till Maas: But I wonder, how do you access CVS without this? You shouldn't need it. What happens if you don't have it? It still seems to work. :-) CVS records the root location in the checked out copy, so you only need to supply a CVS root when doing cvs checkout and even then you don't Just wondering, can I also make CVS record which CVS_RSH to use? For Fedora I use a special one to keep the SSH connection open to speed up things[0]. It probably works for other CVS projects, too, but luckily I do not need to use any currently. need to set CVSROOT, you can just do cvs -d :ext:f...@bar:/baz checkout gazonk. The fedora-cvs tool does set CVSROOT but it could just as well use -d instead. Thanks, I did not know about fedora-cvs before, which also explains my previous mail to this thread. :-) Regards Till [0] http://blogs.23.nu/till/2008/12/ssh-via-cvs-with-automatic-control-socket-support/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
James Antill wrote:
The current state of play is (taking a random kde example):
kdeutils F11 GA 4.2.2-4.fc11
kdeutils F11 Updates 4.4.0-1.fc11
kdeutils F12 GA 4.3.2-1.fc12
kdeutils F12 Updates 4.4.0-1.fc12
...so if someone tries to update from F11 (with updates) using an F12 GA
release DVD, it'll be an older version and I very much doubt you've
tested how well that works.
Poorly :-). Though KDE is far from the only problem, and that particular
upgrade didn't go nearly as bad as when I tried to go from F10+updates
to F11 (somewhat after F12 had been released).
Upgrading from {Fn with updates} to {Fn+1 without updates} is just plain
broken. That's why I usually do upgrades via yum; they tend to work better.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Person A: It's an ISO standard.
Person B: ...And that means what?
-- mal (http://theangryadmin.blogspot.com/2008/04/future.html)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for tomorrow's (2010-03-02) FESCo meeting
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 20:00UTC (3pm EST) in #fedora-meeting on irc.freenode.net. Followups: None. New Business: #343 cloture rule/procedure for fesco meetings #344 Policy proposal: contributing to Fedora should be FUN Fedora Engineering Services Tickets/Discussion https://fedorahosted.org/fedora-engineering-services/ assigned tickets / status update: #2 SIGs roundup and pinging - jds2001 #8 Document Fedora as android devel platform - stickster unassigned tickets: #4 tool idea: script to evaluate buildroot poisoning #5 Fix broken dependencies #6 Fix packages that fail to build from source #7 spec cleanup task: fix the need for perl (etc) in scriptlets Open Floor For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Kevin Kofler wrote: 1. upgrades which disrupt, regress or break things. Those can only be pushed to Rawhide, if at all. Such as KDE 4.4, just to pick a recent example. I had to log out and log in again before I could start Kmail again. That can be quite disruptive if I have long-running processes that shouldn't be interrupted. And since the KDE upgrade I get popups when I log in about something called Akonadi that doesn't work because something called Nepomuk isn't running. I have no idea what that is but apparently something broke. Björn Persson 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 12:06 -0800, Josh Stone wrote: But for rolling back an update, yum requires that the old package is still available. We only keep the very latest version in the updates, so unless your previous version was from the initial release, you're out of luck. My last yum-update hit 19 packages, and only 7 can be downgraded by yum-history-undo. It's still not really usable by normal users, but people on this list can install yum-plugin-local ... which will make sure you can do downgrades like this. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 1 Mar 2010, James Antill wrote: On Mon, 2010-03-01 at 12:06 -0800, Josh Stone wrote: But for rolling back an update, yum requires that the old package is still available. We only keep the very latest version in the updates, so unless your previous version was from the initial release, you're out of luck. My last yum-update hit 19 packages, and only 7 can be downgraded by yum-history-undo. It's still not really usable by normal users, but people on this list can install yum-plugin-local ... which will make sure you can do downgrades like this. in exchange for an arseload of diskspace. just in the interest of complete disclosure. :) -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 1 Mar 2010, Bill Nottingham wrote: Seth Vidal (skvi...@fedoraproject.org) said: Given that we don't provide an easily accessible user-friendly rollback mechanism, I don't know that that's actually applicable to the general case, though. yum history undo works pretty well. Not flawless, to be sure - but it's not bad for the simple-ish cases. Sure, but we don't expose that for the case of I just installed security updates and Thunderbird is crashing - how do I fix it? Of course, that's nowhere near a trivial thing to implement well. I guess something like having the crash catcher look up the last update transaction is going to be fraught with no-fun for the user. would be handy debug data, though: The following pkgs were updated most recently prior to this crash... -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Data-JavaScript-1.13.tgz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Data-JavaScript: 14a2e422d2a22d34749e762614b4736f Data-JavaScript-1.13.tgz -- 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: creating file in koji allowed?
On Thu, 25 Feb 2010 22:29:21 +0100 Thomas Spura spur...@students.uni-mainz.de wrote: Is it allowed to create a file ~/.mpd.conf, when building in koji and deleting afterwards? I need to write down a password into that file, for running a testsuite. If that file does not exist, I can't run mpich2 tests. How does the technique of just setting HOME like mkdir mytemphome cd mytemphome echo STUFF .mpd.conf export HOME=$PWD fail to work for this case? The mpich2 source code suggests this should work. In any case, I would consider it very bad practise for package builds or package tests to write into $HOME/.any.file. -- Hans Ulrich Niedermann -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Björn Persson wrote: Kevin Kofler wrote: 1. upgrades which disrupt, regress or break things. Those can only be pushed to Rawhide, if at all. Such as KDE 4.4, just to pick a recent example. I had to log out and log in again before I could start Kmail again. That can be quite disruptive if I have long-running processes that shouldn't be interrupted. And since the KDE upgrade I get popups when I log in about something called Akonadi that doesn't work because something called Nepomuk isn't running. I have no idea what that is but apparently something broke. In my experience, *any* change to KDE can require a session restart. This seems to be a generic problem with the KDE infrastructure. Therefore, by your logic, no KDE updates should be issued, ever. (Of course, I also run KDE trunk, which tends to exacerbate this issue.) Even more so, no Firefox updates should ever be pushed because those seem to /always/ break existing Firefox sessions. If you aren't willing to risk that you might need to log out, /don't run updates/. Ironically, the kernel is probably the safest thing to update without rebooting :-) (being a rare case where the old one doesn't get replaced). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Person A: It's an ISO standard. Person B: ...And that means what? -- mal (http://theangryadmin.blogspot.com/2008/04/future.html) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 02/26/2010 08:00 PM, Jesse Keating wrote: On Sat, 2010-02-27 at 01:40 +0100, Kevin Kofler wrote: Bill Nottingham wrote: While the ethos as defined on the wiki mentions staying close to upstream and getting the latest software, there's nothing that says that it's done via updates. I would not categorically state that your reading is the only valid reading, or even close to the canonical one. In fact, the wiki implies that this is done via the rapid release cycle, not updates. It may not be strictly codified, but in practice it is a big part of what Fedora is and many users choose it for that. And it is also the main technical difference between us and Ubuntu. (I know there's also the licensing stuff, like Ubuntu bundling proprietary drivers, but that's not that big a difference in practice, it's not like those drivers cannot be easily removed (or added, yuck!).) Kevin Kofler You keep speaking, authoritatively, about what Fedora is. As of yet, I haven't seen anything from our leadership that would agree with your statements. To be pedantic, Fedora is what it is. What the leadership has to say doesn't really matter in terms of what Fedora *is*, only in terms of what Fedora is *supposed to be*. In order to know what Fedora really is, a person would need to look over the updates that have been pushed to F-11 and F-12 and compare those to what's in rawhide and maybe F-13 and see if wholesale package updates are being reserved for rawhide or if wholesale updates are being pushed on down into the stable releases. At that point you would know for sure what Fedora is, not what it's supposed to be. I say this because, obviously, different people read the part about First differently and do different things. -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 02/26/2010 08:52 PM, Kevin Kofler wrote: Adam Jackson wrote: By my count, that's three misrepresentations in one paragraph. I certainly hope they were not deliberate. I'm not deliberately misrepresenting anything or anyone, I just stated my perception of the facts. It may well be that I missed some details in the hectic and chaotic discussion. A more parsimonious explanation is that Matthew's simply been busy the last few days and hasn't gotten around to it yet. Again, this may or may not be true, but Occam's Razor suggests it's more likely. The problem is, when will it be ready? If it's ready on Tuesday afternoon and the vote gets done on Tuesday evening, that's too short a notice to gather appropriate feedback. Do you seriously not understand how FESCo works? If it's not ready by tomorrow when we discuss it, we'll delay discussion again, since that's the only practical thing to do. You create package A. Someone else has created package B, with a triggerin script on A, unbeknownst to you, and you don't have B installed. Your testing of A will not reflect the experience of anyone with B installed. B's triggerin script might rm -rf /, for example. Uh, why do we even allow triggers without explicit FESCo approval (including notification to the maintainers of the packages being triggered on)? They're much more dangerous than linking a static library or bundling a library! Other corner cases where your case was wrong include new packages that Obsolete existing packages. Slipping through testing is itself the problem. It means that testers aren't using testing! We should fix the technical and UX problems that make testing hard to consume. Even if you fix all the fixable problems, testing will still not be a silver bullet! Nobody is saying that it is! Merely that it's better than not having testing! If I had a dollar for every obviously correct one-line fix that broke something, I could probably quit this software game. X11 is particularly dangerous for this kind of changes, given how low it is in the software stack and how some code necessarily looks like (hardware drivers in particular are always scary stuff). The average leaf package is much less propice to breakage induced by minimal changes. This is just plain bull. High level packages also have one line fixes that are simple, elegant, and wrong. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 16:51 -0500, Doug Ledford wrote: To be pedantic, Fedora is what it is. What the leadership has to say doesn't really matter in terms of what Fedora *is*, only in terms of what Fedora is *supposed to be*. In order to know what Fedora really is, a person would need to look over the updates that have been pushed to F-11 and F-12 and compare those to what's in rawhide and maybe F-13 and see if wholesale package updates are being reserved for rawhide or if wholesale updates are being pushed on down into the stable releases. At that point you would know for sure what Fedora is, not what it's supposed to be. I say this because, obviously, different people read the part about First differently and do different things. Right, there are obviously people who feel that what Fedora Is is broken. The status quo isn't working, and that's why FESCo or members of FESCo are trying to come up with ways to fix that. A lot of the argument here seems to be disagreement about what Fedora Should Be, which is precisely an issue the Fedora board has been struggling with. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, 2010-02-27 at 10:16 -0700, Orion Poplawski wrote: On 2/27/2010 5:05 AM, Kevin Kofler wrote: Orion Poplawski wrote: There is plenty of room for something in between your vision of Fedora and CentOS. But that room is filled by other distros, such as Ubuntu. Why do we need to be another Ubuntu? It's not filled by Ubuntu, because Ubuntu is not Fedora. Fedora has the vision that is the most in line with mine, except for the frequent update, which so far I have been willing to put up with. But frequent updates is *not* why I've thrown my hat in with Fedora (sorry :). - Orion Ubuntu is not the first to pick up technology in their releases either. They generally wait for Fedora to ship with it first and work out all the kinks, then they snap it run with it. So I really don't buy the but then we'd be Ubuntu argument, at all. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: creating file in koji allowed?
Am Montag, den 01.03.2010, 22:40 +0100 schrieb Hans Ulrich Niedermann:
On Thu, 25 Feb 2010 22:29:21 +0100
Thomas Spura spur...@students.uni-mainz.de wrote:
Is it allowed to create a file ~/.mpd.conf, when building in koji and
deleting afterwards?
I need to write down a password into that file, for running a
testsuite. If that file does not exist, I can't run mpich2 tests.
How does the technique of just setting HOME like
mkdir mytemphome
cd mytemphome
echo STUFF .mpd.conf
export HOME=$PWD
fail to work for this case? The mpich2 source code suggests this should
work.
In any case, I would consider it very bad practise for package builds
or package tests to write into $HOME/.any.file.
/me too... That's why I asked here on the list, if this is even allowed,
but according to the guidelines it is.
See:
https://fedoraproject.org/wiki/Packaging/Guidelines#Scriplets_are_only_allowed_to_write_in_certain_directories
Now, I try to do:
'''
# create mpd.conf
export MPD_CONF_FILE=mpd.conf
echo MPD_SECRETWORD=$(pwgen -s 50 1) mpd.conf
chmod 600 mpd.conf
%{runtests}
# delte mpd.conf again
rm mpd.conf
unset MPD_CONF_FILE
'''
This way it should have the same effect like your proposal, but
unfortunately mpich2 is currently a bit misbehaving in the buildsystem
and this can only be run localy (with rpmbuild or mock).
There seems to be some DNS problems, which are expected in the
buildsystem, but not worked around with mpich2 :(
Now I run the tests locally and disable them in the buildsys till mpich2
fixes that. (Sorry, currently I didn't look much further into this.)
Thanks for your suggestion.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 09:44 +0100, Jaroslav Reznik wrote: One problem of updates-testing is - it takes so much time to be pushed and then mirrored. More rawhide approach should be used here. Users who are really interested in testing usually downloads from Koji directly. We do pushes daily, and in the case of 13, often twice a day. How much quicker do you want it? That's already as good, and better than how fast rawhide pushes. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 01:27 +0100, Kevin Kofler wrote: Adam Williamson wrote: It seems like extra work for packagers, but in the end it kinda takes the pressure off: you only *have* to ship the important fixes to /updates, /backports is optional, That's already a bad thing, users can no longer expect anything, it depends on the maintainer being willing to do a backport. They can't expect anything currently either. We have no project-wide commitment to what kind of updates we will ship. Some maintainers ship version updates, some don't. There's already no consistency; this wouldn't make things any worse. Now I know our current policy isn't any better, Whoops =) pre-empted. but that's why I think we should more strongly encourage upgrades to stable releases. Wasn't it your side of the argument who was arguing against telling maintainers what to do, and saying it should be 'fun' to contribute to Fedora? If going through a testing process before shipping an update is sufficiently 'unfun' to be a problem, surely being required to ship updates you do not believe should be shipped is in the same boat? Not that I disagree the situation should be less unpredictable than it is at the moment, but I don't see why *one* solution to this (make updates slightly more cautious) is a terrible imposition on maintainers, but another (make all updates more adventurous) is not. Yet, in practice, I still think a lot more stuff gets backported in our updates repository than in those backports repositories of other distros. Probably true (though in the case of Mandriva, maybe less than you'd expect; it's nothing like the wasteland that is Ubuntu backports). What's your point? Also because the maintainers don't have to worry about a conservative updates stream at the same time. Er, yes they do. That's precisely what Mandriva has - twin streams, one stable update stream, one backport stream. All maintainers are required to provide stable updates for packages in /main. They can *choose* to provide /backports upgrades too, but that doesn't absolve them of doing a safe /updates stream. Having both, we'd have to fix bugs in the conservative updates AND push backports. Again, Mandriva's been doing this for years, with a substantially smaller maintainer base, without it being a problem. Obviously the system isn't perfect, no system is; sometimes version bumps just go through as updates because it's way too much work to maintain a seventeen month bugfix backport list. But most of the time it works as advertised, and has a record of causing fewer problems for users of stable releases than the Fedora updates system has. Of course that'd tempt maintainers to just skip the backports step. Whereas our policy is to prefer resolving issues by pushing new upstream releases Er, is it? I thought we were discussing the fact that we don't *have* an updates policy. That may be the KDE SIG's policy, but it's not Fedora's, as far as I know. Upgrading basically gives us the bugfixes for free (in fact I usually just need to copy the specfile from devel to F-13, F-12 and F-11 and build for all). Many instances have shown that it does not give us the bugfixes 'for free'. It comes with the cost of causing regressions. That may be a cost which we decide we want to bear, but portraying things in a Panglossian manner doesn't help your cause, as it just makes you look like you're denying there could ever possibly be any problems with your method. and /backports users are good about knowing that sometimes what they find there will be broken or have new bugs or whatever, and tend to know the drill about not getting too upset and reporting them to you to be fixed. That also sucks. With Fedora's KDE updates, users can be sure that they'll be as regression-free as humanely possible and we do all we can to keep their updates stable. Which means...when they notice something's broken they let you know, and you fix it. What's the difference? Or are you seriously telling us you're perfect, and there's never been any problem in any KDE update? Your little 'as humanly possible' disclaimer suggests you're not really saying that, but you could've made it more obvious. On the other hand, users of distros using the backports model just get told backports are unsupported. No, they don't. please don't misrepresent my words. That's not what I said at all. What they get told is 'well, backports are unsupported - as you know anyway because we spread that message very well and people know what they're getting into - but give me some information and I'll do my best to fix it'. Which usually happens. In fact their builds of new KDE releases tend to carry only the same old distro patches as the old version or even to be entirely vanilla, very little is done to e.g. backport regression fixes from the branch. And KDE is just the example I'm most familiar with, I'm pretty sure it's similar with
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 08:07 +0100, Ralf Corsepius wrote: So yeah, I agree it's not a perfect system - detailed suggestions for improving it would be welcome, I'm sure. Alternatives: * Abandon it (I don't think this would change anything wrt. to QA in Fedora) Um. Hard to put this tactfully. You're completely wrong. Being actually *in* QA I have quite a lot of experience with this, and the Bodhi system has already stopped lots of broken updates being shipped. Throwing it out would be insane. * Replace it by a free text comment system Well, right now you have the choice of looking at the numbers or just ignoring them and reading the text (whether to auto-push a release with a given positive karma is a decision made by the maintainer when pushing a package, remember, it's not written into Bodhi; so you can choose to ignore the votes entirely if you like). Doing this would give you a choice of just reading the text or...just reading the text. Doesn't seem like an improvement :) * In cases an update is trying to address a particular bug in BZ, replace let people comment in bugzilla. You mean, let people check a box to have their comment from Bugzilla put into Bodhi? That would be nice, yep. I don't know how difficult it is from an infrastructure POV. Good idea, though. All the voting/karma stuff does is to let rel-eng believe to be dealing with bad updates, while it actually doesn't cope with the problems it is trying to address, it's the wrong tool. As I said, I just disagree. I have seen many cases where updates that otherwise would have gone out and caused real pain to real people have been caught by Bodhi. The fact that some weren't caught by Bodhi doesn't mean it's useless. I think it's pretty easy to make a case that Bodhi has had a significant positive impact on the overall quality of the updates that have fully utilized it. Well, the only positive impact bodhi had on me was bodhi implementing a more or less usable web-frontend, where Fedora had nothing in place before. This doesn't mean it is a good system and even less does this mean this system is perfect or bug-free. Didn't I just get done saying it's not perfect or bug-free, but that doesn't mean the sensible answer is to burn it down? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 12:17 +0100, Kevin Kofler wrote: It doesn't take a mind reader to realize that an upstream BUGFIX release, well, FIXES BUGS! ;-) They also often shovel in entirely non-related changes on the basis that they're perfectly obvious and trivial and simple changes that Can't Possibly Go Wrong. As noted, we in QA and Rel-eng have an entertaining file on all the ways in which things that Can't Possibly Go Wrong have, historically, gone wrong all over the carpet. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bodhi karma feature request
Split off from the stable pushes in Bodhi thread just because I'd like to see it not get lost. On 02/27/2010 11:35 AM, Mail Lists wrote: On 02/27/2010 11:27 AM, Adam Williamson wrote: On Sat, 2010-02-27 at 10:57 +0100, Ralf Corsepius wrote: Yeah, it's not perfect: there are cases where we have, say, a complex kernel update which works fine for most people but causes a significant regression for some particular bit of hardware. We wouldn't want to put that update out, but it's easy for it to get five +1s before someone with the specific bit of hardware comes by and gives it a -1...and even then, +4 looks good if you're not reading the feedback too carefully. One could argue that the current bodhi karma system is simply too simplistic for real use cases. Maybe instead of just +1 -1, there should be: Fixes my problem Works for me (someone testing that didn't necessarily have any of the problem supposedly fixed by this update just noting that their system still works ok with the update) Doesn't fix my problem (but doesn't necessarily imply it's any worse than before) Causes new problems (which should, IMO, be an automatic veto of any push to stable, requiring intervention to override) I could see situations where you would want to push updates to stable if say the update was supposed to solve multiple bugs, but turns out it only solves a subset of those bugs and doesn't cause new ones, so you would have some FMP, maybe some WFM, some DFMP, but no CNP. You'd probably just need to leave it up to the maintainer to decided if the bugs that are solved are important enough to push to stable before respinning another attempt at the ones that weren't solved. I've personally seen situations where this would be helpful with the mdadm package when I had 5 or 6 bugs on a single update and only 4 of them were actually solved. The update was still worth pushing while I worked on the others again. If you really wanted to get fancy, the FMP/DFMP options could be tied to specific bugzillas reported against the update, and if you get a FMP for each bugzilla listed in the update, plus at least 1 WFM, then you could automatically push to stable. Would be much better than the 3 random +1s you get now that don't indicate anything about test coverage or anything like that. Also FMP/DFMP karma against a bug could be noted both in the bodhi ticket as well as in the bug itself with a resultant VERIFIED/FAILS_QA toggle to the bug status. -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Thrashing between updates-testing and updates
On Mon, 2010-03-01 at 12:42 -0600, Bruno Wolff III wrote: Currently I am following F13 and I have been noticing a lot of packages disappearing from updates-testing before showing up in the branched release (but similar things happen with normal updates, just less often). When things disappear from updates-testing it isn't immediately obvious if this is because the updates are bad or because the update has been pushed to stable. Since I have a local mirror and the packages disappear between syncs, I end up downloading them twice. When stuff ends up having the same key regardless of testing status, this is especially wasteful. What I'd like to see is stuff stay in updates-testing for a while so that the hard link feature of rsync can be used to avoid downloading the data twice. And so that I don't get false alarms for stuff that may need to get downgraded. That's going to be pretty difficult to do with the way our push and sync scripts work. At most an update that is going from testing to stable should disappear for only a few hours, that would be between the updates-testing push of the day an the subsequent branched compose each night. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 11:57 -0500, Tom spot Callaway wrote: On 03/01/2010 11:52 AM, Peter Jones wrote: If you think this isn't the right way to provide a safety net for package maintainers - what is? With the understanding that you're not specifically asking me that question, I'd say that I'd prefer to first try to automate checks for the most frequent update issues: * Causes broken deps * Breaks clean upgrade path between releases * Has ABI/API change (and is a Critical Path package) * Fails to pass any package specific sanity tests (as written by either the maintainer, QA, rel-eng, or qualified contributors) AutoQA has the potential to do this. I'd rather see energy and effort spent on taking out these low hanging fruit. If, after that, we're still having broken updates pushed directly to stable, then I'd be willing to consider a policy with an enforced delay in testing. As I mentioned earlier in the thread, Kamil Paral is already working on exactly this in AutoQA, and would no doubt welcome volunteers of assistance on the autoqa-devel mailing list. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 18:33 +0100, Ralf Corsepius wrote: Right now, the only proposal for doing so is to restrict what can be released without spending some time in testing. The issues that at least I have been trying to point out: * Is testing an adequate safety net? * Is karma an adequate means to assure quality * Is banning a direct pushes an adequate means to improve quality ? My answer to all: Neither of them are. They are components in the net. The solution to actually improve quality are along the lines of * maintainers to acting more carefully and think twice about what they are pushing. As Peter said, people *always* make mistakes. No matter how hard they try, no matter how hard they think about it. It is in the nature of people that this will happen. You can't code it out of the wetware by telling people to be really, really careful. To make another analogy, if you're in the lab handling some incredibly noxious chemical substance, you are (if you're a good scientist) very, very, *very* careful. You also are wearing big gloves and safety goggles...because you know no-one is ever perfectly careful. * rel-eng to implement automated procedures to catch at least the worst mistakes (e.g. dep breakages, SONAME-breakages). We're working on this, as I've said several times. But why does it preclude other components in the safety net? Automated tests can never catch everything. The major problems that have occurred in updates in the past have not always been things that are amenable to automated testing. Just as people will *always* make mistakes, machines will *never* be able to catch all problems. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 567120] perl-Set-Scalar: please update to v1.25 and create EPEL branches
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=567120 --- Comment #5 from Jose Pedro Oliveira j...@di.uminho.pt 2010-03-01 17:47:38 EST --- Spot, Could you build perl-Set-Scalar for EPEL5? The EL-5 branch has already been created by Jason. tia, jpo -- 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
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 00:58 +0100, Kevin Kofler wrote: 1. upgrades which disrupt, regress or break things. Those can only be pushed to Rawhide, if at all. (Sometimes it might be better to not push a change even to Rawhide.) 2. upgrades which do none of the above. Those are what adds value to stable releases and pushing those is a good thing. It provides value which no other major distribution is providing, at least not those with numbered releases. And without using some sort of repository for users to test things and provide feedback, how do you propose we distinguish between the two sets of updates there? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 16:16 -0500, Seth Vidal wrote: in exchange for an arseload of diskspace. just in the interest of complete disclosure. :) Would that be 'an arseload of diskspace in /var, which everyone always forgets to make big enough'? :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi karma feature request
Doug Ledford wrote: One could argue that the current bodhi karma system is simply too simplistic for real use cases. Maybe instead of just +1 -1, there should be: Fixes my problem Works for me (someone testing that didn't necessarily have any of the problem supposedly fixed by this update just noting that their system still works ok with the update) Doesn't fix my problem (but doesn't necessarily imply it's any worse than before) Causes new problems (which should, IMO, be an automatic veto of any push to stable, requiring intervention to override) I was thinking that negative karma really ought to count as -5 instead of -1, but I like this suggestion a lot better. I'd vote for it (if I could legally vote :-( ). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Person A: It's an ISO standard. Person B: ...And that means what? -- mal (http://theangryadmin.blogspot.com/2008/04/future.html) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi karma feature request
On Monday, 01 March 2010 at 23:34, Doug Ledford wrote: [...] One could argue that the current bodhi karma system is simply too simplistic for real use cases. There's nothing to argue. It's rather obvious. :) Maybe instead of just +1 -1, there should be: Fixes my problem Works for me (someone testing that didn't necessarily have any of the problem supposedly fixed by this update just noting that their system still works ok with the update) Doesn't fix my problem (but doesn't necessarily imply it's any worse than before) Causes new problems (which should, IMO, be an automatic veto of any push to stable, requiring intervention to override) Great choices. This covers all bases, I think. I could see situations where you would want to push updates to stable if say the update was supposed to solve multiple bugs, but turns out it only solves a subset of those bugs and doesn't cause new ones, so you would have some FMP, maybe some WFM, some DFMP, but no CNP. You'd probably just need to leave it up to the maintainer to decided if the bugs that are solved are important enough to push to stable before respinning another attempt at the ones that weren't solved. This is an excellent idea, and big improvement over current purely numeric karma system in bodhi. +1 to implementing that. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Incompatible upgrade - Is this workaround ok? (mysql-mmm)
On Feb 26, 2010, at 11:11 AM, Kevin Fenzi wrote:
On Wed, 24 Feb 2010 12:36:31 -0600
BJ Dierkes wdier...@5dollarwhitebox.org wrote:
Hello all,
I maintain Multi-Master Replication Manager for MySQL in both Fedora
and EPEL. With changes from 2.0.11 - 2.1.0 there was an
incompatible change in that the daemon scripts were renamed:
mmmd_agent - mmm_agentd
mmmd_mon - mmm_mond
Upgrades obviously break because the INIT scripts and configuration
files reference the path to the files. Would a sufficient
work-around be a symlink to the old path, or would that not be kosher
for any reason?
Thank you for your feedback.
Well, I would suggest if you can get it setup so it continues to work
as expected on upgrade it should be fine. If thats a symlink or
whatever it should be ok.
Perhaps make and test a version, then post the spec diff for
comment/feedback if you like?
kevin
I have a working upgrade from mysql-mmm-2.0.x - mysql-mmm-2.1. I verified
that all expected changes happen, and that the running processes are gracefully
condrestart'd.
The changes are pretty straight forward. Because this is the first release of
mysql-mmm = 2.1 I am touching a file at
'%{_datadir}/mysql-mmm/.pre-2.1.0-upgrade-check' in the install. From %pre, if
this file does *not* exist then the current install is 2.1 (meaning
modifications need to be done for 2.1 compatibility). I then touch
'%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods' (in %pre)
allowing me to verify that modifications are needed in %post.
The modifications are simple sed changes for pid/status file and sbin daemon
paths. I suppose I'm looking for another set of eyes to point out anything
that is not obvious to me. The following are the [snipped] spec changes:
# --
%install
# … snipped
# Specific for upgrading from 2.0.x - 2.1
touch %{buildroot}%{_datadir}/mysql-mmm/.pre-2.1.0-upgrade-check-do-not-delete
%pre
# This is to facilitate the upgradability of 2.0.x - 2.1
DO_MOD_CHECK=%{_datadir}/mysql-mmm/.pre-2.1.0-upgrade-check-do-not-delete
DO_MOD_VERIFY=%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods
rm -f $DO_MOD_VERIFY 2/dev/null
if [ ! -f $DO_MOD_CHECK ]; then
# the 'check' file does *not* exist (only installed as of 2.1.0)
# modifications are necessary.
touch $DO_MOD_VERIFY
# copy paths for new configs (if replaced on upgrade)
cp -a %{_localstatedir}/run/mysql-mmm/mmmd_mon.pid \
%{_localstatedir}/run/mysql-mmm/mmm_mond.pid 2/dev/null ||:
cp -a %{_localstatedir}/lib/mysql-mmm/mmmd_mon.status \
%{_localstatedir}/lib/mysql-mmm/mmm_mond.status 2/dev/null ||:
cp -a %{_localstatedir}/run/mysql-mmm/mmmd_agent.pid \
%{_localstatedir}/run/mysql-mmm/mmm_agentd.pid 2/dev/null ||:
fi
%post
# This is to facilitate the upgradability of 2.0.x - 2.1
DO_MOD_VERIFY=%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods
if [ -f $DO_MOD_VERIFY ]; then
# system was upgraded from 2.1, need to modify config files/paths
if [ -f %{_sysconfdir}/mysql-mmm/mmm_mon.conf ]; then
cp -a %{_sysconfdir}/mysql-mmm/mmm_mon.conf
%{_sysconfdir}/mysql-mmm/mmm_mon.conf-pre2.1
sed -i
s|/var/run/mysql-mmm/mmmd_mon.pid|/var/run/mysql-mmm/mmm_mond.pid|g \
%{_sysconfdir}/mysql-mmm/mmm_mon.conf
sed -i
s|/var/lib/mysql-mmm/mmmd_mon.status|/var/lib/mysql-mmm/mmm_mond.status|g \
%{_sysconfdir}/mysql-mmm/mmm_mon.conf
fi
if [ -f %{_sysconfdir}/mysql-mmm/mmm_common.conf ]; then
cp -a %{_sysconfdir}/mysql-mmm/mmm_common.conf
%{_sysconfdir}/mysql-mmm/mmm_common.conf-pre2.1
sed -i
s|/var/run/mysql-mmm/mmmd_agent.pid|/var/run/mysql-mmm/mmm_agentd.pid|g \
%{_sysconfdir}/mysql-mmm/mmm_common.conf
fi
fi
%post agent
# … snipped
# This is to facilitate the upgradability of 2.0.x - 2.1
DO_MOD_VERIFY=%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods
if [ -f $DO_MOD_VERIFY ]; then
# remove old files
rm -f %{_localstatedir}/run/mysql-mmm/mmmd_agent.pid 2/dev/null ||:
fi
%post monitor
# … snipped
# This is to facilitate the upgradability of 2.0.x - 2.1
DO_MOD_VERIFY=%{_localstatedir}/run/mysql-mmm/.post-2.1.0-upgrade-do_mods
if [ -f $DO_MOD_VERIFY ]; then
# remove old files
rm -f %{_localstatedir}/run/mysql-mmm/mmmd_mon.pid 2/dev/null ||:
rm -f %{_localstatedir}/lib/mysql-mmm/mmmd_mon.status 2/dev/null ||:
fi
# --
Thanks.
---
derks
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, 2010-03-01 at 14:27 -0800, Adam Williamson wrote: * Replace it by a free text comment system Well, right now you have the choice of looking at the numbers or just ignoring them and reading the text (whether to auto-push a release with a given positive karma is a decision made by the maintainer when pushing a package, remember, it's not written into Bodhi; so you can choose to ignore the votes entirely if you like). Doing this would give you a choice of just reading the text or...just reading the text. Doesn't seem like an improvement :) You can put free text in a bodhi comment without giving positive or negative karma. Seems we already have what you want to replace it with. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 03/01/2010 05:01 PM, Jesse Keating wrote: On Mon, 2010-03-01 at 16:51 -0500, Doug Ledford wrote: To be pedantic, Fedora is what it is. What the leadership has to say doesn't really matter in terms of what Fedora *is*, only in terms of what Fedora is *supposed to be*. In order to know what Fedora really is, a person would need to look over the updates that have been pushed to F-11 and F-12 and compare those to what's in rawhide and maybe F-13 and see if wholesale package updates are being reserved for rawhide or if wholesale updates are being pushed on down into the stable releases. At that point you would know for sure what Fedora is, not what it's supposed to be. I say this because, obviously, different people read the part about First differently and do different things. Right, there are obviously people who feel that what Fedora Is is broken. The status quo isn't working, and that's why FESCo or members of FESCo are trying to come up with ways to fix that. A lot of the argument here seems to be disagreement about what Fedora Should Be, which is precisely an issue the Fedora board has been struggling with. Which is when I point out that I, personally, like the Mandriva way of doing things: Bugfixes/Backports as the two update streams with different goals and allowed updates. I would prefer to have my home server on Bugfixes, and my desktop environment on Backports. But, I could almost guess that a reasonable compromise between the two update stream model and the single update stream model would be to have a single update stream, but to treat all those apps normally thought of as server apps (database servers, dhcp, bind, dnsmasq, dovecot, sendmail, exim, postfix, blah, blah) as though they existed under the bugfix model and treat those things most closely related to the day to day user experience (firefox, thunderbird, gnome, kde, pulseaudio, openoffice) under the backport model. Dunno, could be wrong there. Maybe I'm the only one that draws that particular line between the packages he would like to see updated versus the ones he wants to see targeted fixes only in. If you asked me the same question with my fedora packager hat on, then I prefer updates in stable releases so I can copy my spec, sources, clog, and patch files from devel to F-13/F-12/F-11 and just keep everything in sync. I freely admit that this is purely a convenience thing for me. However, I think this clearly demonstrates that doing backports + bugfixes is no more work than doing devel + bugfixes as the bakcports is mainly just a copy, build, release cycle that takes no real time. It's keeping bugfix releases separate from the new releases that takes time and effort. Some people do that now, some don't. For those that do, the two stream model would probably be an easy change. For those that don't, it would be seen as burdensome since it would be adding the bugfix side, not the backport side. Oh, since it was implied several times in this thread by a couple different people, I feel obliged to point out that I don't think it's appropriate to assume that if someone wants a stable release then they should be on Fedora N-1. I've had machines that were on Fedora N-1 until it became N-2, at which point I upgraded to N. That I leap frogged had nothing to do with whether or not I wanted a stable stream. Well, it sorta did, the 6 month release cycle was too fast and I put off upgrading until 1 year passed, and I didn't want to have to upgrade for another year so I had to jump to N. The fact that I went to N instead of N-1 doesn't imply that I want a mainly rolling update now and to infer so would be incorrect. -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2 Mar 2010, Nicolas Mailhot wrote: Le lundi 01 mars 2010 à 14:46 -0500, Seth Vidal a écrit : Given that we don't provide an easily accessible user-friendly rollback mechanism, I don't know that that's actually applicable to the general case, though. yum history undo works pretty well. Not flawless, to be sure - but it's not bad for the simple-ish cases. How many of those before the system becomes too weird for reproduceability to work? Remember, one of the dnssec problem causes was the difference between new clean installs and old continuously updated systems. Same amount as any update process. If the scriptlets hose things then you're SOL. nothing yum (or rpm) can do about that. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 10-03-01 15:06:21, Josh Stone wrote: On 03/01/2010 11:46 AM, Seth Vidal wrote: ... yum history undo works pretty well. Not flawless, to be sure - but it's not bad for the simple-ish cases. ... But for rolling back an update, yum requires that the old package is still available. We only keep the very latest version in the updates, so unless your previous version was from the initial release, you're out of luck. My last yum-update hit 19 packages, and only 7 can be downgraded by yum-history-undo. Yeah, what's up with that? I see Failed to downgrade for packages that are still present in the yum cache, available with no need to fetch them at all. -- TonyN.:' mailto:tonynel...@georgeanelson.com ' http://www.georgeanelson.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Matthias Clasen wrote: GNOME has bug-fix releases (e.g. 2.28.1, 2.28.2, etc) and we do package those as updates for Fedora releases. I know, but my question was, are there still any 2.28.x bugfix releases after 2.30.0 gets released? (With KDE, there aren't, so it's either upgrading or no more bugfixes.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Björn Persson wrote: Such as KDE 4.4, just to pick a recent example. I had to log out and log in again before I could start Kmail again. That's normal and not considered disruptive. That can be quite disruptive if I have long-running processes that shouldn't be interrupted. You should not upgrade anything while those processes are running, especially not the desktop environment you're using. Even bugfix releases of KDE require a session restart to fully work. (This is also not quite the common usecase.) And since the KDE upgrade I get popups when I log in about something called Akonadi that doesn't work because something called Nepomuk isn't running. I have no idea what that is but apparently something broke. It's a mostly harmless warning, but there's an option to set in System Settings to get rid of it: http://userbase.kde.org/Akonadi#Nepomuk_Indexing_Agents_have_been_Disabled Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Jesse Keating wrote: And without using some sort of repository for users to test things and provide feedback, how do you propose we distinguish between the two sets of updates there? Hey, this is a strawman! I'm not saying updates-testing should go away. I'm just saying there are valid reasons for pushing SOME updates directly to stable. The updates which are susceptible of breaking things should NOT go directly to stable, they are what updates-testing is for. (For example, we NEVER push KDE version upgrades directly to stable, not even bugfix releases. We only hit push to stable once we are confident we aren't breaking things.) I just disagree with the claim that ALL updates are susceptible of breaking things. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Jesse Keating wrote: Ubuntu is not the first to pick up technology in their releases either. They generally wait for Fedora to ship with it first and work out all the kinks, then they snap it run with it. So I really don't buy the but then we'd be Ubuntu argument, at all. It's true that Ubuntu is usually one or two releases behind us with new stuff. (Though they are exceptions, e.g. Upstart which they developed and were the first to ship. They also shipped KDE 4 K3b a release earlier because we didn't feel comfortable shipping an alpha version of K3b in a stable release.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi karma feature request
On Mon, 2010-03-01 at 17:34 -0500, Doug Ledford wrote: One could argue that the current bodhi karma system is simply too simplistic for real use cases. Maybe instead of just +1 -1, there should be: Fixes my problem Works for me (someone testing that didn't necessarily have any of the problem supposedly fixed by this update just noting that their system still works ok with the update) Doesn't fix my problem (but doesn't necessarily imply it's any worse than before) Causes new problems (which should, IMO, be an automatic veto of any push to stable, requiring intervention to override) I could see situations where you would want to push updates to stable if say the update was supposed to solve multiple bugs, but turns out it only solves a subset of those bugs and doesn't cause new ones, so you would have some FMP, maybe some WFM, some DFMP, but no CNP. You'd probably just need to leave it up to the maintainer to decided if the bugs that are solved are important enough to push to stable before respinning another attempt at the ones that weren't solved. I've personally seen situations where this would be helpful with the mdadm package when I had 5 or 6 bugs on a single update and only 4 of them were actually solved. The update was still worth pushing while I worked on the others again. If you really wanted to get fancy, the FMP/DFMP options could be tied to specific bugzillas reported against the update, and if you get a FMP for each bugzilla listed in the update, plus at least 1 WFM, then you could automatically push to stable. Would be much better than the 3 random +1s you get now that don't indicate anything about test coverage or anything like that. Also FMP/DFMP karma against a bug could be noted both in the bodhi ticket as well as in the bug itself with a resultant VERIFIED/FAILS_QA toggle to the bug status. FMP + WFM :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Class-Method-Modifiers-1.05.tar.gz uploaded to lookaside cache by cweyl
A file has been added to the lookaside cache for perl-Class-Method-Modifiers: 8f504d4a95b2994835fbe72a3790864e Class-Method-Modifiers-1.05.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 569295] New: Branch perl-Hash-Case for EPEL
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Branch perl-Hash-Case for EPEL https://bugzilla.redhat.com/show_bug.cgi?id=569295 Summary: Branch perl-Hash-Case for EPEL Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: perl-Hash-Case AssignedTo: cw...@alumni.drew.edu ReportedBy: iarn...@gmail.com QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, fedora-perl-devel-l...@redhat.com Classification: Fedora Chris, would you be happy to branch perl-Hash-Case for EPEL? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 569295] Branch perl-Hash-Case for EPEL
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=569295 Iain Arnell iarn...@gmail.com changed: What|Removed |Added Blocks||569301 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 569300] New: Release perl-Hash-Merge for EPEL
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Release perl-Hash-Merge for EPEL https://bugzilla.redhat.com/show_bug.cgi?id=569300 Summary: Release perl-Hash-Merge for EPEL Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: perl-Hash-Merge AssignedTo: tcall...@redhat.com ReportedBy: iarn...@gmail.com QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Spot, I notice that perl-Hash-Merge was branched and built for EPEL, but never submitted for release. Is that just an oversight? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 569301] New: Branch perl-Config-IniHash for EPEL
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Branch perl-Config-IniHash for EPEL https://bugzilla.redhat.com/show_bug.cgi?id=569301 Summary: Branch perl-Config-IniHash for EPEL Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: perl-Config-IniHash AssignedTo: cw...@alumni.drew.edu ReportedBy: iarn...@gmail.com QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, fedora-perl-devel-l...@redhat.com Depends on: 569295,569298 Classification: Fedora Chris, would you be happy to branch perl-Config-IniHash for EPEL? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Class-Method-Modifiers/F-13 perl-Class-Method-Modifiers.spec, 1.8, 1.9 sources, 1.4, 1.5
Author: cweyl
Update of /cvs/extras/rpms/perl-Class-Method-Modifiers/F-13
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv23983
Modified Files:
perl-Class-Method-Modifiers.spec sources
Log Message:
* Mon Mar 01 2010 Chris Weyl cw...@alumni.drew.edu 1.05-1
- update by Fedora::App::MaintainerTools 0.004
- PERL_INSTALL_ROOT = DESTDIR
Index: perl-Class-Method-Modifiers.spec
===
RCS file:
/cvs/extras/rpms/perl-Class-Method-Modifiers/F-13/perl-Class-Method-Modifiers.spec,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -p -r1.8 -r1.9
--- perl-Class-Method-Modifiers.spec4 Dec 2009 02:01:49 - 1.8
+++ perl-Class-Method-Modifiers.spec1 Mar 2010 08:42:00 - 1.9
@@ -1,22 +1,23 @@
+Name: perl-Class-Method-Modifiers
+Summary:Provides Moose-like method modifiers
+Version:1.05
+Release:1%{?dist}
+License:GPL+ or Artistic
+Group: Development/Libraries
+Source0:
http://search.cpan.org/CPAN/authors/id/S/SA/SARTAK/Class-Method-Modifiers-%{version}.tar.gz
+URL:http://search.cpan.org/dist/Class-Method-Modifiers
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+BuildArch: noarch
+
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
+BuildRequires: perl(MRO::Compat)
+BuildRequires: perl(Test::Exception)
+BuildRequires: perl(Test::More)
-Name: perl-Class-Method-Modifiers
-Version:1.04
-Release:2%{?dist}
-License:GPL+ or Artistic
-Group: Development/Libraries
-Summary:Provides Moose-like method modifiers
-Source:
http://search.cpan.org/CPAN/authors/id/S/SA/SARTAK/Class-Method-Modifiers-%{version}.tar.gz
-Url:http://search.cpan.org/dist/Class-Method-Modifiers
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
-BuildArch: noarch
-
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
-BuildRequires: perl(MRO::Compat)
-# testing
-BuildRequires: perl(Test::Exception)
-BuildRequires: perl(Test::More)
+%{?perl_default_filter}
+%{?perl_default_subpackage_tests}
%description
Method modifiers are a powerful feature from the CLOS (Common Lisp Object
@@ -37,8 +38,6 @@ particular modifiers work.
%prep
%setup -q -n Class-Method-Modifiers-%{version}
-find t/ -type f -exec perl -pi -e 's|^#!perl|#!/usr/bin/perl|' {} +
-
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
@@ -46,7 +45,7 @@ make %{?_smp_mflags}
%install
rm -rf %{buildroot}
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
+make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
@@ -60,11 +59,15 @@ rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
-%doc Changes t/
+%doc Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
+* Mon Mar 01 2010 Chris Weyl cw...@alumni.drew.edu 1.05-1
+- update by Fedora::App::MaintainerTools 0.004
+- PERL_INSTALL_ROOT = DESTDIR
+
* Fri Dec 4 2009 Stepan Kasal ska...@redhat.com - 1.04-2
- rebuild against perl 5.10.1
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Class-Method-Modifiers/F-13/sources,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- sources 31 Jul 2009 07:19:17 - 1.4
+++ sources 1 Mar 2010 08:42:00 - 1.5
@@ -1 +1 @@
-bf278d379903849d492ab975d6504cbe Class-Method-Modifiers-1.04.tar.gz
+8f504d4a95b2994835fbe72a3790864e Class-Method-Modifiers-1.05.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Perl-MinimumVersion/F-13 .cvsignore, 1.5, 1.6 perl-Perl-MinimumVersion.spec, 1.13, 1.14 sources, 1.5, 1.6
Author: corsepiu
Update of /cvs/pkgs/rpms/perl-Perl-MinimumVersion/F-13
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv30658
Modified Files:
.cvsignore perl-Perl-MinimumVersion.spec sources
Log Message:
* Mon Mar 01 2010 Ralf Corsépius corse...@fedoraproject.org - 1.24-1
- Upstream update.
- Adjust BR's.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Perl-MinimumVersion/F-13/.cvsignore,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- .cvsignore 26 Apr 2009 06:08:29 - 1.5
+++ .cvsignore 1 Mar 2010 13:19:05 - 1.6
@@ -1 +1 @@
-Perl-MinimumVersion-1.20.tar.gz
+Perl-MinimumVersion-1.24.tar.gz
Index: perl-Perl-MinimumVersion.spec
===
RCS file:
/cvs/pkgs/rpms/perl-Perl-MinimumVersion/F-13/perl-Perl-MinimumVersion.spec,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -p -r1.13 -r1.14
--- perl-Perl-MinimumVersion.spec 7 Dec 2009 13:04:44 - 1.13
+++ perl-Perl-MinimumVersion.spec 1 Mar 2010 13:19:05 - 1.14
@@ -1,6 +1,6 @@
Name: perl-Perl-MinimumVersion
-Version:1.20
-Release:3%{?dist}
+Version:1.24
+Release:1%{?dist}
Summary:Find a minimum required version of perl for Perl code
License:GPL+ or Artistic
Group: Development/Libraries
@@ -11,24 +11,23 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
-BuildRequires: perl(List::Util) = 1.19
-BuildRequires: perl(PPI) = 1.118
+BuildRequires: perl(List::Util) = 1.18
+BuildRequires: perl(PPI) = 1.205
BuildRequires: perl(Test::Script) = 1.02
-BuildRequires: perl(version)
-BuildRequires: perl(File::Find::Rule) = 0.30
+BuildRequires: perl(version) = 0.76
+BuildRequires: perl(File::Find::Rule) = 0.32
BuildRequires: perl(File::Find::Rule::Perl) = 1.04
BuildRequires: perl(File::Spec) = 0.80
BuildRequires: perl(Test::More) = 0.47
+BuildRequires: perl(Perl::Critic::Utils) = 1.104
+BuildRequires: perl(Params::Util) = 0.25
# For improved tests
-BuildRequires: perl(Test::Pod) = 1.00
+BuildRequires: perl(Test::Pod) = 1.26
BuildRequires: perl(Test::CPAN::Meta) = 0.12
-# n/a in Fedora
-# BuildRequires: perl(Pod::Simple) = 3.07
-BuildRequires: perl(Pod::Simple)
+BuildRequires: perl(Pod::Simple) = 3.07
BuildRequires: perl(Test::MinimumVersion) = 0.008
-
%description
Find a minimum required version of perl for Perl code
@@ -61,6 +60,10 @@ make test AUTOMATED_TESTING=1
%{_mandir}/man3/*
%changelog
+* Mon Mar 01 2010 Ralf Corsépius corse...@fedoraproject.org - 1.24-1
+- Upstream update.
+- Adjust BR's.
+
* Mon Dec 7 2009 Stepan Kasal ska...@redhat.com - 1.20-3
- rebuild against perl 5.10.1
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Perl-MinimumVersion/F-13/sources,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- sources 26 Apr 2009 06:08:29 - 1.5
+++ sources 1 Mar 2010 13:19:06 - 1.6
@@ -1 +1 @@
-6c69ce485db4ca399f29638c34f84da6 Perl-MinimumVersion-1.20.tar.gz
+307a1ebae711026396ba307d2ef7e4ab Perl-MinimumVersion-1.24.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Perl-MinimumVersion/F-12 .cvsignore, 1.5, 1.6 perl-Perl-MinimumVersion.spec, 1.12, 1.13 sources, 1.5, 1.6
Author: corsepiu
Update of /cvs/pkgs/rpms/perl-Perl-MinimumVersion/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv30948
Modified Files:
.cvsignore perl-Perl-MinimumVersion.spec sources
Log Message:
* Mon Mar 01 2010 Ralf Corsépius corse...@fedoraproject.org - 1.24-1
- Upstream update.
- Adjust BR's.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Perl-MinimumVersion/F-12/.cvsignore,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- .cvsignore 26 Apr 2009 06:08:29 - 1.5
+++ .cvsignore 1 Mar 2010 13:20:55 - 1.6
@@ -1 +1 @@
-Perl-MinimumVersion-1.20.tar.gz
+Perl-MinimumVersion-1.24.tar.gz
Index: perl-Perl-MinimumVersion.spec
===
RCS file:
/cvs/pkgs/rpms/perl-Perl-MinimumVersion/F-12/perl-Perl-MinimumVersion.spec,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -p -r1.12 -r1.13
--- perl-Perl-MinimumVersion.spec 26 Jul 2009 16:11:22 - 1.12
+++ perl-Perl-MinimumVersion.spec 1 Mar 2010 13:20:56 - 1.13
@@ -1,6 +1,6 @@
Name: perl-Perl-MinimumVersion
-Version:1.20
-Release:2%{?dist}
+Version:1.24
+Release:1%{?dist}
Summary:Find a minimum required version of perl for Perl code
License:GPL+ or Artistic
Group: Development/Libraries
@@ -11,24 +11,25 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
-BuildRequires: perl(List::Util) = 1.19
-BuildRequires: perl(PPI) = 1.118
+BuildRequires: perl(List::Util) = 1.18
+BuildRequires: perl(PPI) = 1.205
BuildRequires: perl(Test::Script) = 1.02
+# Fedora 12's version is outdated
+# BuildRequires: perl(version) = 0.76
BuildRequires: perl(version)
-BuildRequires: perl(File::Find::Rule) = 0.30
+BuildRequires: perl(File::Find::Rule) = 0.32
BuildRequires: perl(File::Find::Rule::Perl) = 1.04
BuildRequires: perl(File::Spec) = 0.80
BuildRequires: perl(Test::More) = 0.47
+BuildRequires: perl(Perl::Critic::Utils) = 1.104
+BuildRequires: perl(Params::Util) = 0.25
# For improved tests
-BuildRequires: perl(Test::Pod) = 1.00
+BuildRequires: perl(Test::Pod) = 1.26
BuildRequires: perl(Test::CPAN::Meta) = 0.12
-# n/a in Fedora
-# BuildRequires: perl(Pod::Simple) = 3.07
-BuildRequires: perl(Pod::Simple)
+BuildRequires: perl(Pod::Simple) = 3.07
BuildRequires: perl(Test::MinimumVersion) = 0.008
-
%description
Find a minimum required version of perl for Perl code
@@ -61,6 +62,10 @@ make test AUTOMATED_TESTING=1
%{_mandir}/man3/*
%changelog
+* Mon Mar 01 2010 Ralf Corsépius corse...@fedoraproject.org - 1.24-1
+- Upstream update.
+- Adjust BR's.
+
* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.20-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Perl-MinimumVersion/F-12/sources,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- sources 26 Apr 2009 06:08:29 - 1.5
+++ sources 1 Mar 2010 13:20:56 - 1.6
@@ -1 +1 @@
-6c69ce485db4ca399f29638c34f84da6 Perl-MinimumVersion-1.20.tar.gz
+307a1ebae711026396ba307d2ef7e4ab Perl-MinimumVersion-1.24.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Data-JavaScript/devel import.log, NONE, 1.1 perl-Data-JavaScript.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: eseyman
Update of /cvs/pkgs/rpms/perl-Data-JavaScript/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv18462/devel
Modified Files:
.cvsignore sources
Added Files:
import.log perl-Data-JavaScript.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-Data-JavaScript-1_13-1_fc12:HEAD:perl-Data-JavaScript-1.13-1.fc12.src.rpm:1267479490
--- NEW FILE perl-Data-JavaScript.spec ---
Name: perl-Data-JavaScript
Version:1.13
Release:1%{?dist}
Summary:Dump perl data structures into JavaScript code
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Data-JavaScript/
Source0:
http://www.cpan.org/authors/id/J/JP/JPIERCE/Data-JavaScript-%{version}.tgz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%{?perl_default_filter}
%description
This module is mainly intended for CGI programming, when a perl script
generates a page with client side JavaScript code that needs access to
structures created on the server.
%prep
%setup -q -n Data-JavaScript-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc CHANGES README TODO
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Wed Dec 16 2009 Emmanuel Seyman emmanuel.sey...@club-internet.fr 1.13-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Data-JavaScript/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 1 Mar 2010 17:00:42 - 1.1
+++ .cvsignore 1 Mar 2010 21:43:41 - 1.2
@@ -0,0 +1 @@
+Data-JavaScript-1.13.tgz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Data-JavaScript/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 1 Mar 2010 17:00:42 - 1.1
+++ sources 1 Mar 2010 21:43:41 - 1.2
@@ -0,0 +1 @@
+14a2e422d2a22d34749e762614b4736f Data-JavaScript-1.13.tgz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Data-JavaScript/F-12 import.log, NONE, 1.1 perl-Data-JavaScript.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: eseyman
Update of /cvs/pkgs/rpms/perl-Data-JavaScript/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20552/F-12
Modified Files:
.cvsignore sources
Added Files:
import.log perl-Data-JavaScript.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-Data-JavaScript-1_13-1_fc12:F-12:perl-Data-JavaScript-1.13-1.fc12.src.rpm:1267480797
--- NEW FILE perl-Data-JavaScript.spec ---
Name: perl-Data-JavaScript
Version:1.13
Release:1%{?dist}
Summary:Dump perl data structures into JavaScript code
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Data-JavaScript/
Source0:
http://www.cpan.org/authors/id/J/JP/JPIERCE/Data-JavaScript-%{version}.tgz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%{?perl_default_filter}
%description
This module is mainly intended for CGI programming, when a perl script
generates a page with client side JavaScript code that needs access to
structures created on the server.
%prep
%setup -q -n Data-JavaScript-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc CHANGES README TODO
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Wed Dec 16 2009 Emmanuel Seyman emmanuel.sey...@club-internet.fr 1.13-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Data-JavaScript/F-12/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 1 Mar 2010 17:00:42 - 1.1
+++ .cvsignore 1 Mar 2010 22:00:19 - 1.2
@@ -0,0 +1 @@
+Data-JavaScript-1.13.tgz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Data-JavaScript/F-12/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 1 Mar 2010 17:00:42 - 1.1
+++ sources 1 Mar 2010 22:00:20 - 1.2
@@ -0,0 +1 @@
+14a2e422d2a22d34749e762614b4736f Data-JavaScript-1.13.tgz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
