Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On Fri, Jan 27, 2012 at 7:43 PM, Jef Spaleta jspal...@gmail.com wrote: If you haven't read the new summary write-up on the benefits of the /user feature that I think you would benefit from reading it. http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge If you have read it, then I fear you either don't fully understand or do not value the long term benefits associated with the filesystem snapshotting nor the utility of having read-only shared vendor supplied /usr across many guest instances. Apart from fixing things that are not a problem[1], the stateless/snapshotting benefits are, AFAIK, just vaporware promises. I can't see they can work as stated because /etc and /var are quite strongly bound to the details of contents of the newly proposed /usr - and these objections were raised back when FESCo first discussed this feature. Actually getting a stateless system would require first defining what is state and what is OS (and that question will have several different answers, for good reasons!), and then doing the actual work of separating the two. We already have a readonly-root facility in initscripts, and I think that one is doing it right - giving the people that want to use these (non-default, comparatively rarely-used and site-specific) features the power to create a stateless system without burdening the most common users with it. Mirek [1] Improved compatibility with Solaris - Seriously? We didn't need that level of compatibility back when Linux was a small niche, why would we care now? I feel mildly insulted by that argument. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On 01/28/2012 10:47 AM, Miloslav Trmač wrote: [1] Improved compatibility with Solaris - Seriously? We didn't need that level of compatibility back when Linux was a small niche, why would we care now? I feel mildly insulted by that argument. Why stop with Solaris compatibility and not mimick Windows? No /usr, no /bin = /redhat. Seems to be the spirit behind all this. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
Morning people, Having just caught onto this thread about half way through and now read the various pages concerning the topic, I am still in the dark about going forward. I have 3 machines running F15 that I am upgrading to F16 shortly. I have been using yum to upgrade 2 of them since Fedora Core 1 so that is my usual upgrade path. All of them have a separate /usr partition and it is extra hassle for me to unite the partitions. I understand that things could gracefully break once the /usr merge has occurred. Therefore, is there a resource to explain how to 'pre-mount /usr into the initramfs' to avoid the breakages please? Is this possible? Would uniting the partitions be the only possibility? This is intended as pragmatic questions since I am at this moment quite neutral/ignorant on the finer points of this discussion. Thanks phantomjinx -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Fri, Jan 27, 2012 at 5:57 PM, John Ellson john.ell...@comcast.net wrote: Another issue is that I have: /bin/sh: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory [ 1.796642] Kernel panic - not syncing: attempted to kill init! when trying to boot kernel-3.3.0-0.rc1.git4.1.fc17.i686 from f17-usrmove repo. Reverting to kernel-3.3.0-0.rc1.git3.1.fc17.i686 from the Rawhide repo works ok. That means your initramfs for the git4.1 kernel is probably broken. It has nothing to do with the kernel itself. There is a patch needed for kernel.spec eventually, but it isn't integrated yet and I think the patch I've seen needs to be updated slightly. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide build failure (Requires: /usr/sbin/ldconfig)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2012 09:16 PM, Adam Williamson wrote: On Fri, 2012-01-27 at 16:36 -0500, Daniel J Walsh wrote: On 01/27/2012 04:13 PM, Rex Dieter wrote: Roland Grunberg wrote: I noticed that libselinux was just updated to have ldconfig in /usr/sbin/ as per : https://fedoraproject.org/wiki/Features/UsrMove. It seems glibc hasn't yet been update though and I'm getting the following when attempting a scratch build in rawhide. Righto, moved the offending libselinux-2.1.9-5.fc17 build to f17-usrmove tag instead. -- rex Oops, I thought we could build packages now. I also built an updated policycoreutils... When are we throwing the big switch in Rawhide? Well, if I were the Big Kahuna, I'd like at least a few successful tests of the migration, a test of a fresh install of F17 with the changed packages (we can build images to do this), and possibly a definite resolution to the reservations some still seem to have about the requirements for patched rpm and stuff. Dennis? Ok the problem with that is people like me run in rawhide all the time to try to prevent other people seeing SELinux Hickups. So the sooner I see major changes the better. Do we have a yum repository I could point at to switch my machine to the new usrmove environment. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8j6n0ACgkQrlYvE4MpobNA+QCeOkRZ7XSSV4n6Zr9ljbBLpe7+ skgAoOQBMze6Vc7X8L3lsGqFkJ4azZMf =VlBr -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide build failure (Requires: /usr/sbin/ldconfig)
On 28/01/12 12:30, Daniel J Walsh wrote: Ok the problem with that is people like me run in rawhide all the time to try to prevent other people seeing SELinux Hickups. So the sooner I see major changes the better. Do we have a yum repository I could point at to switch my machine to the new usrmove environment. Full instructions: https://lists.fedoraproject.org/pipermail/devel/2012-January/161761.html# Add f17-usrmove in the file /etc/yum.repos.d/f17-usrmove.repo [f17-usrmove] name=Fedora $releasever - $basearch failovermethod=priority baseurl=http://koji.fedoraproject.org/repos/f17-usrmove/latest/$basearch enabled=1 metadata_expire=1d gpgcheck=0 # yum clean all # yum upgrade -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
On 01/27/2012 10:50 PM, Kevin Kofler wrote: You can make your fork of Fedora roll all you want, but please leave us in peace! Good luck! ^^ Kevin Kofler Way to represent Fedora by being a jerk. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On Fri, 27.01.12 22:40, Kevin Kofler (kevin.kof...@chello.at) wrote: Toshio Kuratomi wrote: people targetting FHS compliant systems (unless the FHS changes) That's the biggest flaw of this feature: It violates the FHS! You know, not even its former editor seems to to believe that (or that it was a problem), judging by the message this sarcastic posting of his sends: http://rusty.ozlabs.org/?p=236 ;-) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On Sat, 28.01.12 11:29, Ralf Corsepius (rc040...@freenet.de) wrote: On 01/28/2012 10:47 AM, Miloslav Trmač wrote: [1] Improved compatibility with Solaris - Seriously? We didn't need that level of compatibility back when Linux was a small niche, why would we care now? I feel mildly insulted by that argument. Why stop with Solaris compatibility and not mimick Windows? No /usr, no /bin = /redhat. Seems to be the spirit behind all this. Actually we originally wanted to rename /usr to C:\PROGA~1\ but we feared FESCO might not agree to that, on grounds that backslashes might be too hard to type on the shell prompt! But we'll propose that for F18, OK? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 01/28/2012 06:48 AM, Josh Boyer wrote: On Fri, Jan 27, 2012 at 5:57 PM, John Ellsonjohn.ell...@comcast.net wrote: Another issue is that I have: /bin/sh: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory [1.796642] Kernel panic - not syncing: attempted to kill init! when trying to boot kernel-3.3.0-0.rc1.git4.1.fc17.i686 from f17-usrmove repo.Reverting to kernel-3.3.0-0.rc1.git3.1.fc17.i686 from the Rawhide repo works ok. That means your initramfs for the git4.1 kernel is probably broken. It has nothing to do with the kernel itself. There is a patch needed for kernel.spec eventually, but it isn't integrated yet and I think the patch I've seen needs to be updated slightly. josh Is there a workaround, or do I need to wait for a kernel update? I tried to rebuild initramfs using: dracut -f initramfs-3.3.0-0.rc1.git4.1.fc17.i686.img 3.3.0-0.rc1.git4.1.fc17.i686 but that made no difference. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On Sat, 2012-01-28 at 11:27 +, phantomjinx wrote: Morning people, Having just caught onto this thread about half way through and now read the various pages concerning the topic, I am still in the dark about going forward. I have 3 machines running F15 that I am upgrading to F16 shortly. I have been using yum to upgrade 2 of them since Fedora Core 1 so that is my usual upgrade path. All of them have a separate /usr partition and it is extra hassle for me to unite the partitions. I understand that things could gracefully break once the /usr merge has occurred. Therefore, is there a resource to explain how to 'pre-mount /usr into the initramfs' to avoid the breakages please? Is this possible? Would uniting the partitions be the only possibility? This is intended as pragmatic questions since I am at this moment quite neutral/ignorant on the finer points of this discussion. As far as F16 goes, you have nothing to worry about; the change is not happening in F16. It's planned for F17. -- 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: Rawhide build failure (Requires: /usr/sbin/ldconfig)
On Sat, 2012-01-28 at 07:30 -0500, Daniel J Walsh wrote: On 01/27/2012 09:16 PM, Adam Williamson wrote: On Fri, 2012-01-27 at 16:36 -0500, Daniel J Walsh wrote: On 01/27/2012 04:13 PM, Rex Dieter wrote: Roland Grunberg wrote: I noticed that libselinux was just updated to have ldconfig in /usr/sbin/ as per : https://fedoraproject.org/wiki/Features/UsrMove. It seems glibc hasn't yet been update though and I'm getting the following when attempting a scratch build in rawhide. Righto, moved the offending libselinux-2.1.9-5.fc17 build to f17-usrmove tag instead. -- rex Oops, I thought we could build packages now. I also built an updated policycoreutils... When are we throwing the big switch in Rawhide? Well, if I were the Big Kahuna, I'd like at least a few successful tests of the migration, a test of a fresh install of F17 with the changed packages (we can build images to do this), and possibly a definite resolution to the reservations some still seem to have about the requirements for patched rpm and stuff. Dennis? Ok the problem with that is people like me run in rawhide all the time to try to prevent other people seeing SELinux Hickups. So the sooner I see major changes the better. Do we have a yum repository I could point at to switch my machine to the new usrmove environment. There were instructions in the announcement thread on exactly how you can test the changes right now. -- 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: Rolling release Fedora - fantastic idea
- Andrew Wyatt and...@fuduntu.org wrote: Way to represent Fedora by being a jerk. Way to represent Fedora by being a jerk. Next time try to be excellent to each other. Two things I personally get tired of reading. A rhetorical question comes to mind Would you rather he was excellent to you and lied saying it's a splendid idea when he feels differently just to spare hurting your feelings? Kevin represents himself not Fedora. He is an individual and is free to his opinions. The rolling release idea comes up annually and a lot of developers/contributors get tired of wasting time sending and reading emails about it. Another is a long term release, I can't count how many times that has come up in the last few years. I'll not apologize for Kevin's response because honestly, I agree with him. -- Bob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
On 01/28/2012 10:35 AM, Robert 'Bob' Jensen wrote: - Andrew Wyattand...@fuduntu.org wrote: Way to represent Fedora by being a jerk. Way to represent Fedora by being a jerk. Next time try to be excellent to each other. Two things I personally get tired of reading. A rhetorical question comes to mind Would you rather he was excellent to you and lied saying it's a splendid idea when he feels differently just to spare hurting your feelings? Kevin represents himself not Fedora. He is an individual and is free to his opinions. The rolling release idea comes up annually and a lot of developers/contributors get tired of wasting time sending and reading emails about it. Another is a long term release, I can't count how many times that has come up in the last few years. I'll not apologize for Kevin's response because honestly, I agree with him. -- Bob I didn't call him a jerk because he disagreed about the potential of Fedora as a rolling release. I called him a jerk for being a jerk. I offered nothing but praise for Fedora, and he started the response with just go away. There is a difference between disagreeing, and being an asshat. Back on topic. It wouldn't continue to come up if people didn't see value in it. Simply discarding the idea because a lot of developers feel that it's a waste of time is not valid criticism of the idea. If you can't count how many times it has come up, perhaps you should investigate it because there is obviously potential in the idea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
- Andrew Wyatt and...@fuduntu.org wrote: I didn't call him a jerk because he disagreed about the potential of Fedora as a rolling release. I called him a jerk for being a jerk. I offered nothing but praise for Fedora, and he started the response with just go away. There is a difference between disagreeing, and being an asshat. Back on topic. It wouldn't continue to come up if people didn't see value in it. Simply discarding the idea because a lot of developers feel that it's a waste of time is not valid criticism of the idea. If you can't count how many times it has come up, perhaps you should investigate it because there is obviously potential in the idea. I should stay out of the technical dead horse/discussion and stick to offensive behavior that is my specialty but I feel I need to respond one more time. Value to who? Some random $BRIGHTIDEAGENERATOR who has no idea of the amount of work involved for those that actually do the work? 1 for and 100 against because it is the 100 that will have to do the work to make the 1 happy? The $BRIGHTIDEAGENERATOR always says Oh I can help do the work. Then after they look at the reality of the situation discover what is actually involved from an engineering standpoint... they turn in to vapor. There was just a 60 message thread on this topic, why start another flamefest thread of doom? Sorry again, I disagree. -- Bob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
On Sat, Jan 28, 2012 at 11:15:11AM -0600, Andrew Wyatt wrote: Back on topic. It wouldn't continue to come up if people didn't see value in it. Simply discarding the idea because a lot of developers feel that it's a waste of time is not valid criticism of the idea. If you can't count how many times it has come up, perhaps you should investigate it because there is obviously potential in the idea. Maybe it's good to create a wiki page or so with a FAQ about both the rolling release and the long term support issue, explaining why these things do not exist and why people in general think it's a bad idea. If people still want to argue *after* reading this FAQ, they should have really good arguments. The arguments in the original mail about the success of mixing up things are by no means impressing, this is just stating he's lucky enough to not come across all the possible problems (and I'm sure there are *many* of them). -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
On 01/28/2012 11:23 AM, Kevin Fenzi wrote: On Sat, 28 Jan 2012 11:15:11 -0600 Andrew Wyattand...@fuduntu.org wrote: ...snip... Back on topic. It wouldn't continue to come up if people didn't see value in it. Simply discarding the idea because a lot of developers feel that it's a waste of time is not valid criticism of the idea. If you can't count how many times it has come up, perhaps you should investigate it because there is obviously potential in the idea. I think the way forward is the one I outlined in: http://lists.fedoraproject.org/pipermail/devel/2012-January/161632.html Until those interested can organize and present a compelling case, I fear threads like this one aren't too much use. kevin +1 I don't have time to champion something like this with all of my other responsibilities but I would be happy to contribute should such a project come to exist. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
On 01/28/2012 10:59 AM, Robert 'Bob' Jensen wrote: - Andrew Wyattand...@fuduntu.org wrote: I didn't call him a jerk because he disagreed about the potential of Fedora as a rolling release. I called him a jerk for being a jerk. I offered nothing but praise for Fedora, and he started the response with just go away. There is a difference between disagreeing, and being an asshat. Back on topic. It wouldn't continue to come up if people didn't see value in it. Simply discarding the idea because a lot of developers feel that it's a waste of time is not valid criticism of the idea. If you can't count how many times it has come up, perhaps you should investigate it because there is obviously potential in the idea. I should stay out of the technical dead horse/discussion and stick to offensive behavior that is my specialty but I feel I need to respond one more time. Value to who? Some random $BRIGHTIDEAGENERATOR who has no idea of the amount of work involved for those that actually do the work? 1 for and 100 against because it is the 100 that will have to do the work to make the 1 happy? The $BRIGHTIDEAGENERATOR always says Oh I can help do the work. Then after they look at the reality of the situation discover what is actually involved from an engineering standpoint... they turn in to vapor. There was just a 60 message thread on this topic, why start another flamefest thread of doom? Sorry again, I disagree. -- Bob The downstream benefit to my project is substantial enough that I would be happy to stick around and help. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
On Sat, Jan 28, 2012 at 07:41:47AM -0600, Andrew Wyatt wrote: On 01/27/2012 10:50 PM, Kevin Kofler wrote: You can make your fork of Fedora roll all you want, but please leave us in peace! Good luck! ^^ Kevin Kofler Way to represent Fedora by being a jerk. Just as a reminder, everyone taking part in Fedora is expected to follow http://fedoraproject.org/wiki/Community_working_group/Code_of_Conduct - I appreciate that Kevin's response was inflammatory, but there's no need to go further than that. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
2012/1/28 Ralf Corsepius rc040...@freenet.de: Why stop with Solaris compatibility and not mimick Windows? No /usr, no /bin = /redhat. Seems to be the spirit behind all this. Ralf The rhetoric spoils the argument. Various people inside of Red Hat are either for this, against this, wanting to see where the train wreck will end, thinking this is the greatest innovation since Unix, etc. All the rhetoric does is cause people (inside and outside of Red Hat) to rally more around that idea no matter how silly than allow the idea to be looked at, valued for its merits and then discarded or kept. I would like to think that after 8 years of this same argument, and its ineffectiveness it would time to do something else. -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 01/27/2012 05:57 PM, John Ellson wrote: On 01/27/2012 08:10 AM, Harald Hoyer wrote: Hello Testers and rawhide Users, Fedora 17 will locate the entire base operating system in /usr. The directories /bin, /sbin, /lib, /lib64 will only be symlinks: /bin → /usr/bin /sbin → /usr/sbin /lib → /usr/lib /lib64 → /usr/lib64 Mostly worked as described. One issue is that the default user's PATH needs to be cleaned up: /usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/guest/.local/bin:/home/guest/bin ... There may be a similar problem with ldconfig.At the moment ldconfig -p show most libs being resolved from /lib instead of from /usr/lib. I'm not against this change, but it would be better if it resulted in a performance gain rather than a performance loss. I wrote a test to stat() the 2000+ files in /usr/bin/*, or /bin/*, 100 times. The time cost of a stat() of /usr/bin/foo was ~ 12.4 microseconds; the time cost of a stat() of /bin/foo was ~17.8 microseconds. So to me, it is important that the default PATHs are changed to minimize the traversal of softlinks. At the moment, having /bin early in the PATH means that a softlink has been *introduced* into most lookups, thus degrading performance. The same issue exists for libs. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 2012-01-27 5:10, Harald Hoyer wrote: Any files with conflicting names, which the conversion could not resolve, will be backed up to files named *.usrmove~ residing in /usr/lib, /usr/lib64, /usr/bin and /usr/sbin. To which file does the conversion script append this suffix when it resolves a conflict: the one under / or the one under /usr? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
On 01/28/2012 05:40 AM, Andrew Wyatt wrote: I read the list thread concerning a Fedora rolling release distribution, and I found it interesting enough to compel me to join the list and weigh in. First, I think a rolling release Fedora is a fantastic idea. I'm certain that it's possible, since I've been pulling packages from 15, 16, and Rawhide downstream to Fuduntu which still has a lot of 14 left at it's core with much success. Would you be willing to lead such a project considering you are already doing some of this work? That would be useful. You can look at Kevin Fenzi's mail, create a wiki page detailing your proposal and invite people to work with you. It seems we have a bunch of enthusiasm but this needs to move beyond that if it is supposed to materialize into anything substantial. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
On 01/28/2012 12:23 PM, Kevin Fenzi wrote: On Sat, 28 Jan 2012 11:15:11 -0600 Andrew Wyatt and...@fuduntu.org wrote: ...snip... ... I think the way forward is the one I outlined in: http://lists.fedoraproject.org/pipermail/devel/2012-January/161632.html Until those interested can organize and present a compelling case, I fear threads like this one aren't too much use. Possibly - but without the support from at least some of the Fedora core team (fesco, board, key redhatters etc) and possibly some on the RH business side recognizing some potential benefit in the enterprise setting, this is quite likely not to go too far .. and so far I'm not aware of much support for this .. This can of course be because these key folk, after careful consideration, do not see it as a viable choice to make for Fedora and/or ultimately its impact on RHEL. They are, after all, key players for good reason(s) ... I cannot imagine they are not familiar with the pros/cons of such an approach. The benefits/drawbacks of a rolling release are rather well known these days (notwithstanding those that somehow still believe rawhide is a rolling release .. :-) )... Given that, do folks still believe it could be worthwhile for the rolling-releasers to build a case in a wiki somewhere? gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
- Genes MailLists li...@sapience.com wrote: Possibly - but without the support from at least some of the Fedora core team (fesco, board, key redhatters etc) and possibly some on the RH business side recognizing some potential benefit in the enterprise setting, this is quite likely not to go too far .. and so far I'm not aware of much support for this .. This can of course be because these key folk, after careful consideration, do not see it as a viable choice to make for Fedora and/or ultimately its impact on RHEL. They are, after all, key players for good reason(s) ... I cannot imagine they are not familiar with the pros/cons of such an approach. The benefits/drawbacks of a rolling release are rather well known these days (notwithstanding those that somehow still believe rawhide is a rolling release .. :-) )... Given that, do folks still believe it could be worthwhile for the rolling-releasers to build a case in a wiki somewhere? Gene, forgive me while I go off on a slight tangent forking the thread. I do not thing it is worthwhile for them to do so. There may already be a document somewhere on the wiki on this topic. It will never be found because since the day mediawiki was rolled out there has not been a usable search. I would think that taking a look at existing infrastructure tickets such as the one for getting a usable search for the wiki would be time better spent than writing more pages for the black hole that the wiki has become or dreaming about something that has been shot down repeatedly. -- Bob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
On 01/28/2012 04:26 PM, Robert 'Bob' Jensen wrote: Gene, forgive me while I go off on a slight tangent forking the thread. I do not thing it is worthwhile for them to do so. There may already be a document somewhere on the wiki on this topic. It will never be found because since the day mediawiki was rolled out there has not been a usable search. I would think that taking a look at existing infrastructure tickets such as the one for getting a usable search for the wiki would be time better spent than writing more pages for the black hole that the wiki has become or dreaming about something that has been shot down repeatedly. -- Bob https://fedoraproject.org/w/index.php?title=Special%3ASearchredirs=1search=%22rolling+release%22+-epelfulltext=Searchns0=1ns4=1ns6=1ns12=1ns14=1ns106=1ns108=1ns110=1ns112=1ns114=1ns116=1 pulls up some relevant links: https://fedoraproject.org/wiki/Release_Lifecycle_Proposals and https://fedoraproject.org/wiki/Stable_release_updates_vision along with a couple other irrelevant links. Doesn't seem that hard to find. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
Fuduntu Dev here. I'm not going to bore you all on how great rolling is, and how it's a great model that works for everyone - I'll assume the good folks of Fedora have already researched many different models. Instead, what I'm going to talk about is the feasibility and the logistics. Fuduntu didn't start out as a rolling release. We had versions for a while, until we realised we were basically releasing newer snapshots of our current software with slightly different defaults. Having discussed it as a team, we decided to move to rolling - less work for us to handle the repos and create images, less hassle for our users to reinstall with each release just because we'd changed some default package or updated something vital to a newer version. Our users could just update, and we could just create images. Simples. The transition was painless. I can't say I noticed much fallout, if any. Perhaps fewt can remember some, but I can't. Our distro is pretty stable, with new software - something that's a treat in the Linux world. However, it costs. Development time, it costs. There's 3 of us packaging things, along with 3 newly initiated interns. It also costs our users to some extent - there's no easy way for them to prevent something upgrading. They have to roll with the flow. This doesn't work out great for everyone. A project doing the same for Fedora would need the backing of experienced developers with time or payment. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide build failure (Requires: /usr/sbin/ldconfig)
Daniel J Walsh wrote: Oops, I thought we could build packages now. I also built an updated policycoreutils... And why didn't you untag the darn package? All our daily live image builds failed today because of this! I moved your build to the f17-usrmove tag where it belongs. (Any packager can do this because neither f17 nor f17-usrmove are locked tags.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
Andrew Wyatt wrote: I didn't call him a jerk because he disagreed about the potential of Fedora as a rolling release. I called him a jerk for being a jerk. I offered nothing but praise for Fedora, and he started the response with just go away. After seeing you boast about how at Fuduntu we have been working long and hard to complete the transition from Fedora to being completely self hosted, Today I would like to announce that we are officially forked. This means that we are now a self contained, self hosted distribution. and how Fuduntu has become an independent distribution, why would you think the Fedora community would still consider you part of itself? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
I thought you didn't speak for the community. I'm sorry if forking hurt your feelings, but there really were only two options. Go forward and rework everything for 15 or 16, or fork. Fedora 14 was EOS, remember? Besides, you have no right and no business telling me where I am or am not welcome. -- Sent from my Sony Xperia Play. Kevin Kofler kevin.kof...@chello.at wrote: Andrew Wyatt wrote: I didn't call him a jerk because he disagreed about the potential of Fedora as a rolling release. I called him a jerk for being a jerk. I offered nothing but praise for Fedora, and he started the response with just go away. After seeing you boast about how at Fuduntu we have been working long and hard to complete the transition from Fedora to being completely self hosted, Today I would like to announce that we are officially forked. This means that we are now a self contained, self hosted distribution. and how Fuduntu has become an independent distribution, why would you think the Fedora community would still consider you part of itself? Kevin Kofler -- 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: Rolling release Fedora - fantastic idea
On 01/29/2012 06:12 AM, Noah Hall wrote: Fuduntu Dev here. I'm not going to bore you all on how great rolling is, and how it's a great model that works for everyone - I'll assume the good folks of Fedora have already researched many different models. Instead, what I'm going to talk about is the feasibility and the logistics. It seems that Fuduntu can get together with Fedora by putting up a proposal and leading the effort. I don't see why not since you have a bunch of people already doing something. Seems like you guys would or should have the technical know how. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 proposal - prerelease version name changes
On 01/28/2012 07:30 AM, Adam Williamson wrote: It may, however, be worth doing something with the naming of TCs / RCs, as has been proposed in the past, because they do seem to confuse people. Every TC and RC announcement should have a brief blurb on who it is targeting and whats the exact change between them. That would help. Naming isn't as important. Setting expectations, is. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 proposal - prerelease version name changes
On Sun, 2012-01-29 at 11:14 +0530, Rahul Sundaram wrote: On 01/28/2012 07:30 AM, Adam Williamson wrote: It may, however, be worth doing something with the naming of TCs / RCs, as has been proposed in the past, because they do seem to confuse people. Every TC and RC announcement should have a brief blurb on who it is targeting and whats the exact change between them. That would help. Naming isn't as important. Setting expectations, is. The target doesn't change, the purpose of any TC or RC is always to test it against the release criteria using the validation tests. There is a link to the trac ticket, which usually describes the changes between TC and RC builds, in each announcement. -- 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
File Directory-Queue-1.5.tar.gz uploaded to lookaside cache by stevetraylen
A file has been added to the lookaside cache for perl-Directory-Queue: 5be9ae874aa49bf6f5ba64d33d99ed07 Directory-Queue-1.5.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Directory-Queue] Update to 1.5 rhbz#785073.
commit 9d4ba5e1779fb20f1c67fa8f2fedc5ce87f39457
Author: Steve Traylen steve.tray...@cern.ch
Date: Sat Jan 28 11:13:00 2012 +0100
Update to 1.5 rhbz#785073.
.gitignore|1 +
perl-Directory-Queue.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index c925905..7754453 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@ Directory-Queue-0.5.tar.gz
/Directory-Queue-1.1.tar.gz
/Directory-Queue-1.2.tar.gz
/Directory-Queue-1.4.tar.gz
+/Directory-Queue-1.5.tar.gz
diff --git a/perl-Directory-Queue.spec b/perl-Directory-Queue.spec
index 5458cac..9c943e8 100644
--- a/perl-Directory-Queue.spec
+++ b/perl-Directory-Queue.spec
@@ -1,6 +1,6 @@
Name: perl-Directory-Queue
-Version:1.4
-Release:2%{?dist}
+Version:1.5
+Release:1%{?dist}
Summary:Object oriented interface to a directory based queue
License:GPL+ or Artistic
Group: Development/Libraries
@@ -56,6 +56,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Sat Jan 28 2012 Steve Traylen steve.tray...@cern.ch - 1.5-1
+- Update to 1.5 rhbz#785073.
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.4-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
diff --git a/sources b/sources
index 6640b77..46e0007 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-301d2f28910328ff67f9f23a41a5d37a Directory-Queue-1.4.tar.gz
+5be9ae874aa49bf6f5ba64d33d99ed07 Directory-Queue-1.5.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Directory-Queue] Created tag perl-Directory-Queue-1.5-1.fc17
The unsigned tag 'perl-Directory-Queue-1.5-1.fc17' was created. Tagger: Steve Traylen steve.tray...@cern.ch Date: Sat Jan 28 11:13:37 2012 +0100 Update to 1.5 rhbz#785073. Changes since the last tag 'perl-Directory-Queue-1.4-1.fc16': Dennis Gilmore (1): - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild Steve Traylen (1): Update to 1.5 rhbz#785073. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Directory-Queue/f16] (2 commits) ...Update to 1.5 rhbz#785073.
Summary of changes: 1418423... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass (*) 9d4ba5e... Update to 1.5 rhbz#785073. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Directory-Queue] Created tag perl-Directory-Queue-1.5-1.fc16
The unsigned tag 'perl-Directory-Queue-1.5-1.fc16' was created. Tagger: Steve Traylen steve.tray...@cern.ch Date: Sat Jan 28 11:15:15 2012 +0100 Update to 1.5 rhbz#785073. Changes since the last tag 'perl-Directory-Queue-1.4-1.fc16': Dennis Gilmore (1): - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild Steve Traylen (1): Update to 1.5 rhbz#785073. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Directory-Queue/el6] (3 commits) ...Update to 1.5 rhbz#785073.
Summary of changes: 1418423... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass (*) 9d4ba5e... Update to 1.5 rhbz#785073. (*) 3331d84... Update to 1.5 rhbz#785073. (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Directory-Queue] Created tag perl-Directory-Queue-1.5-1.el6
The unsigned tag 'perl-Directory-Queue-1.5-1.el6' was created. Tagger: Steve Traylen steve.tray...@cern.ch Date: Sat Jan 28 11:16:44 2012 +0100 Update to 1.5 rhbz#785073. Changes since the last tag 'perl-Directory-Queue-1.4-1.el6': Dennis Gilmore (1): - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild Steve Traylen (2): Update to 1.5 rhbz#785073. Update to 1.5 rhbz#785073. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Directory-Queue/el6: 3/3] Update to 1.5 rhbz#785073.
commit 3331d84f63da451f6ce574f7c6ed8682d57c776e
Merge: 03c5164 9d4ba5e
Author: Steve Traylen steve.tray...@cern.ch
Date: Sat Jan 28 11:16:28 2012 +0100
Update to 1.5 rhbz#785073.
.gitignore|1 +
perl-Directory-Queue.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --cc perl-Directory-Queue.spec
index f00becd,9c943e8..d061f56
--- a/perl-Directory-Queue.spec
+++ b/perl-Directory-Queue.spec
@@@ -56,6 -56,12 +56,9 @@@ rm -rf $RPM_BUILD_ROO
%{_mandir}/man3/*
%changelog
+ * Sat Jan 28 2012 Steve Traylen steve.tray...@cern.ch - 1.5-1
+ - Update to 1.5 rhbz#785073.
+
-* Fri Jan 13 2012 Fedora Release Engineering
rel-...@lists.fedoraproject.org - 1.4-2
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
-
* Thu Dec 8 2011 Steve Traylen steve.tray...@cern.ch - 1.4-1
- Update 1.4 rhbz#760472.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Directory-Queue/el5] (14 commits) ...Merge branch 'el6' into el5
Summary of changes: 10ad12b... Initialize branch EL-6 for perl-Directory-Queue (*) 7e053f1... Populate branches: #607355 (*) fb47d34... Forgot the .spec file. (*) 11e99d5... Bump release due to my mitake. (*) 7e1c4f3... dist-git conversion (*) ec67560... Merge branch 'master' into el6 (*) 948833e... Merge branch 'master' into el6 (*) 48b49ce... Merge branch 'master' into el6 (*) 9692354... Merge branch 'master' into el6 (*) 03c5164... Merge branch 'master' into el6 (*) 1418423... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass (*) 9d4ba5e... Update to 1.5 rhbz#785073. (*) 3331d84... Update to 1.5 rhbz#785073. (*) 4ce1fa8... Merge branch 'el6' into el5 (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Directory-Queue] Created tag perl-Directory-Queue-1.5-1.el5
The unsigned tag 'perl-Directory-Queue-1.5-1.el5' was created. Tagger: Steve Traylen steve.tray...@cern.ch Date: Sat Jan 28 11:17:32 2012 +0100 Update to 1.5 rhbz#785073. Changes since the last tag 'perl-Directory-Queue-1.4-1.el5': Dennis Gilmore (1): - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild Fedora Release Engineering (1): dist-git conversion Jason ティビツ (1): Initialize branch EL-6 for perl-Directory-Queue Steve Traylen (8): Merge branch 'master' into el6 Merge branch 'master' into el6 Merge branch 'master' into el6 Merge branch 'master' into el6 Merge branch 'master' into el6 Update to 1.5 rhbz#785073. Update to 1.5 rhbz#785073. Merge branch 'el6' into el5 stevetraylen (3): Populate branches: #607355 Forgot the .spec file. Bump release due to my mitake. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Directory-Queue/el5: 14/14] Merge branch 'el6' into el5
commit 4ce1fa89e6d4c5f0bfd899ec71236ebadab6959f Merge: 1d6494b 3331d84 Author: Steve Traylen steve.tray...@cern.ch Date: Sat Jan 28 11:17:18 2012 +0100 Merge branch 'el6' into el5 .gitignore|1 + perl-Directory-Queue.spec |5 - sources |2 +- 3 files changed, 6 insertions(+), 2 deletions(-) --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 785073] Upgrade to new upstream version
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=785073 --- Comment #2 from Fedora Update System upda...@fedoraproject.org 2012-01-28 04:18:35 EST --- perl-Directory-Queue-1.5-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/perl-Directory-Queue-1.5-1.fc16 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 785073] Upgrade to new upstream version
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=785073 --- Comment #1 from Fedora Update System upda...@fedoraproject.org 2012-01-28 04:18:28 EST --- perl-Directory-Queue-1.5-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-Directory-Queue-1.5-1.el6 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 785073] Upgrade to new upstream version
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=785073 --- Comment #3 from Fedora Update System upda...@fedoraproject.org 2012-01-28 04:18:43 EST --- perl-Directory-Queue-1.5-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/perl-Directory-Queue-1.5-1.el5 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 785363] New: perl-Glib-Object-Introspection-0.006 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Glib-Object-Introspection-0.006 is available https://bugzilla.redhat.com/show_bug.cgi?id=785363 Summary: perl-Glib-Object-Introspection-0.006 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Glib-Object-Introspection AssignedTo: berra...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: berra...@redhat.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Latest upstream release: 0.006 Current version in Fedora Rawhide: 0.004 URL: http://search.cpan.org/dist/Glib-Object-Introspection/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 785361] New: perl-Archive-RPM-0.07 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Archive-RPM-0.07 is available https://bugzilla.redhat.com/show_bug.cgi?id=785361 Summary: perl-Archive-RPM-0.07 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Archive-RPM AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: iarn...@gmail.com, fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, psab...@redhat.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Latest upstream release: 0.07 Current version in Fedora Rawhide: 0.06 URL: http://search.cpan.org/dist/Archive-RPM/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 785365] New: perl-MogileFS-Client-1.15 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-MogileFS-Client-1.15 is available https://bugzilla.redhat.com/show_bug.cgi?id=785365 Summary: perl-MogileFS-Client-1.15 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-MogileFS-Client AssignedTo: ppi...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, ppi...@redhat.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Latest upstream release: 1.15 Current version in Fedora Rawhide: 1.14 URL: http://search.cpan.org/dist/MogileFS-Client/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 785366] New: perl-MogileFS-Utils-2.22 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-MogileFS-Utils-2.22 is available https://bugzilla.redhat.com/show_bug.cgi?id=785366 Summary: perl-MogileFS-Utils-2.22 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-MogileFS-Utils AssignedTo: ppi...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, ppi...@redhat.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Latest upstream release: 2.22 Current version in Fedora Rawhide: 2.21 URL: http://search.cpan.org/dist/MogileFS-Utils/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 785364] New: perl-Module-Install-ExtraTests-0.007 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Module-Install-ExtraTests-0.007 is available https://bugzilla.redhat.com/show_bug.cgi?id=785364 Summary: perl-Module-Install-ExtraTests-0.007 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Module-Install-ExtraTests AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, psab...@redhat.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Latest upstream release: 0.007 Current version in Fedora Rawhide: 0.006 URL: http://search.cpan.org/dist/Module-Install-ExtraTests/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 785073] Upgrade to new upstream version
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=785073 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2012-01-28 12:48:41 EST --- Package perl-Directory-Queue-1.5-1.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing perl-Directory-Queue-1.5-1.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-0274/perl-Directory-Queue-1.5-1.el6 then log in and leave karma (feedback). -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
