Re: PCRE 8.30 will break API
On 2012-02-09, Sérgio Basto ser...@serjux.com wrote: On Thu, 2012-02-09 at 16:52 +, Petr Pisar wrote: It's long time since PCRE (Perl-Compatible Regular Expression) library has changed API or ABI. Version 8.30 is different. Besides UTF-16 support, the incompatible changes are described by upstream with these words: And sed is not affected ? sed does not use pcre at all. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 5:45 AM, Ralf Corsepius rc040...@freenet.de wrote: [...] To draw an arbitrary example from recent past: Ask yourself - What was the shape of systemd in F15/F16? Has the situation been fixed in F17? Just for the record I didn't have *any* systemd related problem in F15 and neither have one in F16. So from my point of view there is nothing to get fixed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning eruby
Hi, I'm orphaning eruby package. If anyone else wants to take it over, please. Cheers, --- Akira TAGOH -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 04:45 AM, Ralf Corsepius wrote: On 02/09/2012 11:06 PM, Jared K. Smith wrote: On Thu, Feb 9, 2012 at 11:57 AM, Ralf Corsepiusrc040...@freenet.de wrote: IMO, Fedora has obvious problems with its - work-flow (Too immature SW migrates/sneaks through from Alpha/Beta to Final) If you feel this is the case, feel free to help improve the work-flow, or at a minimum help write better Alpha/Beta/Final release criteria to help us catch things you consider immature. Let me put it this way: I am having difficulties in recalling any Fedora release which worked for me out of the box ... In earlier releases there for example were pulseaudio and SELinux, in current releases it's primarily systemd, in F17 I am sure it will be the usemore stuff, which will cause trouble. You can go further back if you like.. NetworkManager,X, KMS,Radeon,Nouveau,etc... But yes there is a pattern not only on a bit level but also policy wize ( we have had the tendency up to this point to implement policy's without having any tools or process to measure the outcome of that policy ). - management, whom seems to be driven by a must have at any price, no point of return ever policy. I'm not sure who you're referring to as management here Everybody involved to drawing strategic and tactical decisions related to the Fedora distribution. My point is, I feel there is a lack of monitoring, reporting, and a sense of responsibility of the different bodies involved and of people who are able to draw unpleasant decisions. To draw an arbitrary example from recent past: Ask yourself - What was the shape of systemd in F15/F16? Has the situation been fixed in F17? You need to be a bit more specific on what situation regarding systemd you are referring to? Bugs are actively being fixed and worked on for example I don't believe we have any bug open against systemd in F15 which is not an RFE or DOC ( somewhere between 10 - 15 bugs in total ). The state of overall migration to systemd is depended on each package maintainer(s) and at current rate that wont be finished until F20+. If you got some ideas how to *motivate* those maintainers to migrate to systemd even if they would just simply package and ship the submitted unit files many of them have received I'm all ears but unfortunately the only way I see that finish in a reasonable time is if FESCO blocks the relevant package from the release. FESCO has avoided thus far to go down that path even thou it already was clear that this was going to be an issue after the F15 release. That said, IMO, on the technical side, Fedora urgently needs a calming down/lean back/settlement phase, say 2 consecutive Fedora releases without revolutionary features being introduced, to revisit re-evaluate, revert/complete old revolutionary features. If we wanted we could release Fedora LTS which Red Hat's could use as bases for their RHEL which also would server as the free alternative RHEL users demand for ( And our infrastructure would actually have faith in the bits we ship and run on top of that ) and have a constant rolling release ( Fedora/Rawhide ) as opposed to be having 2 GA releases and Rawhide... ( or some variant of the above proposal ) In this spirit, I eg. would propose to table usrmove for F17 and to concentrate on systemd integration and anaconda/grub2 improvements, both topics, I perceived as the hall of shame of F16. Better systemd integration of services is not going to happen I can just tell you that here and now unless fesco brings fourth the big hammer or packagers get their act together. The said state of systemd migration only reflects the said state of package maintainership in the distribution... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Am 10.02.2012 08:36, schrieb Ondrej Vasik: On Fri, 2012-02-10 at 05:45 +0100, Ralf Corsepius wrote: On 02/09/2012 11:06 PM, Jared K. Smith wrote: - management, whom seems to be driven by a must have at any price, no point of return ever policy. I'm not sure who you're referring to as management here Everybody involved to drawing strategic and tactical decisions related to the Fedora distribution. My point is, I feel there is a lack of monitoring, reporting, and a sense of responsibility of the different bodies involved and of people who are able to draw unpleasant decisions. To draw an arbitrary example from recent past: Ask yourself - What was the shape of systemd in F15/F16? Has the situation been fixed in F17? Wrt. F17: usrmove - Independently from the fact that I consider it to be an idotic foolishness, ask yourself if it is a shape to be part of F17? IMO, it's foreseeable it will not be ready, because there are too many unknows attached to it. I now would expect those people having been involved to stand up, show responsibility and revisit their decisions - This obiviously doesn't happen. One additional item to this topic. I'm the Fedora filesystem package maintainer (and because it has it's upstream on the fedorahosted, you can say upstream...) and I was aware of the usrmove feature only from the discussions and feature pages. For quite a long time I waited for an email from Harald - with some please include the changes into upstream git. The only mail I received from him was the mail on 24th of January - saying - do not build the package. Nothing more... Strange - when the first thing for Fedora maintainers should be upstream first and imho violation of Proven It had to happen all at one time in koji. packager rules in some cases . For me it was kind of misusing proven packager - as e.g. in coreutils package he did following change: +%check +# FIXME: check failed!! +# make check (part of http://lists.fedoraproject.org/pipermail/scm-commits/2012-January/725967.html , quite easy to miss when reading the commit mail) without even informing me about that! I don't see disabling testsuite at buildtime as the necessary minimal change. Not saying anything that with the /bin/ provides the spec file looks really like a mess now. The testsuite was failing in rawhide at patch creation time (without any usrmove patches). Works now again. Just turned it on. Given the fact that there is NO ultimate gain from the usrmove feature (ok, I understand all the arguments for the usrmove, but I don't see them that bright at the moment as Harald and fastboot guys - e.g. the compatibility of distro locations is not only in the locations of binaries and we have much more differences in Fedora) That's your personal opinion.. I tend to differ. Please read http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge again. I really don't know why the REAL ACTIONS on this feature were started that late in F17 release cycle - several months after branching. Because politics took so long. Only 3 weeks after the start of usrmove git commits you now have even F18 git branch and F18 would have been MUCH better for it. In addition, for mock builds of F17+ packages with usrmove support on RHEL-6 systems you now need UNSUPPORTED rpm from Harald pages ( http://people.redhat.com/harald/downloads/rpm/4.8.0-19.el6.0.usrmove.1/ ). and? It will get in RHEL-6.3 ... SUPPORTED! That's a self inflicted wound, binding Fedora development to RHEL-6. I'm sure that reverting the changes at the moment would mean much more confusion and that there is the only option now - finish it. But I hope that FESCO will learn from this feature and will set the deadlines for distro-wide features with higher impact sooner - so there will be enough time to postpone them to Fedora X+1 in the case of immaturity. I think there is a difference between usrmove and e.g. GIMP2.8 feature (no offence to Gimp). Greetings, Ondrej Vasik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Qt Package Build fails in rawhide and f17 and builds in f16
Hey, I just seem to run into an error that a package builds just fine in f16 (unpackaged file is another thing) but it won't build on f17 and f18. Is there an incompatibility of the source code with newer Qt versions or is it just a temporary koji hickup? f16 build: http://koji.fedoraproject.org/koji/taskinfo?taskID=313 f17 build: http://koji.fedoraproject.org/koji/taskinfo?taskID=315 f18 build: http://koji.fedoraproject.org/koji/taskinfo?taskID=309 Thanks for any help, Johannes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Qt Package Build fails in rawhide and f17 and builds in f16
On 02/10/2012 11:19 AM, Johannes Lips wrote: Hey, I just seem to run into an error that a package builds just fine in f16 (unpackaged file is another thing) but it won't build on f17 and f18. Is there an incompatibility of the source code with newer Qt versions or is it just a temporary koji hickup? f16 build: http://koji.fedoraproject.org/koji/taskinfo?taskID=313 f17 build: http://koji.fedoraproject.org/koji/taskinfo?taskID=315 f18 build: http://koji.fedoraproject.org/koji/taskinfo?taskID=309 Thanks for any help, Johannes You need to #include stdint.h . This is due to GCC 4.7 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 01:11:06AM +0100, Kevin Kofler wrote: Yes, I'm arguing that the feature is undesirable by design and should not have been approved, not for Fedora 17, not for Fedora 18, not even for Fedora 31337. It has been approved, other distributions are following. It is very clear you do not want this. But at the same time, it is happening in Fedora and elsewhere (noticed openSUSE, will propose for Mageia 3). I don't think additional emails will change anything about either the feature, or your opinion. In any case, when painting I like the colour white. Though maybe in summer (slightly warmer times), I'll change my mind and choose purple. ;) -- Regards, Olav (lurking:) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Test-Fatal-0.009.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-Fatal: d120fa7df76d287080b7e47134159144 Test-Fatal-0.009.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Fatal] Update to 0.009
commit 1c9b99ed9ff14fa1e9f2adf57cad2c2d513fbe95
Author: Paul Howarth p...@city-fan.org
Date: Fri Feb 10 10:32:41 2012 +
Update to 0.009
- New upstream release 0.009:
- Advise against using isnt(exception{...},undef)
perl-Test-Fatal.spec | 10 +++---
sources |2 +-
2 files changed, 8 insertions(+), 4 deletions(-)
---
diff --git a/perl-Test-Fatal.spec b/perl-Test-Fatal.spec
index fd1ef80..5141bd8 100644
--- a/perl-Test-Fatal.spec
+++ b/perl-Test-Fatal.spec
@@ -1,7 +1,7 @@
Summary: Incredibly simple helpers for testing code with exceptions
Name: perl-Test-Fatal
-Version: 0.008
-Release: 2%{?dist}
+Version: 0.009
+Release: 1%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
Url: http://search.cpan.org/dist/Test-Fatal/
@@ -55,7 +55,11 @@ rm -rf %{buildroot}
%{_mandir}/man3/Test::Fatal.3pm*
%changelog
-* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.008-2
+* Fri Feb 10 2012 Paul Howarth p...@city-fan.org 0.009-1
+- Update to 0.009
+ - Advise against using isnt(exception{...},undef)
+
+* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
0.008-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
* Mon Nov 7 2011 Paul Howarth p...@city-fan.org 0.008-1
diff --git a/sources b/sources
index d71f0ff..acbd318 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-201c94efbbcbd38b32e3cdc6752a6c07 Test-Fatal-0.008.tar.gz
+d120fa7df76d287080b7e47134159144 Test-Fatal-0.009.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Fatal/f17] Update to 0.009
Summary of changes: 1c9b99e... Update to 0.009 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Qt Package Build fails in rawhide and f17 and builds in f16
Hmm weird that the previous version went through the mass rebuild without problems. So I am going to check upstream. On Fri, Feb 10, 2012 at 10:28 AM, Brendan Jones brendan.jones...@gmail.comwrote: On 02/10/2012 11:19 AM, Johannes Lips wrote: Hey, I just seem to run into an error that a package builds just fine in f16 (unpackaged file is another thing) but it won't build on f17 and f18. Is there an incompatibility of the source code with newer Qt versions or is it just a temporary koji hickup? f16 build: http://koji.fedoraproject.org/**koji/taskinfo?taskID=313http://koji.fedoraproject.org/koji/taskinfo?taskID=313 f17 build: http://koji.fedoraproject.org/**koji/taskinfo?taskID=315http://koji.fedoraproject.org/koji/taskinfo?taskID=315 f18 build: http://koji.fedoraproject.org/**koji/taskinfo?taskID=309http://koji.fedoraproject.org/koji/taskinfo?taskID=309 Thanks for any help, Johannes You need to #include stdint.h . This is due to GCC 4.7 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 10:06 AM, Jóhann B. Guðmundsson wrote: On 02/10/2012 04:45 AM, Ralf Corsepius wrote: In this spirit, I eg. would propose to table usrmove for F17 and to concentrate on systemd integration and anaconda/grub2 improvements, both topics, I perceived as the hall of shame of F16. Better systemd integration of services is not going to happen I can just tell you that here and now Why not? Users are supposed to struggle with the swamp/mess the systemd integration currently is in? Could it be systemd reached its design limitations (== is a failure)? Don't get me wrong, I am honestly asking, because I don't know and because it's in general not uncommmon to see promissing developments to reach 90% of its goals in 10% of the projected time, but to never cover the remaining 10% - Often because for limitations of the design. unless fesco brings fourth the big hammer or packagers get their act together. That's what I meant my responsibility. I am asking the people in charge to draw consequences. This could be to bring out the hammer, it could be to revert, it could be Red Hat to delegate personnel, it could be volunteers to jump in, to bring this unpleasant topic to a proper end. The said state of systemd migration only reflects the said state of package maintainership in the distribution... Well, I do not share this view. IMO, it reflects the attitude of the people behind this development. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 5:45 AM, Ralf Corsepius rc040...@freenet.de wrote: Wrt. F17: usrmove - Independently from the fact that I consider it to be an idotic foolishness, ask yourself if it is a shape to be part of F17? IMO, it's foreseeable it will not be ready, because there are too many unknows attached to it. I now would expect those people having been involved to stand up, show responsibility and revisit their decisions - This obiviously doesn't happen. At the moment the feature was again brought up to FESCo two weeks ago, the commits were already in the repository, so reverting the feature would have had a pretty big cost; as much as I oppose the idea of UsrMove, I didn't think reverting it was worth it at that time, and I don't think it is worth it now - the situation is not that hopeless to call for a comparatively extreme measure. (Also, a large part of FESCo clearly wants this, and I don't think reverting features just because elections happened in the mean time is a good idea.) Yes, FESCo * should have recognized early that the scope of the feature was not thought through and that more pieces are needed (contrary to claims back in the end of October that everything is already implemented and works) * probably should have asked for an advance approval from FPC (although, as a general rule, I think advance approval from FPC lengthens the feature cycle too much and should be avoided) * and should have monitored the progress more closely. The feature process is currently being revised, and at least some of these issues have been brought up at https://fedoraproject.org/wiki/Fixing_features . What would be especially useful is to find ways to improve the feature process. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
None of your arguments explain the lack of communication. FESCo give you go even so late in development cycle, because you are well known in Fedora project. We believe that you can make it, because you told us at the start it's tested, it's working. If you said earlier changes in anaconda, rpm and other places are needed, it would be probably postponed into F-18. Such huge change should be discussed with release engineering at the start (in November), not in January. I guess for future features will be a scope with all dependencies a must and a plan of such huge changes will be reviewed by FESCo more closely. Now I really hope that new feature process will be ready for next Fedora. Marcela On 02/10/2012 10:21 AM, Harald Hoyer wrote: Am 10.02.2012 08:36, schrieb Ondrej Vasik: On Fri, 2012-02-10 at 05:45 +0100, Ralf Corsepius wrote: On 02/09/2012 11:06 PM, Jared K. Smith wrote: - management, whom seems to be driven by a must have at any price, no point of return ever policy. I'm not sure who you're referring to as management here Everybody involved to drawing strategic and tactical decisions related to the Fedora distribution. My point is, I feel there is a lack of monitoring, reporting, and a sense of responsibility of the different bodies involved and of people who are able to draw unpleasant decisions. To draw an arbitrary example from recent past: Ask yourself - What was the shape of systemd in F15/F16? Has the situation been fixed in F17? Wrt. F17: usrmove - Independently from the fact that I consider it to be an idotic foolishness, ask yourself if it is a shape to be part of F17? IMO, it's foreseeable it will not be ready, because there are too many unknows attached to it. I now would expect those people having been involved to stand up, show responsibility and revisit their decisions - This obiviously doesn't happen. One additional item to this topic. I'm the Fedora filesystem package maintainer (and because it has it's upstream on the fedorahosted, you can say upstream...) and I was aware of the usrmove feature only from the discussions and feature pages. For quite a long time I waited for an email from Harald - with some please include the changes into upstream git. The only mail I received from him was the mail on 24th of January - saying - do not build the package. Nothing more... Strange - when the first thing for Fedora maintainers should be upstream first and imho violation of Proven It had to happen all at one time in koji. packager rules in some cases . For me it was kind of misusing proven packager - as e.g. in coreutils package he did following change: +%check +# FIXME: check failed!! +# make check (part of http://lists.fedoraproject.org/pipermail/scm-commits/2012-January/725967.html , quite easy to miss when reading the commit mail) without even informing me about that! I don't see disabling testsuite at buildtime as the necessary minimal change. Not saying anything that with the /bin/ provides the spec file looks really like a mess now. The testsuite was failing in rawhide at patch creation time (without any usrmove patches). Works now again. Just turned it on. Given the fact that there is NO ultimate gain from the usrmove feature (ok, I understand all the arguments for the usrmove, but I don't see them that bright at the moment as Harald and fastboot guys - e.g. the compatibility of distro locations is not only in the locations of binaries and we have much more differences in Fedora) That's your personal opinion.. I tend to differ. Please read http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge again. I really don't know why the REAL ACTIONS on this feature were started that late in F17 release cycle - several months after branching. Because politics took so long. Only 3 weeks after the start of usrmove git commits you now have even F18 git branch and F18 would have been MUCH better for it. In addition, for mock builds of F17+ packages with usrmove support on RHEL-6 systems you now need UNSUPPORTED rpm from Harald pages ( http://people.redhat.com/harald/downloads/rpm/4.8.0-19.el6.0.usrmove.1/ ). and? It will get in RHEL-6.3 ... SUPPORTED! That's a self inflicted wound, binding Fedora development to RHEL-6. I'm sure that reverting the changes at the moment would mean much more confusion and that there is the only option now - finish it. But I hope that FESCO will learn from this feature and will set the deadlines for distro-wide features with higher impact sooner - so there will be enough time to postpone them to Fedora X+1 in the case of immaturity. I think there is a difference between usrmove and e.g. GIMP2.8 feature (no offence to Gimp). Greetings, Ondrej Vasik -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 11:28:59AM +0100, Olav Vitters wrote:
It has been approved, other distributions are following. It is very
clear you do not want this. But at the same time, it is happening in
Fedora and elsewhere (noticed openSUSE, will propose for Mageia 3).
For openSUSE we're currently doing it in a lightweight fashion,
i.e. no movement of directories (until rpm learns do deal with
those) and no big /bin - /usr/bin symlink.
(We're mostly doing it because to provide some kind of Fedora
compatibility for 3rd parties.)
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 12:11 PM, Michael Schroeder wrote: On Fri, Feb 10, 2012 at 11:28:59AM +0100, Olav Vitters wrote: It has been approved, other distributions are following. It is very clear you do not want this. But at the same time, it is happening in Fedora and elsewhere (noticed openSUSE, will propose for Mageia 3). For openSUSE we're currently doing it in a lightweight fashion, i.e. no movement of directories (until rpm learns do deal with those) and no big /bin - /usr/bin symlink. Then let me point that openSUSE _not following_ this route would be a surplus for openSUSE to attract users, who are feeling this Fedora development is driving them away from Fedora. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 10/02/12 12:11, Michael Schroeder wrote: (We're mostly doing it because to provide some kind of Fedora compatibility for 3rd parties.) What? You don't think, there are other/better reasons to do this? Harald and Kay described better/other reasons on their feature-page. I think this is really astonishing! -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, 2012-02-10 at 10:21 +0100, Harald Hoyer wrote: Am 10.02.2012 08:36, schrieb Ondrej Vasik: Given the fact that there is NO ultimate gain from the usrmove feature (ok, I understand all the arguments for the usrmove, but I don't see them that bright at the moment as Harald and fastboot guys - e.g. the compatibility of distro locations is not only in the locations of binaries and we have much more differences in Fedora) That's your personal opinion.. I tend to differ. Please read http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge again. I already read that few times before and I understand all the things. I'm not against usrmove feature - as I see the benefits - but I'm not a big fan of it - as I see some of the negatives. It is really not that painless how it was presented at the beginning. But I'm against the style and timing how it was achieved. None of the arguments in the systemd page usrmove cases is we need it now and it can't wait for Fedora 18. All of them are personal opinions of you and systemd guys - and as I said, they are mostly valid. I really don't know why the REAL ACTIONS on this feature were started that late in F17 release cycle - several months after branching. Because politics took so long. So it should have been moved to F18... I still see it very unfortunate, but it reached that far that it could be only taken as a warning for future releases distro-wide features. Only 3 weeks after the start of usrmove git commits you now have even F18 git branch and F18 would have been MUCH better for it. In addition, for mock builds of F17+ packages with usrmove support on RHEL-6 systems you now need UNSUPPORTED rpm from Harald pages ( http://people.redhat.com/harald/downloads/rpm/4.8.0-19.el6.0.usrmove.1/ ). and? It will get in RHEL-6.3 ... SUPPORTED! That's a self inflicted wound, binding Fedora development to RHEL-6. And? When will the RHEL-6.3 start being supported? After or before the Fedora 17 release? That's a self inflicted wound, breaking Fedora-17+ package builders on non-Fedora systems. Try to think about third parties using RHEL-6 (or different supported rpmbased) mock builders for their third party packages and using Fedora for the rest of non-critical jobs. It is not only about RHEL... I'm quite sure there are such cases - and builds for Fedora-17 will be broken for them unless they will use unsupported patched rpm. Anyway, that's more for beer-meeting discussion next week ;). Greetings, Ondrej Vasik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 10:21 AM, Harald Hoyer har...@redhat.com wrote: I really don't know why the REAL ACTIONS on this feature were started that late in F17 release cycle - several months after branching. Because politics took so long. Which part exactly? * Half of July 2011! The feature page was created * Sep 29: Marked as ReadyForWrangler * Oct 27 (+~1 month!): First reviewed by Feature Wrangler * Nov 07 (+11 days): Approved by wrangler, on agenda for FESCo * Nov 21 (+14 days): After much discussion, feature approved * Nov 14 (+7 weeks since feature proposed!, +7 days on FESCo agenda): FESCo asked for FPC review (AFAICT, feature owners typically include FPC review in scope of their features themselves) * Nov 21 (+7 days): FPC review initiated by FESCo * Dec 8 (+2.5 weeks): Final FPC approval, RPM changes requested * Dec 15 (+2.5 months since feature proposed!, +3.5 weeks since feature approval): ProvenPackager requested * Jan 3 (+3 weeks): First ProvenPackager approved * Jan 9 (+3.5 weeks): Second ProvenPackager approved * sometime after Jan 15 (+5.5 weeks since FPC asked for RPM changes!): rel-eng contacted * Jan 27 (+ =2 weeks): rel-eng brings objections to FESCo * Feb 2 (+ 1 week): objections resolved * Jan 24 (+2 months since feature approval! +7 weeks since FPC approval! +13 days since second ProvenPackager): first feature-related commits to Fedora git I'll grant you that the politics took some time, sometimes more time than would be desirable, but most of the multi-month delays are directly attributable to not even giving the politics a chance to start. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Am 10.02.2012 09:55, schrieb drago01: On Fri, Feb 10, 2012 at 5:45 AM, Ralf Corsepius rc040...@freenet.de wrote: [...] To draw an arbitrary example from recent past: Ask yourself - What was the shape of systemd in F15/F16? Has the situation been fixed in F17? Just for the record I didn't have *any* systemd related problem in F15 and neither have one in F16. So from my point of view there is nothing to get fixed. surely there is a ton of foedra-packages still shipping sysv/lsb so systemd integration is NOT fnished yet before the next big feature is implemented under pressure it would be a good attidtude look that the last ones are finished this is really not anything i would call a clean development and nobody feels responsible for anything signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Am 10.02.2012 10:06, schrieb Jóhann B. Guðmundsson: The state of overall migration to systemd is depended on each package maintainer(s) and at current rate that wont be finished until F20+. so fedora has STOPPED to be a distribution it is a bundle of packages which hopefully work together and nobody feels repsonsible for anything, things may happen or not or somewhere in a undefined fuuture the definition of a distribution is that all packages are comonig from one central source (repos) and are optimized to work together and not everybody does like he feel and if things are not badly enough broken they will not be touched signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Am 10.02.2012 12:36, schrieb Ondrej Vasik: Anyway, that's more for beer-meeting discussion next week ;). A very good proposal :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, 2012-02-10 at 12:29 +0100, Matthias Runge wrote: On 10/02/12 12:11, Michael Schroeder wrote: (We're mostly doing it because to provide some kind of Fedora compatibility for 3rd parties.) What? You don't think, there are other/better reasons to do this? Harald and Kay described better/other reasons on their feature-page. I think this is really astonishing! I hope that this is just sarcasm. Many of the reasons were refuted to not be real. Of course there are still some positive reasons remaining but they are very weak in comparison to the break of expectations of existing users and developers of 3rd party software. So if you mainly ignore the existing expectations you might come to a conclusion that this feature is a net gain however this is by no means certain thing and undisputable. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Am 10.02.2012 12:38, schrieb Miloslav Trmač: On Fri, Feb 10, 2012 at 10:21 AM, Harald Hoyer har...@redhat.com wrote: I really don't know why the REAL ACTIONS on this feature were started that late in F17 release cycle - several months after branching. Because politics took so long. Which part exactly? * Half of July 2011! The feature page was created * Sep 29: Marked as ReadyForWrangler * Oct 27 (+~1 month!): First reviewed by Feature Wrangler * Nov 07 (+11 days): Approved by wrangler, on agenda for FESCo * Nov 21 (+14 days): After much discussion, feature approved * Nov 14 (+7 weeks since feature proposed!, +7 days on FESCo agenda): FESCo asked for FPC review (AFAICT, feature owners typically include FPC review in scope of their features themselves) * Nov 21 (+7 days): FPC review initiated by FESCo * Dec 8 (+2.5 weeks): Final FPC approval, RPM changes requested * Dec 15 (+2.5 months since feature proposed!, +3.5 weeks since feature approval): ProvenPackager requested * Jan 3 (+3 weeks): First ProvenPackager approved * Jan 9 (+3.5 weeks): Second ProvenPackager approved * sometime after Jan 15 (+5.5 weeks since FPC asked for RPM changes!): rel-eng contacted * Jan 27 (+ =2 weeks): rel-eng brings objections to FESCo * Feb 2 (+ 1 week): objections resolved * Jan 24 (+2 months since feature approval! +7 weeks since FPC approval! +13 days since second ProvenPackager): first feature-related commits to Fedora git I'll grant you that the politics took some time, sometimes more time than would be desirable, but most of the multi-month delays are directly attributable to not even giving the politics a chance to start. Mirek I would say 7 weeks since FPC approval is a reasonable time frame for such a change. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 10/02/12 12:45, Tomas Mraz wrote: I hope that this is just sarcasm. Many of the reasons were refuted to not be real. Of course there are still some positive reasons remaining but they are very weak in comparison to the break of expectations of existing users and developers of 3rd party software. So if you mainly ignore the existing expectations you might come to a conclusion that this feature is a net gain however this is by no means certain thing and undisputable. I think, there are good reasons to move. Doing it, mainly because of others do, is not such a good reason for me. -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Module-Implementation/el6] Update to 0.05
Summary of changes: be51602... Update to 0.05 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: PCRE 8.30 will break API
Am 10.02.2012 12:46, schrieb Richard W.M. Jones: On Fri, Feb 10, 2012 at 01:03:11AM +0100, Kevin Kofler wrote: Richard W.M. Jones wrote: It dlopen's the package so there is no automatic dependency. To make up for this it requires pcre-devel, but in the light of this soname change that might be a bug. It is against the guidelines to require a devel package. Actually ocaml-pcre-devel is the one which requires pcre-devel. I don't think this is against any guidelines, or if it is, it shouldn't be. that devel-packages require other devel-packages is OK but that you need ANY devel-package on machines having not installed any compiler/packaging-software not this machine as example has not a single devel-package over years and some time ago all these were introduced by a packaging mistake package-maintainers should have some CLEAN virtual machine to test if their new versions are introducing new dependencies at all because mostly ANY dpendencie will have another ones over the long and its frustrating to play around all 3 months to look if some of them got relaxed [root@arrakis:~]$ yum remove \*-devel Geladene Plugins: downloadonly, protectbase Einrichten des Entfernungsprozess Löse Abhängigkeiten auf -- Führe Transaktionsprüfung aus --- Package apr-devel.x86_64 0:1.4.5-1.fc15.20111201.rh will be gelöscht --- Package apr-util-devel.x86_64 0:1.3.12-1.fc15 will be gelöscht --- Package cyrus-sasl-devel.x86_64 0:2.1.23-18.fc15 will be gelöscht --- Package db4-devel.x86_64 0:4.8.30-3.fc15 will be gelöscht --- Package expat-devel.x86_64 0:2.0.1-11.fc15 will be gelöscht --- Package httpd-devel.x86_64 0:2.2.22-2.fc15.20120201.rh will be gelöscht --- Package mod_perl-devel.x86_64 0:2.0.5-1.fc15 will be gelöscht -- Verarbeite Abhängigkeiten: perl(Apache::SizeLimit::Core) für Paket: mod_perl-2.0.5-1.fc15.x86_64 --- Package openldap-devel.x86_64 0:2.4.24-5.fc15 will be gelöscht --- Package perl-devel.x86_64 4:5.12.4-164.fc15 will be gelöscht -- Verarbeite Abhängigkeiten: perl-devel für Paket: 1:perl-ExtUtils-ParseXS-2.2206-164.fc15.noarch -- Verarbeite Abhängigkeiten: perl-devel für Paket: perl-ExtUtils-Embed-1.28-164.fc15.noarch -- Verarbeite Abhängigkeiten: perl-devel für Paket: perl-Test-Harness-3.17-164.fc15.noarch -- Verarbeite Abhängigkeiten: perl-devel für Paket: perl-ExtUtils-MakeMaker-6.56-164.fc15.noarch -- Verarbeite Abhängigkeiten: perl-devel für Paket: perl-Test-Simple-0.98-1.fc15.noarch --- Package systemtap-sdt-devel.x86_64 0:1.6-1.fc15 will be gelöscht -- Führe Transaktionsprüfung aus --- Package mod_perl.x86_64 0:2.0.5-1.fc15 will be gelöscht -- Verarbeite Abhängigkeiten: perl(Apache2::Const) für Paket: perl-SOAP-WSDL-2.00.10-10.fc15.20111201.rh.noarch -- Verarbeite Abhängigkeiten: perl(Apache2::Log) für Paket: perl-SOAP-WSDL-2.00.10-10.fc15.20111201.rh.noarch -- Verarbeite Abhängigkeiten: perl(Apache2::RequestIO) für Paket: perl-SOAP-WSDL-2.00.10-10.fc15.20111201.rh.noarch -- Verarbeite Abhängigkeiten: perl(Apache2::RequestRec) für Paket: perl-SOAP-WSDL-2.00.10-10.fc15.20111201.rh.noarch -- Verarbeite Abhängigkeiten: perl(Apache2::RequestUtil) für Paket: perl-SOAP-WSDL-2.00.10-10.fc15.20111201.rh.noarch -- Verarbeite Abhängigkeiten: perl(APR::Table) für Paket: perl-SOAP-WSDL-2.00.10-10.fc15.20111201.rh.noarch --- Package perl-ExtUtils-Embed.noarch 0:1.28-164.fc15 will be gelöscht --- Package perl-ExtUtils-MakeMaker.noarch 0:6.56-164.fc15 will be gelöscht -- Verarbeite Abhängigkeiten: perl(ExtUtils::MakeMaker) für Paket: perl-CPAN-1.9402-164.fc15.noarch --- Package perl-ExtUtils-ParseXS.noarch 1:2.2206-164.fc15 will be gelöscht --- Package perl-Test-Harness.noarch 0:3.17-164.fc15 will be gelöscht --- Package perl-Test-Simple.noarch 0:0.98-1.fc15 will be gelöscht -- Führe Transaktionsprüfung aus --- Package perl-CPAN.noarch 0:1.9402-164.fc15 will be gelöscht --- Package perl-SOAP-WSDL.noarch 0:2.00.10-10.fc15.20111201.rh will be gelöscht -- Verarbeite Abhängigkeiten: perl(SOAP::WSDL) für Paket: perl-Net-DRI-0.96-2.fc15.20111201.rh.noarch -- Verarbeite Abhängigkeiten: perl-SOAP-WSDL für Paket: perl-Net-DRI-0.96-2.fc15.20111201.rh.noarch -- Führe Transaktionsprüfung aus --- Package perl-Net-DRI.noarch 0:0.96-2.fc15.20111201.rh will be gelöscht -- Abhängigkeitsauflösung beendet lounge-buildserver | 2.9 kB 00:00 ... lounge-cache | 2.9 kB 00:00 Abhängigkeiten aufgelöst Paket Arch Version RepositoryGrösse Entfernen: apr-devel x86_64 1.4.5-1.fc15.20111201.rh @lounge-buildserver 767 k
Re: /usrmove?
On Fri, Feb 10, 2012 at 12:42 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 10.02.2012 10:06, schrieb Jóhann B. Guðmundsson: The state of overall migration to systemd is depended on each package maintainer(s) and at current rate that wont be finished until F20+. so fedora has STOPPED to be a distribution it is a bundle of packages which hopefully work together and nobody feels repsonsible for anything, things may happen or not or somewhere in a undefined fuuture the definition of a distribution is that all packages are comonig from one central source (repos) and are optimized to work together and not everybody does like he feel and if things are not badly enough broken they will not be touched I quite agree this is (becoming?) a problem - but can you suggest a workable solution? What can FESCo practically do when tens of packagers simply ignore the bugs filed against their components? More importantly, what can FESCo practically do when a component has an abrt bug open for 5 months, roughly 1 new reporter per day is added, and the package owner has not done a single action in bugzilla? [1] If the answer is kick the package out of the distribution, I'm sad to say the distribution would have some glaring holes. We really need to find a good solution for these cases, or Fedora will, as you say, stop being a distribution. So far, the best I idea can think of is to open up provenpackager access much more, and make it much more acceptable to use it - but that would bring problems of its own. Mirek [1] Yes, this really exists. Another similarly widely-reported bug took 4 months to fix, and I've informally been told there are quite a few such cases. In both cases details withheld, fingerpointing won't help answer the question above. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Am 10.02.2012 12:55, schrieb Matthias Runge: On 10/02/12 12:45, Tomas Mraz wrote: I hope that this is just sarcasm. Many of the reasons were refuted to not be real. Of course there are still some positive reasons remaining but they are very weak in comparison to the break of expectations of existing users and developers of 3rd party software. So if you mainly ignore the existing expectations you might come to a conclusion that this feature is a net gain however this is by no means certain thing and undisputable. I think, there are good reasons to move. Doing it, mainly because of others do, is not such a good reason for me what missed here is the main point: there is no single bleding wound to do it NOW under pressure nobody would have been died if F17 would have bean left in peace and the feature would been introduced in F18 or even F19 because it brings no single benefit NOW especially the /usrmove could have been started by changing the locations in single packages to get /usr and /sbin empty step by step instead forcing a big change with pressure and a lot of problems making a change for the sake of the change is not wise signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Module-Implementation] Created tag perl-Module-Implementation-0.05-1.el6
The lightweight tag 'perl-Module-Implementation-0.05-1.el6' was created pointing to: be51602... Update to 0.05 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Implementation] Created tag perl-Module-Implementation-0.05-1.fc16
The lightweight tag 'perl-Module-Implementation-0.05-1.fc16' was created pointing to: be51602... Update to 0.05 -- 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: /usrmove?
Ralf Corsepius wrote: Let me put it this way: I am having difficulties in recalling any Fedora release which worked for me out of the box ... In earlier releases there for example were pulseaudio and SELinux, in current releases it's primarily systemd What kind of problems in the out of the box setup are you seeing with systemd? Could you give me any Bugzilla links? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 6:42 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 10.02.2012 10:06, schrieb Jóhann B. Guðmundsson: The state of overall migration to systemd is depended on each package maintainer(s) and at current rate that wont be finished until F20+. so fedora has STOPPED to be a distribution it is a bundle of packages which hopefully work together and nobody feels repsonsible for anything, things may happen or not or somewhere in a undefined fuuture I think there's some truth in that statement, except for the nobody feels responsible part. FESCo and many other community members try very hard to ensure the packages in the distribution are not broken, don'.t cause a bad user experience, and are generally robust. the definition of a distribution is that all packages are comonig from one central source (repos) and are optimized to work together and not everybody does like he feel and if things are not badly enough broken they will not be touched That is the definition of a product. Fedora has never been a product. Fedora is a community driven distribution and as such has no central or overriding authority to tell people that volunteer their time to go do some specific thing they don't feel like doing. At best, FESCo can tell people no. However, they'd have to know about something bad before it happened, and there are far too many packages to monitor in that fashion under today's setup. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 10.02.2012 12:59, schrieb Miloslav Trmač: On Fri, Feb 10, 2012 at 12:42 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 10.02.2012 10:06, schrieb Jóhann B. Guðmundsson: The state of overall migration to systemd is depended on each package maintainer(s) and at current rate that wont be finished until F20+. so fedora has STOPPED to be a distribution it is a bundle of packages which hopefully work together and nobody feels repsonsible for anything, things may happen or not or somewhere in a undefined fuuture the definition of a distribution is that all packages are comonig from one central source (repos) and are optimized to work together and not everybody does like he feel and if things are not badly enough broken they will not be touched I quite agree this is (becoming?) a problem - but can you suggest a workable solution? calm down new features because you see now what happended What can FESCo practically do when tens of packagers simply ignore the bugs filed against their components? learn from what has happened? More importantly, what can FESCo practically do when a component has an abrt bug open for 5 months, roughly 1 new reporter per day is added, and the package owner has not done a single action in bugzilla? has anybody spent a thought that the reason maybe that more and more maintainers are getting frustrated about the way big changes brought up by some people are introduced forcing all maintainers to act and that the number of such changes in a short timeframe is the reason? If the answer is kick the package out of the distribution, I'm sad to say the distribution would have some glaring holes. We really need to find a good solution for these cases, or Fedora will, as you say, stop being a distribution. a good solution would be NOT introduce in each release BIG changes NOT frustrade maintainers which a lot of work until they do no longer see the horizon because at the moment they have finished one change the next is brought up under pressure more and more of them will giving up or start workaround somehow about the probblems but not having the energy do this clean because they all have a real life, have to maintain F-1, F-N, F-N+1 the release schedule of fedora is no longer working good with this pressure at each release and will sooner or later stop completly if people do not change the way fedora as distribution acts POSSIBLE SOLUTION: each second release does not introduzce those big changes and only optimize existing things and bringing only new versions of packages require a simple mass rebuild for so-changes you can call it F17, F17.5 where F17 have a big chnage affecting the whole distribution and F17.5 is only a careful upgrade without intention to break stuff and require actions from all involved people take away the current pressure from maintainers as well users give the involved people time to breath this is opensource, there is NO SINGLE NEED to implement any possible good idea under pressure NOW and beeing first only for beeing first is not always the right hting signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 10/02/12 13:01, Reindl Harald wrote: what missed here is the main point: there is no single bleding wound to do it NOW under pressure nobody would have been died if F17 would have bean left in peace and the feature would been introduced in F18 or even F19 because it brings no single benefit NOW You're absolutely right. There's no need to hurry. This was not, was I was discussing. My point was: If everybody does it, why don't we do it? Comparable to: 1000 flies can not be mistaken, shit must be great. Having no other reason than 'everybody does it' is imho a bad reason. -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
On 2012-02-10, Reindl Harald h.rei...@thelounge.net wrote: that devel-packages require other devel-packages is OK but that you need ANY devel-package on machines having not installed any compiler/packaging-software not You can have a tool which creates binding to native shared objects at run-time. Then header files are good input for such generator. OTOH such tool is usuallay a developer tool. This is just to show each rule hase an exception. package-maintainers should have some CLEAN virtual machine to test if their new versions are introducing new dependencies Packager can check it using rpmdiff on old and updated package. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 10/02/12 12:13, Matthias Runge wrote: My point was: If everybody does it, why don't we do it? Comparable to: 1000 flies can not be mistaken, shit must be great. They're sowing Mushrooms. Which people fry, boil, smoke. ;) -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 10:49 AM, Ralf Corsepius wrote: On 02/10/2012 10:06 AM, Jóhann B. Guðmundsson wrote: On 02/10/2012 04:45 AM, Ralf Corsepius wrote: In this spirit, I eg. would propose to table usrmove for F17 and to concentrate on systemd integration and anaconda/grub2 improvements, both topics, I perceived as the hall of shame of F16. Better systemd integration of services is not going to happen I can just tell you that here and now Why not? Users are supposed to struggle with the swamp/mess the systemd integration currently is in? Could it be systemd reached its design limitations (== is a failure)? In a perfect world users should not have to struggle with anykind of mess systemd integration currently is or any other project for that matter but then again arguably we would not make any progress et all... Systemd does not suffer from any kind of design limitation that I'm aware of so you need to be a bit more specific than this and point them out to me what you think they are? However the systemd migration process has shown that the project suffers from limitations in so many ways. Don't get me wrong, I am honestly asking, because I don't know and because it's in general not uncommmon to see promissing developments to reach 90% of its goals in 10% of the projected time, but to never cover the remaining 10% - Often because for limitations of the design. Again limitation in design is not a factor here and the people behind this particular project are flexible enough to extent that scope should it ever become necessary. Systemd itself is as complete as any other development project for it's age. Bugs are being fixed and new features are being introduced as are with any project that is actively being worked on. unless fesco brings fourth the big hammer or packagers get their act together. That's what I meant my responsibility. I am asking the people in charge to draw consequences. If anyone is to blame for the current state it's the package maintainers. The distribution will never be better then the packages they ship and their relevant maintainers so if you want to improve the overall quality of the distribution you will have to do so in the roots of the project. This could be to bring out the hammer, it could be to revert, it could be Red Hat to delegate personnel, it could be volunteers to jump in, to bring this unpleasant topic to a proper end. Bringing out the big hammer which would be in this case to *force* migration or the package will be removed from the distribution is a last resource solution which is why FESCO. Reverting is not an option at this stage and even considering is nonsense. For an distribution that should be striving to become self sufficient running to or otherwize expecting an sponsor to throw in personal when tough gets going is a bit backwards don't you think... The said state of systemd migration only reflects the said state of package maintainership in the distribution... Well, I do not share this view. IMO, it reflects the attitude of the people behind this development. No the current state of systemd migration has everything to do with relevant package maintainers in the distribution not systemd not fesco not fpc not someone else and refusing to accept that fact wont make that problem go away. I've been responsible for overseeing this migration in the project or feature if your will and I dont need to be told what and where the problems are I already know... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 11:59 AM, Miloslav Trmač wrote: On Fri, Feb 10, 2012 at 12:42 PM, Reindl Haraldh.rei...@thelounge.net wrote: Am 10.02.2012 10:06, schrieb Jóhann B. Guðmundsson: The state of overall migration to systemd is depended on each package maintainer(s) and at current rate that wont be finished until F20+. so fedora has STOPPED to be a distribution it is a bundle of packages which hopefully work together and nobody feels repsonsible for anything, things may happen or not or somewhere in a undefined fuuture the definition of a distribution is that all packages are comonig from one central source (repos) and are optimized to work together and not everybody does like he feel and if things are not badly enough broken they will not be touched I quite agree this is (becoming?) a problem - but can you suggest a workable solution? What can FESCo practically do when tens of packagers simply ignore the bugs filed against their components? More importantly, what can FESCo practically do when a component has an abrt bug open for 5 months, roughly 1 new reporter per day is added, and the package owner has not done a single action in bugzilla? [1] If the answer is kick the package out of the distribution, I'm sad to say the distribution would have some glaring holes. We really need to find a good solution for these cases, or Fedora will, as you say, stop being a distribution. So far, the best I idea can think of is to open up provenpackager access much more, and make it much more acceptable to use it - but that would bring problems of its own. Mirek [1] Yes, this really exists. Another similarly widely-reported bug took 4 months to fix, and I've informally been told there are quite a few such cases. In both cases details withheld, fingerpointing won't help answer the question above. Agreed The ownership model is playing a big role in systemd migration feature incompletion's along with inefficient package cleanup process as well along with the whole the definition of the feature process. Expecting feature of this magnitude to be completed in one release cycle is just unrealistic and try to make it adhere to the same laws as introducing some new application or an feature in application is just absurd .. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? (missing responsibility)
Am 10.02.2012 13:07, schrieb Josh Boyer: That is the definition of a product. Fedora has never been a product. Fedora is a community driven distribution and as such has no central or overriding authority to tell people that volunteer their time to go do some specific thing they don't feel like doing. and that is the root cause nothing in life works without clear rules if a distribution starts soemthing like systemd-transition or /usrmove it needs clearly resposnibility and at least authority to make sure that needed work is done or if a big amount of maintainers does not needed changes to say stop in this case we can not enforce the change at all as long we have no way to make it lcean for me the switch from a redhat-controlled distribution to a complelty community-one does not work, in times before this change there was a party responsible for the coresystem these days everybody and no one is responsible for anything and hope the needed work is done somehow from someone will not work forever signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? (missing responsibility)
You couldn't force voluntary contributors to anything as you could for example not be forced to contribute to the fedora project as well. So how should this work? On Fri, Feb 10, 2012 at 1:01 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 10.02.2012 13:07, schrieb Josh Boyer: That is the definition of a product. Fedora has never been a product. Fedora is a community driven distribution and as such has no central or overriding authority to tell people that volunteer their time to go do some specific thing they don't feel like doing. and that is the root cause nothing in life works without clear rules if a distribution starts soemthing like systemd-transition or /usrmove it needs clearly resposnibility and at least authority to make sure that needed work is done or if a big amount of maintainers does not needed changes to say stop in this case we can not enforce the change at all as long we have no way to make it lcean for me the switch from a redhat-controlled distribution to a complelty community-one does not work, in times before this change there was a party responsible for the coresystem these days everybody and no one is responsible for anything and hope the needed work is done somehow from someone will not work forever -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 05:28 AM, Olav Vitters wrote: On Fri, Feb 10, 2012 at 01:11:06AM +0100, Kevin Kofler wrote: Yes, I'm arguing that the feature is undesirable by design and should not have been approved, not for Fedora 17, not for Fedora 18, not even for Fedora 31337. It has been approved, other distributions are following. It is very Hmmm... a google search of linux distributions implementing usrmove only turned up Fedora related links. clear you do not want this. But at the same time, it is happening in Fedora and elsewhere (noticed openSUSE, will propose for Mageia 3). I don't think additional emails will change anything about either the feature, or your opinion. In any case, when painting I like the colour white. Though maybe in summer (slightly warmer times), I'll change my mind and choose purple. ;) -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 07:07 AM, Josh Boyer wrote: That is the definition of a product. Fedora has never been a product. Fedora is a community driven distribution and as such has no central or overriding authority to tell people that volunteer their time to go do some specific thing they don't feel like doing. True - however many of us look to fedora as the future RHEL as well. At best, FESCo can tell people no. However, they'd have to know about something bad before it happened, and there are far too many packages to monitor in that fashion under today's setup. josh As a lowly user, there is the impression that creating a sense of urgency late in the cycle and being loud and pushy are good ways to get features in. Sadly, none of those adjectives imply good design or well written software - only claims to same, oftentimes the truth is less so. While I do believe many of the features (as discussed here) have a lot of merit, the way they are arriving in fedora (esp the last year or so) is very disappointing. What can be done? (i) May I suggest new features require a review and comment period with Fesco having the final say. Features that are 'core' - should require substantial review and broader community engagement before being accepted. (ii) Limit major features to 1 per release is also crucial - if that slows dev down too much, then switch to rolling release where testing only allows major feature at a time until that one is solid and moved to production. Only then allow the next major feature into testing. I have watched with some dismay and sadness what is happening to fedora. It can be great again ... however it needs work. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? (missing responsibility)
how does package-guidelines work? if someone wants to contribute to anything he has to accept that there are rules, and yes everywhere in life are rules a community works only as long as all members are working in the same direction, if many members are not willing to do needed changes because of systemd-transition as example the community has to ask if the change can done at all or if only a few contributors are ignroing outstanding work from release to release they have to be withdrawn because their contribution does simply not exist and the poor quality of their package affects the quality of the distribution at all a community project which wnats to do big changes can not work witout rules over the long, if fedora will act forever in this few people introduce a big change, many involved people ignore that their help is needed as they are responsible for packages and finally nobody is responsible for anything sooner or later fedora will die and each big change like systemd-transition, /usrmove... is one step closer to the dead of the project at all yes, drastical words, but hopefully it helps that people start thinking about the future at all before it is too late Am 10.02.2012 14:04, schrieb Johannes Lips: You couldn't force voluntary contributors to anything as you could for example not be forced to contribute to the fedora project as well. So how should this work? On Fri, Feb 10, 2012 at 1:01 PM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Am 10.02.2012 13:07, schrieb Josh Boyer: That is the definition of a product. Fedora has never been a product. Fedora is a community driven distribution and as such has no central or overriding authority to tell people that volunteer their time to go do some specific thing they don't feel like doing. and that is the root cause nothing in life works without clear rules if a distribution starts soemthing like systemd-transition or /usrmove it needs clearly resposnibility and at least authority to make sure that needed work is done or if a big amount of maintainers does not needed changes to say stop in this case we can not enforce the change at all as long we have no way to make it lcean for me the switch from a redhat-controlled distribution to a complelty community-one does not work, in times before this change there was a party responsible for the coresystem these days everybody and no one is responsible for anything and hope the needed work is done somehow from someone will not work forever -- devel mailing list devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Feature process (was: Re: /usrmove?)
On Fri, Feb 10, 2012 at 11:58:32AM +0100, Miloslav Trmač wrote: The feature process is currently being revised, and at least some of these issues have been brought up at https://fedoraproject.org/wiki/Fixing_features . What would be especially useful is to find ways to improve the feature process. Is it? Looking at the history of that page, there was a lot of activity on the page in June, and then a blip of activity in November, and then nothing again until this month. The deadline stated on the page for next steps is long past. It sounds like maybe you know about something going on behind the scenes that I don't? Care to share? -- Scott -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 01:34 PM, Jóhann B. Guðmundsson wrote: On 02/10/2012 10:49 AM, Ralf Corsepius wrote: On 02/10/2012 10:06 AM, Jóhann B. Guðmundsson wrote: On 02/10/2012 04:45 AM, Ralf Corsepius wrote: In this spirit, I eg. would propose to table usrmove for F17 and to concentrate on systemd integration and anaconda/grub2 improvements, both topics, I perceived as the hall of shame of F16. Better systemd integration of services is not going to happen I can just tell you that here and now Why not? Users are supposed to struggle with the swamp/mess the systemd integration currently is in? Could it be systemd reached its design limitations (== is a failure)? In a perfect world users should not have to struggle with anykind of mess systemd integration currently is or any other project for that matter but then again arguably we would not make any progress et all... Systemd does not suffer from any kind of design limitation that I'm aware of so you need to be a bit more specific than this and point them out to me what you think they are? However the systemd migration process has shown that the project suffers from limitations in so many ways. Don't get me wrong, I am honestly asking, because I don't know and because it's in general not uncommmon to see promissing developments to reach 90% of its goals in 10% of the projected time, but to never cover the remaining 10% - Often because for limitations of the design. Again limitation in design is not a factor here and the people behind this particular project are flexible enough to extent that scope should it ever become necessary. Systemd itself is as complete as any other development project for it's age. ATM, systemd integration is a semi-cooked, hardly usable mess, which still has to prove its sustainability. Not more and not less. unless fesco brings fourth the big hammer or packagers get their act together. That's what I meant my responsibility. I am asking the people in charge to draw consequences. If anyone is to blame for the current state it's the package maintainers. It's naive to expect all packager to modify their packages to adopt something they do not understand or consider to be crack. IMO, systemd integration would have been an example where a tag team would have been appropriate. This did not happen, a fact I consider to be project management mistake. This could be to bring out the hammer, it could be to revert, it could be Red Hat to delegate personnel, it could be volunteers to jump in, to bring this unpleasant topic to a proper end. Bringing out the big hammer which would be in this case to *force* migration or the package will be removed from the distribution is a last resource solution which is why FESCO. Reverting is not an option at this stage and even considering is nonsense. Well, history is full of initd systems, which been replaced before they had been fully up. I would not want to bet if systemd isn't amonst these. The said state of systemd migration only reflects the said state of package maintainership in the distribution... Well, I do not share this view. IMO, it reflects the attitude of the people behind this development. No the current state of systemd migration has everything to do with relevant package maintainers in the distribution not systemd not fesco not fpc not someone else and refusing to accept that fact wont make that problem go away. cf. above. I've been responsible for overseeing this migration in the project or feature if your will and I dont need to be told what and where the problems are I already know... Ok, then my advice to you is: Stop shifiting around responsibilities and start to work. Team up with others and start working on migrating the remaining not-converted services. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature process (was: Re: /usrmove?)
On Fri, Feb 10, 2012 at 2:14 PM, Scott Schmit i.g...@comcast.net wrote: On Fri, Feb 10, 2012 at 11:58:32AM +0100, Miloslav Trmač wrote: The feature process is currently being revised, and at least some of these issues have been brought up at https://fedoraproject.org/wiki/Fixing_features . What would be especially useful is to find ways to improve the feature process. Is it? Looking at the history of that page, there was a lot of activity on the page in June, and then a blip of activity in November, and then nothing again until this month. The deadline stated on the page for next steps is long past. It sounds like maybe you know about something going on behind the scenes that I don't? Care to share? Te dates indeed appear to be incorrect. I was referring to http://comments.gmane.org/gmane.linux.redhat.fedora.advisory-board/10356 . Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 2:09 PM, Genes MailLists li...@sapience.com wrote: (i) May I suggest new features require a review and comment period with Fesco having the final say. Features that are 'core' - should require substantial review and broader community engagement before being accepted. Good point, I have added a proposal to the FixingFeatures wiki. Thank you, Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 01:17 PM, Ralf Corsepius wrote: Ok, then my advice to you is: Stop shifiting around responsibilities and start to work. Team up with others and start working on migrating the remaining not-converted services. Excuse me? I've been working on this for 3 release cycles now and spend on average 30 minutes on each migration and I have for f15/f16 50 components that are just stuck in bugzilla with no comments or movement on them and another additional new 50 components for F17 which are also stuck with no comments or movement on them. That's total of 100 components with native systemd units attached to them with *unresponsive* maintainers... And note these are just the ones that have not been packaged and shipped I've probably one way or another had my finger in every unit that is currently being shipped in Fedora... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 01:17 PM, Ralf Corsepius wrote: ATM, systemd integration is a semi-cooked, hardly usable mess, which still has to prove its sustainability. Not more and not less. How about you actually start providing example of what you actually feel is semi cooked yata yata that you keep refereeing too? If anyone is to blame for the current state it's the package maintainers. It's naive to expect all packager to modify their packages to adopt something they do not understand or consider to be crack. IMO, systemd integration would have been an example where a tag team would have been appropriate. This did not happen, a fact I consider to be project management mistake. Yes an feature can be hold hostage should packager/maintainer not agree with fesco accepting that as feature and refuse to participate with the rest of the community. It's at same time naive to expect feature completion when that is possible... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
2012/2/10 Jóhann B. Guðmundsson johan...@gmail.com: On 02/10/2012 01:17 PM, Ralf Corsepius wrote: Ok, then my advice to you is: Stop shifiting around responsibilities and start to work. Team up with others and start working on migrating the remaining not-converted services. Excuse me? I've been working on this for 3 release cycles now and spend on average 30 minutes on each migration and I have for f15/f16 50 components that are just stuck in bugzilla with no comments or movement on them and another additional new 50 components for F17 which are also stuck with no comments or movement on them. That's total of 100 components with native systemd units attached to them with *unresponsive* maintainers... And note these are just the ones that have not been packaged and shipped I've probably one way or another had my finger in every unit that is currently being shipped in Fedora... Thank you for that, BTW, it made migrating my packages to systemd that much simpler. -J JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Johann, Aren't you provenpackager? If not this looks like the best thing to do so you push these changes yourself and considering that systemd is the initd system noone should complain as this was already approved. I bet not every packager that hasn't responded is unresponsive and have done other changes they are well aware off and postponing this upto the point when they can get familiar with your patch. Alex - Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: Ralf Corsepius rc040...@freenet.de Cc: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, February 10, 2012 3:28:06 PM Subject: Re: /usrmove? On 02/10/2012 01:17 PM, Ralf Corsepius wrote: Ok, then my advice to you is: Stop shifiting around responsibilities and start to work. Team up with others and start working on migrating the remaining not-converted services. Excuse me? I've been working on this for 3 release cycles now and spend on average 30 minutes on each migration and I have for f15/f16 50 components that are just stuck in bugzilla with no comments or movement on them and another additional new 50 components for F17 which are also stuck with no comments or movement on them. That's total of 100 components with native systemd units attached to them with *unresponsive* maintainers... And note these are just the ones that have not been packaged and shipped I've probably one way or another had my finger in every unit that is currently being shipped in Fedora... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 08:07:11AM -0500, Steve Clark wrote: On 02/10/2012 05:28 AM, Olav Vitters wrote: On Fri, Feb 10, 2012 at 01:11:06AM +0100, Kevin Kofler wrote: Yes, I'm arguing that the feature is undesirable by design and should not have been approved, not for Fedora 17, not for Fedora 18, not even for Fedora 31337. It has been approved, other distributions are following. It is very Hmmm... a google search of linux distributions implementing usrmove only turned up Fedora related links. I talked to people at FOSDEM (regarding systemd, /usr, etc). As mentioned, openSUSE is watching closely (but will wait until Fedora solves the pain). Furthermore, likely Mageia 3 (2 is not out). Regarding your Google query, I don't expect linux distributions to help you much. Quick query gives you: http://lists.opensuse.org/opensuse-factory/2011-11/msg01398.html Lots of good feedback. Initial emails are all really positive. But, IMO, often easier to ask the people who make things happen (FOSDEM, etc). -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Fri, Feb 10, 2012 at 1:13 PM, Reindl Harald h.rei...@thelounge.net wrote: [..] POSSIBLE SOLUTION: each second release does not introduzce those big changes and only optimize existing things and bringing only new versions of packages require a simple mass rebuild for so-changes you can call it F17, F17.5 where F17 have a big chnage affecting the whole distribution and F17.5 is only a careful upgrade without intention to break stuff and require actions from all involved people take away the current pressure from maintainers as well users give the involved people time to breath this is opensource, there is NO SINGLE NEED to implement any possible good idea under pressure NOW and beeing first only for beeing first is not always the right hting Well it seems that you are better suited with using a distro like RHEL (or one of its clones). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 10.02.2012 15:09, schrieb drago01: On Fri, Feb 10, 2012 at 1:13 PM, Reindl Harald h.rei...@thelounge.net wrote: [..] POSSIBLE SOLUTION: each second release does not introduzce those big changes and only optimize existing things and bringing only new versions of packages require a simple mass rebuild for so-changes you can call it F17, F17.5 where F17 have a big chnage affecting the whole distribution and F17.5 is only a careful upgrade without intention to break stuff and require actions from all involved people take away the current pressure from maintainers as well users give the involved people time to breath this is opensource, there is NO SINGLE NEED to implement any possible good idea under pressure NOW and beeing first only for beeing first is not always the right hting Well it seems that you are better suited with using a distro like RHEL (or one of its clones). no because i need current software-versions, but current does not mean broken/unfinished or baken in rush also even if i would be better suited (what is not the case) this would not change the fact that the current fedora release/devel process is broken and even as RHEL user this would cause sorrows on my side fedora would be close to a perfect distribution if there would not be so much useless feature-pressure in each release useless because if you are release every 6 months you will nothing lose spare out a big change to the next release and win overall quality and stability and at least it would not result in so many burned out maintainers which everybody can recognize if he openes his eyes currently fedira is on the best way to burn down it's contributors by blindly enforce changes an dpressure to them! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 8:09 AM, Genes MailLists li...@sapience.com wrote: On 02/10/2012 07:07 AM, Josh Boyer wrote: That is the definition of a product. Fedora has never been a product. Fedora is a community driven distribution and as such has no central or overriding authority to tell people that volunteer their time to go do some specific thing they don't feel like doing. True - however many of us look to fedora as the future RHEL as well. RHEL is a product. Fedora may be the base of that but it's a bit naive to think that it's taken directly and just shoved out the door. There is ample time to actually productize, stablize, and align RHEL. (Also, RHEL ships a substantially smaller package set than Fedora.) At best, FESCo can tell people no. However, they'd have to know about something bad before it happened, and there are far too many packages to monitor in that fashion under today's setup. josh As a lowly user, there is the impression that creating a sense of urgency late in the cycle and being loud and pushy are good ways to get features in. Sadly, none of those adjectives imply good design or well written software - only claims to same, oftentimes the truth is less so. While I do believe many of the features (as discussed here) have a lot of merit, the way they are arriving in fedora (esp the last year or so) is very disappointing. What can be done? (i) May I suggest new features require a review and comment period with Fesco having the final say. They already do. The pages are written, reviewed by the Feature wrangler, and are available for anyone to read and comment on. FESCo approves them, taking comments into account. Features that are 'core' - should require substantial review and broader community engagement before being accepted. That's already the intention. The process could perhaps use some work. I hear there are people looking into that. (ii) Limit major features to 1 per release is also crucial - if that slows dev down too much, then switch to rolling release where testing only allows major feature at a time until that one is solid and moved to production. Only then allow the next major feature into testing. Switching to a rolling release seems both drastic and orthogonal to the problem of wide-spread features. I have watched with some dismay and sadness what is happening to fedora. It can be great again ... however it needs work. Honestly, I wonder if people are focusing on and remembering only the development periods of releases as of late. Reading back through the lists during the F16 timeframe, one would have thought it was an utterly broken release that worked for noone and broke thousands of machines. Yet the final release, IMHO, seems great. I've really had no issues on any of the 4 machines running F16 (including the f16 ppc64 secondary arch release). Maybe if you're staring at the meat grinder all day the last thing you want to do is go home and eat sausage, but I do think it's important to judge a release on it's GA quality. Immediately discounting it during the Alpha and Beta phases is both premature and non-productive. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Am 10.02.2012 15:20, schrieb Josh Boyer: Maybe if you're staring at the meat grinder all day the last thing you want to do is go home and eat sausage, but I do think it's important to judge a release on it's GA quality. Immediately discounting it during the Alpha and Beta phases is both premature and non-productive. wait until GA is out and see it is broken would be the better way for you? nothing more important as trageting alpha as fature complete instead of written down wishes and go ahead looking what may happen and if features require the work of many maintainers the most important decision for the go should be that this maintainers support it actively this did NOT happen with systemd or how do you explain that we have to wait for F20 or even F25 until the feature is finsihed? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 9:25 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 10.02.2012 15:20, schrieb Josh Boyer: Maybe if you're staring at the meat grinder all day the last thing you want to do is go home and eat sausage, but I do think it's important to judge a release on it's GA quality. Immediately discounting it during the Alpha and Beta phases is both premature and non-productive. wait until GA is out and see it is broken would be the better way for you? nothing more important as trageting alpha as fature complete instead of written down wishes and go ahead looking what may happen No, that's not really what I was implying at all. I was replying to the fedora is dying with each release and it's quality is slipping and blah blah blah. and if features require the work of many maintainers the most important decision for the go should be that this maintainers support it actively They do as far as I've seen. this did NOT happen with systemd or how do you explain that we have to wait for F20 or even F25 until the feature is finsihed? Maybe those maintainers are too busy replying to your rhetoric. I don't know. I think I'll go back to not emailing devel list because it sure as hell isn't about development of the distro anymore. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Am 10.02.2012 15:31, schrieb Josh Boyer: this did NOT happen with systemd or how do you explain that we have to wait for F20 or even F25 until the feature is finsihed? Maybe those maintainers are too busy replying to your rhetoric. I don't know. I think I'll go back to not emailing devel list because it sure as hell isn't about development of the distro anymore. what the hell are you believe about what this discussion is? how many fedora upgrades did you in your live? mine are 200 since FC3 and because of this fact i would say i see the difference how they are wroked and how decisions was made as long Redhat was responsible for Fedora Core and how this happens currently where nobody feels responsible for anything and nobody can enforce anybody to do anyhting for proposed features which are blindly done but never finished nor done with care instead hurry up signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 01:46 PM, Aleksandar Kurtakov wrote: Johann, Aren't you provenpackager? If not this looks like the best thing to do so you push these changes yourself and considering that systemd is the initd system noone should complain as this was already approved. I bet not every packager that hasn't responded is unresponsive and have done other changes they are well aware off and postponing this upto the point when they can get familiar with your patch. I'm not a provenpackager and have no interested in becoming a package maintainer all thou I would not mind have the ability to fix things here and there if I came across them. ( I'm not aware if there is a role/process in the distribution for people that want to do just this ) And this process is not that simple as in we cant blindly have provenpackagers to package submitted units because in some cases upstream code changes are needed or the units aren't fully compatible with previous init script behaviour due to some unforeseeable usage of it which only the actual maintainers are aware of hence a solution for that needs to be found. I did file spec file changes along with those units to ease migration at request and guidance of Toshio which he himself or Tom packaged the units and shipped them which is why we manage to reach the set goal for last release cycle however Tom and Toshio only touched packaged they already knew they could touch in safe manner. It's best that maintainers would just ship the submitted units ( I think the window is up to beta ) atleast then the packaging part was done and the unit(s) would be in the release and they could fix them, either from feedback from users or if/when they have gotten familiar with systemd. Fixes to systemd units usually arent more then onliner changes anyway due to their simplicity. If an unit becomes bloated or complex it usually only highlights the fact that the relevant daemon lacks the ability to parse config file. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Fri, Feb 10, 2012 at 01:13:13PM +0100, Reindl Harald wrote: POSSIBLE SOLUTION: each second release does not introduzce those big changes and only optimize existing things and bringing only new versions of packages require a simple mass rebuild for so-changes you can call it F17, F17.5 where F17 have a big chnage affecting the whole distribution and F17.5 is only a careful upgrade without intention to break stuff and require actions from all involved people take away the current pressure from maintainers as well users give the involved people time to breath this is opensource, there is NO SINGLE NEED to implement any possible good idea under pressure NOW and beeing first only for beeing first is not always the right hting I think this would increase the pressure to push unpolished features into the distribution. Allowing big feature changes only every two releases means that the waiting time should the feature not get merged is 12 months. For some features that's quite unacceptable. So the likely effect is that these features will be called ready whenever they need to be (according to the process) with the rest simply called optimizing. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PCRE 8.30 will break API
Richard W.M. Jones wrote: Actually ocaml-pcre-devel is the one which requires pcre-devel. I don't think this is against any guidelines, or if it is, it shouldn't be. No, that makes sense. Your message wasn't clear about that. Instead, the software MUST be patched to dlopen the fully versioned so from the runtime package instead. If I understand what you mean, the software does this already. The bug is that there's no explicit (or implicit) dependency to tell RPM that it's doing this. There needs to be at least a Requires: pcre. I guess a Requires on the exact soname being dlopened would be more robust, but then you need to take care of that pesky '()(64bit)' multilib suffix. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Translation
Fedora packages maintainers It is Software String Freeze on 14th February next week Tuesday. From this point, Fedora translators for over 40 languages exert every possible effort to complete software translation 100%. So please make sure that your package's latest translatable file is pushed/uploaded and available at Transifex BY THIS DATE. Silent string freeze break can cost translation task. If it needs to happen please tell us at trans at lists, so that we can address it. Thanks noriko Fedora Localization Project ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 10.02.2012 16:06, schrieb Peter Hutterer: On Fri, Feb 10, 2012 at 01:13:13PM +0100, Reindl Harald wrote: POSSIBLE SOLUTION: each second release does not introduzce those big changes and only optimize existing things and bringing only new versions of packages require a simple mass rebuild for so-changes you can call it F17, F17.5 where F17 have a big chnage affecting the whole distribution and F17.5 is only a careful upgrade without intention to break stuff and require actions from all involved people take away the current pressure from maintainers as well users give the involved people time to breath this is opensource, there is NO SINGLE NEED to implement any possible good idea under pressure NOW and beeing first only for beeing first is not always the right hting I think this would increase the pressure to push unpolished features into the distribution. Allowing big feature changes only every two releases means that the waiting time should the feature not get merged is 12 months. For some features that's quite unacceptable. So the likely effect is that these features will be called ready whenever they need to be (according to the process) with the rest simply called optimizing. if people do not care the can destroy every process if someone calls repeatly non-ready features as ready he is the wrong person for any sort of decision maybe the project should get rid of some people who do not care or guidelines which have the power to ENFORCE contributors or get rid of them yes this may sound hard but what is the alternative? burn down ressources with each relese more and more signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
- Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Friday, February 10, 2012 10:43:07 AM Subject: Re: /usrmove? - about the future Am 10.02.2012 16:06, schrieb Peter Hutterer: On Fri, Feb 10, 2012 at 01:13:13PM +0100, Reindl Harald wrote: POSSIBLE SOLUTION: each second release does not introduzce those big changes and only optimize existing things and bringing only new versions of packages require a simple mass rebuild for so-changes you can call it F17, F17.5 where F17 have a big chnage affecting the whole distribution and F17.5 is only a careful upgrade without intention to break stuff and require actions from all involved people take away the current pressure from maintainers as well users give the involved people time to breath this is opensource, there is NO SINGLE NEED to implement any possible good idea under pressure NOW and beeing first only for beeing first is not always the right hting I think this would increase the pressure to push unpolished features into the distribution. Allowing big feature changes only every two releases means that the waiting time should the feature not get merged is 12 months. For some features that's quite unacceptable. So the likely effect is that these features will be called ready whenever they need to be (according to the process) with the rest simply called optimizing. if people do not care the can destroy every process if someone calls repeatly non-ready features as ready he is the wrong person for any sort of decision maybe the project should get rid of some people who do not care or guidelines which have the power to ENFORCE contributors or get rid of them yes this may sound hard but what is the alternative? burn down ressources with each relese more and more Hi, Where can I review your formal submission(s) for such improvements? Thanks, Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora major feature introduction; was Re: /usrmove?
On 02/09/2012 11:45 PM, Ralf Corsepius wrote: Let me put it this way: I am having difficulties in recalling any Fedora release which worked for me out of the box ... ... That said, IMO, on the technical side, Fedora urgently needs a calming down/lean back/settlement phase, say 2 consecutive Fedora releases without revolutionary features being introduced, to revisit re-evaluate, revert/complete old revolutionary features. To me, Fedora is the Linux RD lab, and the releases are designed to introduce new features. Still, you have a point about the worrying number of defects (I am personally affected by one of those: my X is misbehaving now, with terrible latency and update performance)---but I think we need to adjust the process rather than make strategic retreats. Specifically, in my opinion the major developments should be planned and announced in a more organized way: - they are first proposed, discussed, adopted and announced in the timeframe of 1 or 2 releases before the release they go in. - they are introduced, on schedule and as a matter of process, into rawhide at the start of the cycle, rather than midstream or late. There are of course difficulties with this approach: first, it could slow down the development just because it adds steps to the process. Perhaps more importantly, many important improvements are driven by small groups or individuals (Lennart's systemd, and even usrmove) and this process would open the discussion much wider and earlier; there would likely be more opposition. The FESCO would have to pitch in and stand behind the project and its lonely champion after adopting it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 10.02.2012 16:49, schrieb Steve Gordon: - Original Message - From: Reindl Harald h.rei...@thelounge.net So the likely effect is that these features will be called ready whenever they need to be (according to the process) with the rest simply called optimizing. if people do not care the can destroy every process if someone calls repeatly non-ready features as ready he is the wrong person for any sort of decision maybe the project should get rid of some people who do not care or guidelines which have the power to ENFORCE contributors or get rid of them yes this may sound hard but what is the alternative? burn down ressources with each relese more and more Where can I review your formal submission(s) for such improvements? they do not exist because fedoras feature-quality at release burns down way to much of my time to maintain 20 machines with fedora and rebuild half of the distribution to fix design bugs so if the releases would be more well thought i would have time to write such things, but then there would be no need for it signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Fri, Feb 10, 2012 at 16:57:18 +0100, Reindl Harald h.rei...@thelounge.net wrote: so if the releases would be more well thought i would have time to write such things, but then there would be no need for it Consider running for FESCO this spring and emphasize your views on features in your campaign. While I don't think the problem is as bad as you think, but I would like to see features that have distro wide impact land much earlier. For example I would have preferred usrmove to target F18 rather than (mostly) land at the F17 branching. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Image-ExifTool-8.77.tar.gz uploaded to lookaside cache by spot
A file has been added to the lookaside cache for perl-Image-ExifTool: 33c9c7b9a0153390374910e9da652487 Image-ExifTool-8.77.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: PCRE 8.30 will break API
On Fri, Feb 10, 2012 at 04:24:43PM +0100, Kevin Kofler wrote:
Richard W.M. Jones wrote:
Actually ocaml-pcre-devel is the one which requires pcre-devel. I
don't think this is against any guidelines, or if it is, it shouldn't
be.
No, that makes sense. Your message wasn't clear about that.
Instead, the software MUST be patched to dlopen the fully versioned
so from the runtime package instead.
If I understand what you mean, the software does this already. The
bug is that there's no explicit (or implicit) dependency to tell RPM
that it's doing this.
There needs to be at least a Requires: pcre. I guess a Requires on the exact
soname being dlopened would be more robust, but then you need to take care
of that pesky '()(64bit)' multilib suffix.
Well now, now that everything's in the same directory, can't we use
%{_libdir}/libpcre.so.1 :-?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Image-ExifTool/f17] update to 8.77
commit 137c17ce309d14793a2102887a480df936f74f91
Author: Tom Callaway s...@fedoraproject.org
Date: Fri Feb 10 11:27:05 2012 -0500
update to 8.77
perl-Image-ExifTool.spec |5 -
sources |2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Image-ExifTool.spec b/perl-Image-ExifTool.spec
index 017086d..b9e9a55 100644
--- a/perl-Image-ExifTool.spec
+++ b/perl-Image-ExifTool.spec
@@ -1,5 +1,5 @@
Name: perl-Image-ExifTool
-Version: 8.75
+Version: 8.77
Release: 1%{?dist}
License: GPL+ or Artistic
Group: Applications/Multimedia
@@ -51,6 +51,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Fri Feb 10 2012 Tom Callaway s...@fedoraproject.org - 8.77-1
+- update to 8.77
+
* Mon Jan 9 2012 Tom Callaway s...@fedoraproject.org - 8.75-1
- update to 8.75
diff --git a/sources b/sources
index 9f498fe..ebc9917 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c1bffbb9928353ab3a683b1d2126df9f Image-ExifTool-8.75.tar.gz
+33c9c7b9a0153390374910e9da652487 Image-ExifTool-8.77.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Image-ExifTool] update to 8.77
commit 362797cfac2eac8d9049b87f2ac0cc8608aa1f55
Author: Tom Callaway s...@fedoraproject.org
Date: Fri Feb 10 11:27:21 2012 -0500
update to 8.77
.gitignore |1 +
perl-Image-ExifTool.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e5fab42..f8001d7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ Image-ExifTool-8.25.tar.gz
/Image-ExifTool-8.60.tar.gz
/Image-ExifTool-8.65.tar.gz
/Image-ExifTool-8.75.tar.gz
+/Image-ExifTool-8.77.tar.gz
diff --git a/perl-Image-ExifTool.spec b/perl-Image-ExifTool.spec
index 017086d..b9e9a55 100644
--- a/perl-Image-ExifTool.spec
+++ b/perl-Image-ExifTool.spec
@@ -1,5 +1,5 @@
Name: perl-Image-ExifTool
-Version: 8.75
+Version: 8.77
Release: 1%{?dist}
License: GPL+ or Artistic
Group: Applications/Multimedia
@@ -51,6 +51,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Fri Feb 10 2012 Tom Callaway s...@fedoraproject.org - 8.77-1
+- update to 8.77
+
* Mon Jan 9 2012 Tom Callaway s...@fedoraproject.org - 8.75-1
- update to 8.75
diff --git a/sources b/sources
index 9f498fe..ebc9917 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c1bffbb9928353ab3a683b1d2126df9f Image-ExifTool-8.75.tar.gz
+33c9c7b9a0153390374910e9da652487 Image-ExifTool-8.77.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
serious conflicts between python pks installed via yum vs pip
I've seen this repeatedly, with often very serious consequences (complete failure of update from f15-f16 for example). Between packages installed via pip, and packages installed via yum, some packages seem to switch between e.g., numpy-1.6.1-py2.7.egg-info being installed as a file and the same name being installed as a directory. This can cause subsequent rpm update (via cpio) to abort. I don't know what's causing this, but IMO this is a serious problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: serious conflicts between python pks installed via yum vs pip
2012/2/10 Neal Becker ndbeck...@gmail.com: I've seen this repeatedly, with often very serious consequences (complete failure of update from f15-f16 for example). Between packages installed via pip, and packages installed via yum, some packages seem to switch between e.g., numpy-1.6.1-py2.7.egg-info being installed as a file and the same name being installed as a directory. This can cause subsequent rpm update (via cpio) to abort. I don't know what's causing this, but IMO this is a serious problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Never use pip outside an isolated environment (use virtualenv) H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: serious conflicts between python pks installed via yum vs pip
On 2/10/12 11:32 AM, Neal Becker wrote: I've seen this repeatedly, with often very serious consequences (complete failure of update from f15-f16 for example). Between packages installed via pip, and packages installed via yum, some packages seem to switch between e.g., numpy-1.6.1-py2.7.egg-info being installed as a file and the same name being installed as a directory. This can cause subsequent rpm update (via cpio) to abort. I don't know what's causing this, but IMO this is a serious problem. Doctor, it hurts when I do this. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: serious conflicts between python pks installed via yum vs pip
80 wrote: 2012/2/10 Neal Becker ndbeck...@gmail.com: I've seen this repeatedly, with often very serious consequences (complete failure of update from f15-f16 for example). Between packages installed via pip, and packages installed via yum, some packages seem to switch between e.g., numpy-1.6.1-py2.7.egg-info being installed as a file and the same name being installed as a directory. This can cause subsequent rpm update (via cpio) to abort. I don't know what's causing this, but IMO this is a serious problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Never use pip outside an isolated environment (use virtualenv) H. Really? This is the only answer? Can't we tweek rpm/yum to accomodate this? Does anyone understand what is causing it? Why would pip install the egg-info differently than rpm? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 11:58:32AM +0100, Miloslav Trmač wrote: On Fri, Feb 10, 2012 at 5:45 AM, Ralf Corsepius rc040...@freenet.de wrote: Wrt. F17: usrmove - Independently from the fact that I consider it to be an idotic foolishness, ask yourself if it is a shape to be part of F17? IMO, it's foreseeable it will not be ready, because there are too many unknows attached to it. I now would expect those people having been involved to stand up, show responsibility and revisit their decisions - This obiviously doesn't happen. At the moment the feature was again brought up to FESCo two weeks ago, the commits were already in the repository, so reverting the feature would have had a pretty big cost; as much as I oppose the idea of UsrMove, I didn't think reverting it was worth it at that time, and I don't think it is worth it now - the situation is not that hopeless to call for a comparatively extreme measure. (Also, a large part of FESCo clearly wants this, and I don't think reverting features just because elections happened in the mean time is a good idea.) Just a note -- if this is the case, then the contingency planning portion of the Feature Process is broken. If it is, the changes to fix it could be a big pain... For instance, at X milestone, features that fesco is afraid won't make it are required to run through their contingency plan to make sure that it is doable and extimate cost to revert... falout of this is that with the extra work, some features might miss the deadline because they optimistically felt they wouldn't fall into this category... OTOH, if fit and polish of the GA is the criteria, perhaps this isn't a bad thing.) Note that I didn't get the impression from reading the FESCo logs that they felt the contingency plan was too big to invoke at their last discussion of UsrMove so I'm not certain that this is something that needs attention. Yes, FESCo * should have recognized early that the scope of the feature was not thought through and that more pieces are needed (contrary to claims back in the end of October that everything is already implemented and works) nod So one idea would be that a specific FESCo member needs to step up to be the collaboration guide (Must think of a better name for that :-) for a feature. They would be in charge of the feature, watch it as it evolves. Pick apart all the points where it requires coordination with other groups. And make sure that those groups were informed that the feature was in progress. * probably should have asked for an advance approval from FPC (although, as a general rule, I think advance approval from FPC lengthens the feature cycle too much and should be avoided) When I saw the feature, I brought it to FPC for an initial look. We gave it a cursory look in 10 minutes during open floor of one session and gave the recommendation that we would likely find that the /bin/ /sbin/ portion of the feature would not be allowed by us but the / to /usr portion would. Unfortunately, rather than taking that and modifying the Feature before sending it on to FPC, the Feature Owners and FESCo chose to send the feature with the /bin/ /sbin/ merge in it to us. That caused debate, discussion, and examination for at least one whole meeting. This portion could easily have been avoided if people had taken the pre-recommendation from FPC seriously. The implementation changes that occurred after the proposal was officially sent to FPC and lack of a workable method of properly controlling the upgrade experience until FPC made that a requirement also took time. One possible interpretation of that is that the feature owners or fesco should have gotten those figured out before it got to FPC. Another interpretation is that FPC was a second set of eyes that did what they were supposed to by finding the flaws and forcing them to be fixed -- in that case, though, you can hardly say that the lengthening of the time taken to approve the feature was misspent. * and should have monitored the progress more closely. nod - that would go along with the idea of having a particular FESCo member be in charge of tracking the feature and making sure it was on track. The feature process is currently being revised, and at least some of these issues have been brought up at https://fedoraproject.org/wiki/Fixing_features . What would be especially useful is to find ways to improve the feature process. +1. I'm perfectly capable of figuring out bad ways to fix the feature process (See my off the cuff thought on contingency plans, above ;-) If someone has ideas that are less costly, that would help a lot so there is a half-way decent proposed solution for the first strawman proposal. -Toshio pgpGqGg3uqTqV.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feature process (was: Re: /usrmove?)
On Fri, Feb 10, 2012 at 02:20:25PM +0100, Miloslav Trmač wrote: On Fri, Feb 10, 2012 at 2:14 PM, Scott Schmit i.g...@comcast.net wrote: On Fri, Feb 10, 2012 at 11:58:32AM +0100, Miloslav Trmač wrote: The feature process is currently being revised, and at least some of these issues have been brought up at https://fedoraproject.org/wiki/Fixing_features . What would be especially useful is to find ways to improve the feature process. Is it? Looking at the history of that page, there was a lot of activity on the page in June, and then a blip of activity in November, and then nothing again until this month. The deadline stated on the page for next steps is long past. It sounds like maybe you know about something going on behind the scenes that I don't? Care to share? Te dates indeed appear to be incorrect. I was referring to http://comments.gmane.org/gmane.linux.redhat.fedora.advisory-board/10356 Yes, it's been stalled for a while. I've taken it up as a responsibility to get it moving again. I think that part of it will be changing the deadlines at which things can and/or need to be done. Since I've heard a lot of clamour that some features need to be started very soon after branch (which happened a few days ago), full changes to the policy will likely not happen until after F18 (but some changes may be implementable before). -Toshio pgpKvwHnlmZ7c.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 01:05 PM, Michal Schmidt wrote: Ralf Corsepius wrote: Let me put it this way: I am having difficulties in recalling any Fedora release which worked for me out of the box ... In earlier releases there for example were pulseaudio and SELinux, in current releases it's primarily systemd What kind of problems in the out of the box setup are you seeing with systemd? I have been facing 3 kind of major issues related to systemd: a) yum upgrading from f14-f16 did not cleanup /etc/rc?.d, leaving dangling symlinks behind, seemingly causing systemd to get confused. In some cases the machines fortunately came up to a point, I could manually clean up the symlinks. b) Machines not coming up properly after upgrades and sending me into - In one case, seemingly xserver failed, ... I found myself on console filed with systemd error messages, with no option to do anything. - In another case, I ended up in some sort of systemd emergency shell, confronted with some cryptic error messages, which left me clueless (I know how to use an emergency shell, it's just that I had no idea what to do about these error messages) c) Systemd doesn't seem to preserve existing activated services upon update (I recall having to manually activate cron and rsyslog). There are other minor issues, which sporadically show up, such as some network related services (vsftpd, yp, named, ntpd, autofs, ...) not coming up after reboots, but I am not sure if it's really systemd who is to blame or something else. Could you give me any Bugzilla links? Unfortunatly, except of the vsftpd issue, no - My fault, sorry, but when upgrading, I am focusing on getting the machine up again ;) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 5:39 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Fri, Feb 10, 2012 at 11:58:32AM +0100, Miloslav Trmač wrote: At the moment the feature was again brought up to FESCo two weeks ago, the commits were already in the repository, so reverting the feature would have had a pretty big cost; as much as I oppose the idea of UsrMove, I didn't think reverting it was worth it at that time, and I don't think it is worth it now - the situation is not that hopeless to call for a comparatively extreme measure. (Also, a large part of FESCo clearly wants this, and I don't think reverting features just because elections happened in the mean time is a good idea.) Just a note -- if this is the case, then the contingency planning portion of the Feature Process is broken. If it is, the changes to fix it could be a big pain... For instance, at X milestone, features that fesco is afraid won't make it are required to run through their contingency plan to make sure that it is doable and extimate cost to revert... falout of this is that with the extra work, some features might miss the deadline because they optimistically felt they wouldn't fall into this category... OTOH, if fit and polish of the GA is the criteria, perhaps this isn't a bad thing.) Note that I didn't get the impression from reading the FESCo logs that they felt the contingency plan was too big to invoke at their last discussion of UsrMove so I'm not certain that this is something that needs attention. No, this wasn't discussed by FESCo - that's just my personal rationale for being reluctant to push for reverting the feature. Reverting a large-scale feature will always cause some amount of pain, that's unavoidable and, given how rarely we revert features, I don't think it's a real problem. In this case, the changes were committed to the master branch, which both made it more difficult to revert the feature and made life for pretty much every packager more difficult for some time. AFAIK it is not currently possible to create a public feature-specific git branch; is that something worth considering? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 05:53 PM, Ralf Corsepius wrote: [... issues after upgrades ...] We fix them when we know about them. c) Systemd doesn't seem to preserve existing activated services upon update (I recall having to manually activate cron and rsyslog). Not preserving the enablement state of services when migrating from SysV was mandated by FPC+FESCo. systemd developers dislike the guideline just like you do. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Fri, 2012-02-10 at 13:13 +0100, Reindl Harald wrote: I quite agree this is (becoming?) a problem - but can you suggest a workable solution? calm down new features because you see now what happended On a point of fact: what _is_ it that you are suggesting happened exactly? Everyone on this list is well aware of the fact that you consider systemd a terrible failure because not every package in Fedora yet has systemd-native init scripts, but by the same token, it is clear that almost no-one agrees with you. On a solid practical level, I am not aware that systemd is currently the source of any major problems in Fedora 15, 16 or 17. I have not seen systemd identified as a major problem by any independent review of Fedora. I have not seen it brought it up as a major issue in any kind of release readiness or validation context. So your use of systemd as an example of the feature process being a terrible idea seems like a weak choice. The only other actual real-world feature that has been cited in the present discussion is /usr move. Aside from the FESCo discussion about whether they could have handled its feature approval better, on a solid practical level, the feature landed in Rawhide and so far as I know has caused no major problems for anyone who's migrated to it: I have seen none such reported. It has not prevented us from building composes, nor has it stopped those composes working. The code to handle /usr move in anaconda actually landed a couple of days ago, and should be included in Alpha TC2, which was released yesterday. Personally, I quite simply don't agree with the entire foundation of your argumentation in this thread. You suggest that the rapid pace of feature development in general is causing terrible problems for the distro, and cite systemd and /usr move as examples; I simply don't see that your examples back up your contention. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: serious conflicts between python pks installed via yum vs pip
2012/2/10 Neal Becker ndbeck...@gmail.com: Really? This is the only answer? Can't we tweek rpm/yum to accomodate this? Does anyone understand what is causing it? Why would pip install the egg-info differently than rpm? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Python guidelines recommends that packagers installs python eggs using distutils (python setup.py install as recommended in guidelines) while pip use the same install method as easy_install (provided by setuptools/distribute). The former one install egg metadata as a file, the latter as a directory, that's not a packaging/rpm issue. @+ H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 10.02.2012 18:05, schrieb Adam Williamson: On Fri, 2012-02-10 at 13:13 +0100, Reindl Harald wrote: Everyone on this list is well aware of the fact that you consider systemd a terrible failure because not every package in Fedora yet has systemd-native init scripts, but by the same token, it is clear that almost no-one agrees with you. On a solid practical level, I am not aware that systemd is currently the source of any major problems in Fedora 15, 16 or 17. F15 was horrible broken mysqld in F15 was horrible broken F15 was the first Linux i saw where reboot did not work until you typed kill 1 while praying! if no one agress that is unacceptable that init-system is changed in F15 and F17 still contains not converted services then no one knows how quality looks like for me there are two options * doing a change and doing it completly * doing not the change at all if maintainers can not be forced to convert their services and maintain their packages properly the distribution lacks needed authority - and NO freedom and do what you want does not work always and in every context Personally, I quite simply don't agree with the entire foundation of your argumentation in this thread. You suggest that the rapid pace of feature development in general is causing terrible problems for the distro, and cite systemd and /usr move as examples; I simply don't see that your examples back up your contention. as long as /usrmove requires something else than yum distro-sync for a working upgrade the feature is broken at all other examples from the past: KDE4.0, put in a pre-alpha state in F9, completly unuseable because someone HEARED it MAY be ready until end of GA cycle someone heard, thought and expected that something is ready is the wrong argument for decisions - if i want to pray i go in a church. this has nothing to search in software-development pulseuadio was horrible broken and did not work on any of my machines for some releases systemd is not finished until now and 20 releases behind upstream in F15, half of the packages are not converted your definition and my definition of quality are complete incompatible signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17 compose
Has there been a compose against F17, that would therefore create the images dir and boot.iso and everything so can install against it? -- Mike Chambers Madisonville, KY Best little town on Earth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Fri, Feb 10, 2012 at 8:21 AM, Reindl Harald h.rei...@thelounge.net wrote: F15 was the first Linux i saw where reboot did not work until you typed kill 1 while praying! Can you point me to a bug report from you or anyone else that has been confirmed by at least one other person? I personally didn't experience that with the F15 systems I had. But maybe I got lucked and dodged a bullet. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, 2012-02-10 at 17:53 +0100, Ralf Corsepius wrote: c) Systemd doesn't seem to preserve existing activated services upon update (I recall having to manually activate cron and rsyslog). This is documented in the common bugs: https://fedoraproject.org/wiki/Common_F16_bugs#Upgrade_from_previous_releases_resets_the_enablement_status_of_services (including my extra-special new invented word, 'enablement'!) Either FESCo or FPC, I forget which, requested that it be done this way, even though there is a tool in systemd (systemd-sysv-convert) which should have made it possible to bring over the present status of services during the upgrade. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Fri, 2012-02-10 at 18:21 +0100, Reindl Harald wrote: Am 10.02.2012 18:05, schrieb Adam Williamson: On Fri, 2012-02-10 at 13:13 +0100, Reindl Harald wrote: Everyone on this list is well aware of the fact that you consider systemd a terrible failure because not every package in Fedora yet has systemd-native init scripts, but by the same token, it is clear that almost no-one agrees with you. On a solid practical level, I am not aware that systemd is currently the source of any major problems in Fedora 15, 16 or 17. F15 was horrible broken mysqld in F15 was horrible broken My servers ran F15 for six months. Never had a problem with mysql. As I recall, your issues with mysql were to do with a specific fairly advanced use case, hardly general-purpose stuff. F15 was the first Linux i saw where reboot did not work until you typed kill 1 while praying! I ran F15 on four machines for months, didn't have that problem. If lots of people had, I would have expected to hear a lot more noise. if no one agress that is unacceptable that init-system is changed in F15 and F17 still contains not converted services then no one knows how quality looks like I don't agree, no. systemd was explicitly written to be 100% sysv-compatible because everyone involved knew perfectly well that sysv init scripts would stick around for years. That outcome was entirely expected and planned for. I'm not aware of any major bug caused by using a sysv init script with systemd in current Fedora. So why is it you think this is such a huge problem? for me there are two options * doing a change and doing it completly * doing not the change at all if maintainers can not be forced to convert their services and maintain their packages properly the distribution lacks needed authority - and NO freedom and do what you want does not work always and in every context Personally, I quite simply don't agree with the entire foundation of your argumentation in this thread. You suggest that the rapid pace of feature development in general is causing terrible problems for the distro, and cite systemd and /usr move as examples; I simply don't see that your examples back up your contention. as long as /usrmove requires something else than yum distro-sync for a working upgrade the feature is broken at all other examples from the past: KDE4.0, put in a pre-alpha state in F9, completly unuseable because someone HEARED it MAY be ready until end of GA cycle someone heard, thought and expected that something is ready is the wrong argument for decisions - if i want to pray i go in a church. this has nothing to search in software-development pulseuadio was horrible broken and did not work on any of my machines for some releases systemd is not finished until now and 20 releases behind upstream in F15, half of the packages are not converted your definition and my definition of quality are complete incompatible -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Fri, Feb 10, 2012 at 04:57:18PM +0100, Reindl Harald wrote: Am 10.02.2012 16:49, schrieb Steve Gordon: - Original Message - From: Reindl Harald h.rei...@thelounge.net So the likely effect is that these features will be called ready whenever they need to be (according to the process) with the rest simply called optimizing. if people do not care the can destroy every process if someone calls repeatly non-ready features as ready he is the wrong person for any sort of decision maybe the project should get rid of some people who do not care or guidelines which have the power to ENFORCE contributors or get rid of them yes this may sound hard but what is the alternative? burn down ressources with each relese more and more Where can I review your formal submission(s) for such improvements? they do not exist because fedoras feature-quality at release burns down way to much of my time to maintain 20 machines with fedora and rebuild half of the distribution to fix design bugs so if the releases would be more well thought i would have time to write such things, but then there would be no need for it I haven't seen much tangible change in the direction Fedora is heading as a result of all your emails, spending some of that time on formal suggestions for improvement may change this. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Fri, 2012-02-10 at 08:28 -0900, Jef Spaleta wrote: On Fri, Feb 10, 2012 at 8:21 AM, Reindl Harald h.rei...@thelounge.net wrote: F15 was the first Linux i saw where reboot did not work until you typed kill 1 while praying! Can you point me to a bug report from you or anyone else that has been confirmed by at least one other person? I personally didn't experience that with the F15 systems I had. But maybe I got lucked and dodged a bullet. Just upgraded an F14 machine to F15 yesterday via installing f15's fedora-release and 'yum upgrade'. I did experience this bug, but only before I'd rebooted. When the system was actually running F15 this problem does not appear and restarts work fine. But I did have to drop to a VT and manually whack the system to get it to reboot; even 'poweroff' didn't do it. Clearly that could be handled better, but honestly, we don't support this type of upgrade. Isn't our only supported upgrade path via preupgrade, which I'm assuming would handle this well? In any case, badmouthing systemd for an upgrade bug where it actually works fine *when you're really running F15* doesn't seem right. I wouldn't have had this problem if it'd installed off the Live CD or done a fresh install. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Fri, Feb 10, 2012 at 08:28:28 -0900, Jef Spaleta jspal...@gmail.com wrote: I personally didn't experience that with the F15 systems I had. But maybe I got lucked and dodged a bullet. It seems pretty common that updating systemd causes problems with the next shutdown. I don't know why and it is a pain to reproduce since it doesn't happen again on the next reboot. I don't know if there are tickets corresponding to these issues, but I have seen other people make similar observations. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/10/2012 06:33 PM, Bruno Wolff III wrote: It seems pretty common that updating systemd causes problems with the next shutdown. I don't know why and it is a pain to reproduce since it doesn't happen again on the next reboot. Did you see the problem with updates within a stable Fedora release? Or do you mean updates in Rawhide / Branched? Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 10.02.2012 18:28, schrieb Jef Spaleta: On Fri, Feb 10, 2012 at 8:21 AM, Reindl Harald h.rei...@thelounge.net wrote: F15 was the first Linux i saw where reboot did not work until you typed kill 1 while praying! Can you point me to a bug report from you or anyone else that has been confirmed by at least one other person? I personally didn't experience that with the F15 systems I had. But maybe I got lucked and dodged a bullet. no i can not because it is a one-shot thing to do yum distro-sync and so i had no time for a bugrport while other more important things like mysqld were horrible broken but this was reproduceable on all vritual machines a own including my two physical machines and the notebook of my co-developer and shows that something was not well thought or yum upgrades was never tested enough because Fedora thinks Anaconda is the way too go what is a horrible broken thing for a upgrade because you have no single chance to verify grub-config, enabled services or anything and blindly reboot in a unknown state if it boots i made 3 fedora upgrades in my life with Anaconda/Preupgrade and all 3 were horrible broken ending in a no longe rbotting machine while around 200 dist-upgrades with yum were clean and controllable - so any feature breaking yum upgrades while services are UP is a spit in my face and yes, if this braindead (sorry no other words) autorestart of services while yum upgrade is running would be controllable instead spit it in each SPEC to force rebuild all these packages would be optimized this whould make much more sense as move files from here to there wich is not interesting any user and was no problem for amny many years and is no problem currently which needs to fixed under pressure signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Fri, Feb 10, 2012 at 8:36 AM, Dan Williams d...@redhat.com wrote: In any case, badmouthing systemd for an upgrade bug where it actually works fine *when you're really running F15* doesn't seem right. I wouldn't have had this problem if it'd installed off the Live CD or done a fresh install. Shrug, I don't make it a point to do yum based upgrades across release boundaries so that would explain why i didn't encounter it. Did anyone doing and testing the not supported upgrade dance to F15 bother filing it at any point? Obviously people use it regardless of what the support policy is. I would imagine one of them would file it as a market for other people who aren't going to follow policy. I noticed it wasn't list as a common gotcha on the F15 commons bug page that is maintained to handle these sorts of quibbles. Do we allow for recognition of the not supported upgrade dance in the common bugs information as a policy or is it the upgrade path that must not be named? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: serious conflicts between python pks installed via yum vs pip
On Fri, Feb 10, 2012 at 11:38:20AM -0500, Neal Becker wrote:
80 wrote:
2012/2/10 Neal Becker ndbeck...@gmail.com:
I've seen this repeatedly, with often very serious consequences (complete
failure of update from f15-f16 for example).
Between packages installed via pip, and packages installed via yum, some
packages seem to switch between
e.g.,
numpy-1.6.1-py2.7.egg-info
being installed as a file and the same name being installed as a directory.
This can cause subsequent rpm update (via cpio) to abort.
I don't know what's causing this, but IMO this is a serious problem.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Never use pip outside an isolated environment (use virtualenv)
H.
Really? This is the only answer? Can't we tweek rpm/yum to accomodate this?
Does anyone understand what is causing it? Why would pip install the
egg-info
differently than rpm?
If a package uses distutils (from the stdlib) to build, it will create an
egg-info file with the metadata. If the package is installed with
setuptools (from python-setuptools), it will create and egg-info directory
with the metadata.
Some upstream packages allow you to use either distutils or setuptools with
code like:
try:
from setuptools import setup
except ImportError:
from distutils.core import setup
(numpy is more complex than this looks like with numpy, pip imports
setuptools and therefore the numpy setup.py uses setuptools' setup whereas
python setup.py [COMMAND] does not import setuptools so it uses distutils)
This has the unhappy side effect that sometimes the package is installed
with the egg-info as a file adn sometimes as a directory.
rpm/yum cannot accomodate this easily. I thought that Panu had posted
a good explanation to the mailing lists many years ago but my search skills
are failing me right now. IIRC, it's basically that in your rpm
transaction, rpm must install the new archive before removing the old one.
If the archive includes a file that has to replace a directory, this has no
way of succeeding. (What if the directory contains files, for instance).
Now, there is a way out in this case that doesn't involve the rpm program.
In this case, the numpy rpm could contain either a file or a directory for
the egg-info. It presently contains a file and thus the failure. If you
can figure out how to make numpy create directory egg-info in this case,
you'll be able to make an rpm that will install over a pip local install.
Another option would be to configure python (via the PYTHONPATH environment
variable probably) to read modules from
/usr/local/lib{64,}/python2.7/site-packages/ or another directory that isn't
for the OS vendor. Then have pip install numpy into there.
-Toshio
pgp2pvFY3WSqF.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 10.02.2012 18:32, schrieb Adam Williamson: On Fri, 2012-02-10 at 18:21 +0100, Reindl Harald wrote: Am 10.02.2012 18:05, schrieb Adam Williamson: On Fri, 2012-02-10 at 13:13 +0100, Reindl Harald wrote: Everyone on this list is well aware of the fact that you consider systemd a terrible failure because not every package in Fedora yet has systemd-native init scripts, but by the same token, it is clear that almost no-one agrees with you. On a solid practical level, I am not aware that systemd is currently the source of any major problems in Fedora 15, 16 or 17. F15 was horrible broken mysqld in F15 was horrible broken My servers ran F15 for six months. Never had a problem with mysql. As I recall, your issues with mysql were to do with a specific fairly advanced use case, hardly general-purpose stuff. and this is what blindly butchers not realize: there are well maintained servers not running only plain default configs F15 was the first Linux i saw where reboot did not work until you typed kill 1 while praying! I ran F15 on four machines for months, didn't have that problem. If lots of people had, I would have expected to hear a lot more noise. dmaned you make the dist-upgrade once and not over years if no one agress that is unacceptable that init-system is changed in F15 and F17 still contains not converted services then no one knows how quality looks like I don't agree, no. systemd was explicitly written to be 100% sysv-compatible BUT IT IS NOT AND IT WAS NEVER AND IT WILL NEVER why are VMware-Workstation machines are killed hardly as they was clean suspended until systemd came into my life? yes, it is not a fedora package but that does not matter and prove your argument is wrong - if it would be 100% comatible it would not act like a blind butcher at shutdown even this service does not help as long as it is not stopped manually before type reboot/shutdown, so please leave me in peace with theory where the real life is painful [root@srv-rhsoft:~]$ cat /etc/systemd/system/vmware-default.service [Unit] Description=VMware-Default-Machines After=vmware.service [Service] Type=oneshot ExecStart=/bin/su -c /scripts/vmware/vm-default-start.sh vmware ExecStop=/scripts/vmware/vm-suspend-all.sh RemainAfterExit=yes TimeoutSec=600 SysVStartPriority=90 [Install] WantedBy=multi-user.target _ if it would be 100% compatible all my mysqld problems of services are crashing because they was fired up long before mysqld was ready for connections would never have existed signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Fri, Feb 10, 2012 at 8:41 AM, Reindl Harald h.rei...@thelounge.net wrote: no i can not because it is a one-shot thing to do yum distro-sync and so i had no time for a bugrport while other more important things like mysqld were horrible broken Let me strongly suggest, that unfiled problems will never get fixed because you cannot assume your workflow is part of anyone elses prerelease testing. Let me further stridently suggest that if you or any user insist on using an upgrade path which is stated as a matter of policy as unsupported, that you no justification for assuming that the official testing will catch problems with it and thus you have no business complaining about it a year later. You best course of action when relying on an unsupported set of actions is to do your own testing, and report back deficiencies. If you are nice and polite and professional in the bugreports you have a chance that developers will do you a _favor_ and attempt to fix the problem in the _unsupported_ workflow. But if you do not file, and you do not test then well...adjust your workflow and avoid the unsupported actions and reduce the impedance mismatch with the fedora development process as it stands. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Fri, Feb 10, 2012 at 11:42 AM, Jef Spaleta jspal...@gmail.com wrote: On Fri, Feb 10, 2012 at 8:36 AM, Dan Williams d...@redhat.com wrote: In any case, badmouthing systemd for an upgrade bug where it actually works fine *when you're really running F15* doesn't seem right. I wouldn't have had this problem if it'd installed off the Live CD or done a fresh install. Shrug, I don't make it a point to do yum based upgrades across release boundaries so that would explain why i didn't encounter it. Did anyone doing and testing the not supported upgrade dance to F15 bother filing it at any point? Obviously people use it regardless of what the support policy is. I would imagine one of them would file it as a market for other people who aren't going to follow policy. I've been yum upgrading since FC1. I didn't see that. I was also running a mysql server. I noticed it wasn't list as a common gotcha on the F15 commons bug page that is maintained to handle these sorts of quibbles. Do we allow for recognition of the not supported upgrade dance in the common bugs information as a policy or is it the upgrade path that must not be named? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora major feature introduction; was Re: /usrmove?
On 02/10/2012 04:51 PM, Przemek Klosowski wrote: On 02/09/2012 11:45 PM, Ralf Corsepius wrote: Let me put it this way: I am having difficulties in recalling any Fedora release which worked for me out of the box ... ... That said, IMO, on the technical side, Fedora urgently needs a calming down/lean back/settlement phase, say 2 consecutive Fedora releases without revolutionary features being introduced, to revisit re-evaluate, revert/complete old revolutionary features. To me, Fedora is the Linux RD lab, and the releases are designed to introduce new features. Well, to me Fedora is an advanced end-user development-oriented distro. Being a 1st generation Linux user, who has been using Linux for approx. 20 years and being a developer, I don't have much of a problem with facing an occasional bug every now and then, but I feel Fedora is trying to rush it too fast and is stumbling over its own feet. Still, you have a point about the worrying number of defects (I am personally affected by one of those: my X is misbehaving now, with terrible latency and update performance)---but I think we need to adjust the process rather than make strategic retreats. Hmm, I am facing what I assume to losing focus issues and am facing thunderbird and firefox segfaults every 24-48 hours ;) Specifically, in my opinion the major developments should be planned and announced in a more organized way: - they are first proposed, discussed, adopted and announced in the timeframe of 1 or 2 releases before the release they go in. - they are introduced, on schedule and as a matter of process, into rawhide at the start of the cycle, rather than midstream or late. There are of course difficulties with this approach: first, it could slow down the development just because it adds steps to the process. I would not consider a slow down to be a disadvantage. It would provide devs more time to develop and to test in their labs and provide other parties (packagers, upstreams, users) more time to adapt to on-going developments. It also likely would reduce the impresson of Fedora users being utilized as Guinea Pigs and Fedora being rawhide snapshots. Perhaps more importantly, many important improvements are driven by small groups or individuals Some people will likely find this inappropriate, but I see a direct connection between certain individuals and the shape of Fedora. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
