Re: Announcing Fedora Activity Day - Fedora Development Cycle 2009
On 02.06.2009 22:30, Jesse Keating wrote: On Tue, 2009-06-02 at 21:30 +0200, Thorsten Leemhuis wrote: but if we get RC with the final name transferred to the mirrors ahead of time then they can be updated relative quickly as well, as only a few bit change. We don't do this as it tends to lead to leaks, and confusion as to whether the release has been done or not. Then put it in a temporary folder that is rsynced from the mirror masters, but not exported it to the world. Later it's just a update to the file and a hardlink to a proper place. Or simply ignore that there might be leaks problem more -- the clientele that is huntin for leaks before something is announced is doing something wrong already in any case. And if the whole process from finishing to release would be a whole lot shorter then it shortens the time where something leaks. CU knurd -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Announcing Fedora Activity Day - Fedora Development Cycle 2009
Kevin Kofler, Wed, 03 Jun 2009 01:29:35 +0200: gmane.linux.redhat.fedora.testers http://list.gmane.org/fedora-test-l...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wed, 03 Jun 2009 05:09:49 +0200, Ralf wrote: Kevin Kofler wrote: Steve Grubb wrote: I don't want to start a long thread, but just to ask a couple questions for my own clarification. Does a maintainer's responsibilities end with packaging bugs? IOW, if there is a problem in the package that is _broken code_ do they need to do something about it or is it acceptable for them to close the bug and say talk to upstream? It's the reporter's job to report the bug upstream when asked to do so. I disagree. Reporters are users - customers if you like to. Consumers. Consumers of a product. And the product (albeit developed by upstream) is offered by Fedora, as the Fedora packagers prepare and build the packages for the Fedora software environment. Added value, and as such it's normal for the packagers to stay at the front with regard to incoming problem reports. You can't expect them to do anything, nor demand them to do anything, nor force them to do anything. On the contrary, a packager at least ought to have an opinion about every Fedora bugzilla ticket that is opened for the package. An opinion about whether a problem is reproducible, whether it may be specific to Fedora, whether it can be patched for Fedora, whether it is grave enough to be in need of major rewrites in the upstream code base, whether the report is not helpful, and so on. The Fedora packager ought to be aware of what the package users think about how usable the packaged software is in the Fedora environment. That said, I consider it to be a Fedora package's maintainer's job and duty to act as moderator/arbiter/coordinator to initiate appropriate communication/interaction between all different parties (reporter, packager, upstreams) when necessary/if required. This is particularly important when upstream doesn't have a bug tracking system, when it takes weeks till months for a new upstream release, when a problem requires the user to test unofficial updates (and patches that can be derived from SCM commits) where the Fedora packager may need to assist. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wednesday 03 June 2009 11:47:26 Jaroslav Reznik wrote: PS: I'm not saying to not report bugs to RH bugzilla, we can help then but lack of direct communication between user and developer is issue, You're assuming that all those users are engineers and technical people. That might be true atm but at least I also would like to get the 'normal people' which are now ubuntu users. back to propritetary software which is the reason why most 'normal people' use windows and among the numbers, they have the control of everything (hw support etc). I'd like to see a day that my new display adapter works out of the box. I'd like to see that day as a Fedora user/community member. Tuju -- Better to have one, and not need it, than to need one and not have it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Tue, 2009-06-02 at 16:17 -0400, Steve Grubb wrote: I don't want to start a long thread, but just to ask a couple questions for my own clarification. Does a maintainer's responsibilities end with packaging bugs? IOW, if there is a problem in the package that is _broken code_ do they need to do something about it or is it acceptable for them to close the bug and say talk to upstream? There are _some_ kinds of bug (feature requests, etc.) which it's reasonable for any decent maintainer to punt upstream. There are other kinds of bugs (crashes, security issues -- perhaps even _anything_ that's a real bug rather than an RFE) which the maintainer really _ought_ to deal with directly. Opinions vary on precisely where the boundary between those classes should be, but I'm fairly adamant it should be 'RFE vs. bug'. Any packager who _isn't_ capable of handling the latter class of bug probably shouldn't be maintaining the package without the assistance of a co-packager or their sponsor. Note that you don't _have_ to be able to code to handle a real bug in an acceptable fashion -- decent coordination with upstream can be perfectly sufficient, if upstream are responsive enough. But just closing the bug in our bugzilla as 'upstream' is rarely acceptable for a _real_ bug, IMHO. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
uClibc orphaned
Hello, I want to split uClibc from busybox package - is here a volunteer who is willing to take care about it? Ivana Hutarova Varekova -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages (brasero, transmission and more)
On 06/03/2009 12:50 PM, Denis Leroy wrote: In an effort to focus more on FOSS upstream development, I am going to be orphaning some of my Fedora packages in the near future, starting with this first batch. transmission Taken this. Co-maintainers welcome. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Miércoles 03 Junio 2009 11:52:37 Juha Tuomala escribió: On Wednesday 03 June 2009 11:47:26 Jaroslav Reznik wrote: PS: I'm not saying to not report bugs to RH bugzilla, we can help then but lack of direct communication between user and developer is issue, You're assuming that all those users are engineers and technical people. That might be true atm but at least I also would like to get the 'normal people' which are now ubuntu users. Most bugs are filled by quite technically skilled users. For average users it doesn't depend if it is RH bugzilla or upstream's bugzilla - it's too complicated for them. I know - it's another story... For these people forums are much more better. Maybe we lack some tool for users - without technical details, more collecting only tool... Some easy GUI for Abrt? New Dr. Konqui is nice but still too complicated for average users. They don't click on send bug button but OK buttons and accepting the fact of crash... back to propritetary software which is the reason why most 'normal people' use windows and among the numbers, they have the control of everything (hw support etc). But if you observe bug or have some wish - there's no chance to talk to developer... I'd like to see a day that my new display adapter works out of the box. I'd like to see that day as a Fedora user/community member. I hope that day is close because I think it's worst problem of whole OSS Desktop :( Tuju -- Better to have one, and not need it, than to need one and not have it. Jaroslav -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F11: kernel/boot hangs at creating initial device nodes with 2.6.30-rc6
On Mon, Jun 01, 2009 at 08:15:48AM +0300, Pasi Kärkkäinen wrote: Hello. Yesterday I installed latest F11/rawhide. The default installed kernel (2.6.29 something) works fine. I compiled custom 2.6.30-rc6 kernel, and created initrd for it, and tried booting it. Booting process gets stuck at creating initial device nodes. Any ideas? I assume that's during initrd execution.. Something missing from my kernel config? Any tips would be appreciated. Has anyone else seen this problem? -- Pasi -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibility Policy
On 05/06/2008 03:54 PM, Brian Pepple wrote: On Tue, 2008-05-06 at 07:26 -0700, Toshio Kuratomi wrote: snip Brian, we probably want to list the ways to deal with bug reports in the policy as many maintainers don't realize how many options there are for getting help fixing a bug. Here's what I've got right now (from Kevin's suggestion) in the section regarding bugs: If you find yourself unable to handle the load of bugs from your package(s), please ask for assistance on the fedora-devel and/or fedora-test lists. Teaching triagers about how to triage your bugs or getting help from other maintainers can not only reduce your load, but improve Fedora. Consider reaching out for some (more) co-maintainers to assist as well. Do we want to expand on that? FYI If bugs need (Re)testing or a component needs a speedup treatment in bodhi drop a testing request to fedora-test list and/or file a request in Fedora QA trac instance on https://fedorahosted.org/fedora-qa and we will take care of it. We also assisting in any test case creation, setup test day's etc. Dont hesitate to drop a mail to the test-list or open a ticktet in Fedora QA trac instance JBG begin:vcard fn:Johann B. Gudmundsson n:Gudmundsson;Johann B. org:Reiknistofnun - University of Iceland;IT Management adr:Taeknigardi;;Dunhagi 5;Reykjavik;;107;Iceland email;internet:johan...@hi.is title:Unix System Engineer RHCE,CCSA tel;work:+3545254267 tel;fax:+3545528801 tel;pager:N/A tel;home:N/A tel;cell:N/A url:www.rhi.hi.is version:2.1 end:vcard -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages (brasero, transmission and more)
On Wed, Jun 03, 2009 at 09:20:54AM +0200, Denis Leroy wrote: In an effort to focus more on FOSS upstream development, I am going to be orphaning some of my Fedora packages in the near future, starting with this first batch. brasero (high-maintenance) Wait... didn't we just make this the default CD/DVD buring application in the Fedora spin? http://fedoraproject.org/wiki/Features/Gnome2_26 And now it's orphaned? josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Jaroslav Reznik wrote: On Miércoles 03 Junio 2009 05:09:49 Ralf Corsepius escribió: Kevin Kofler wrote: Steve Grubb wrote: I don't want to start a long thread, but just to ask a couple questions for my own clarification. Does a maintainer's responsibilities end with packaging bugs? IOW, if there is a problem in the package that is _broken code_ do they need to do something about it or is it acceptable for them to close the bug and say talk to upstream? It's the reporter's job to report the bug upstream when asked to do so. I disagree. Reporters are users - customers if you like to. You can't expect them to do anything, nor demand them to do anything, nor force them to do anything. We are not forcing anyone to do anything but we think direct communication between user and developer is much more better I consider maintainers redirecting arbitrary reporters to upstreams to be rude and hostile, because they are presuming the reporter to be * interested in tracking down bugs * interested in getting involved into upstreams * technically able to do so. This occasionally applies to developers - To normal users it usally doesn't apply, they want to have their issue fixed. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages (brasero, transmission and more)
Rahul Sundaram wrote: On 06/03/2009 05:18 PM, Josh Boyer wrote: On Wed, Jun 03, 2009 at 09:20:54AM +0200, Denis Leroy wrote: In an effort to focus more on FOSS upstream development, I am going to be orphaning some of my Fedora packages in the near future, starting with this first batch. brasero (high-maintenance) Wait... didn't we just make this the default CD/DVD buring application in the Fedora spin? http://fedoraproject.org/wiki/Features/Gnome2_26 And now it's orphaned? Yep. Bad timing. Somebody should pick it up. Rahul Xavier Lamien said he'd pick it up, which I assume he'll do after Denis orphans it in pkgdb. -J -- in your fear, speak only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Tuesday 02 June 2009 07:34:17 pm Kevin Kofler wrote: Steve Grubb wrote: I don't want to start a long thread, but just to ask a couple questions for my own clarification. Does a maintainer's responsibilities end with packaging bugs? IOW, if there is a problem in the package that is _broken code_ do they need to do something about it or is it acceptable for them to close the bug and say talk to upstream? It's the reporter's job to report the bug upstream when asked to do so. And then should the bug be closed hoping that one day you pull in a package that solves the user's problem? Fixing bugs often requires two-way communication, so it's important for upstream to have a real reporter to talk to, I don't see why it should be the maintainer's job to play the relaying monkey. Its real simple. In reporting the bug, people are asked how to reproduce the bug. If its reproducible by the maintainer, the user is no longer required to solve the problem and all you need to do is ask them to do a retest. If the bug is not reproducible, then things do get a little trickier. I would still take the bug report to upstream and see if it rings any bells, but I would not close the bug. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Tuesday 02 June 2009 11:09:49 pm Ralf Corsepius wrote: Kevin Kofler wrote: Steve Grubb wrote: I don't want to start a long thread, but just to ask a couple questions for my own clarification. Does a maintainer's responsibilities end with packaging bugs? IOW, if there is a problem in the package that is _broken code_ do they need to do something about it or is it acceptable for them to close the bug and say talk to upstream? It's the reporter's job to report the bug upstream when asked to do so. I disagree. Reporters are users - customers if you like to. You can't expect them to do anything, nor demand them to do anything, nor force them to do anything. That said, I consider it to be a Fedora package's maintainer's job and duty to act as moderator/arbiter/coordinator to initiate appropriate communication/interaction between all different parties (reporter, packager, upstreams) when necessary/if required. For the record, I agree with this sentiment. If there's a bug in my packages, I want to fix it and not cause the reporter to have to get upstream bz accounts or join upstream mail lists just because they reported a problem. I will interact with the reporter until I see the problem myself. And then I can fix it or show upstream the problem. Thanks everybody for the opinions. I just wanted to raise awareness on this topic. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Announcing Fedora Activity Day - Fedora Development Cycle 2009
On Tue, Jun 02, 2009 at 08:15:32PM -0400, Josh Boyer wrote: We are facing some real limitations on our turn around time for things at the moment and they are only going to get worse as we have newer releases that will get the delta rpms. At the same time, the same people are getting raked over the coals for not getting bits out fast enough. We are working on this from a rel-eng standpoint, but advocating for a bit of discretion on what should be pushed as an update is not entirely a bad thing. Personally, I would love it if package maintainers slowed down a bit. But it's not an end solution. So certainly the leadership, defined as FESCo and FPB, is not in conflict with the contributor's apparent direction. As far as I can see, they haven't made a statement either way. If there is a group that was pushing for something that ran contrary, it was Rel-Eng. And given that Jesse and I both just said we're going to basically stop begging people to slow down on updates, I think even that group is trying to figure out a way to make things better. Hell, that's partly what this FAD is all about. If the FAD identifies some tangibles (hardware, etc.) that would help alleviate some of the time problems, I can tell you that Spot and I will do our best to procure them. From what I've heard others describe up until now, it doesn't seem like there's one clear roadblock in that regard -- just a huge mountain of tasks that our current systems have to chug through for composing, and no matter how you slice it, it takes a lot of time and I/O bandwidth. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wed, 03 Jun 2009 14:06:45 +0200, Ralf wrote: I consider users (esp. bug reporters) not to be the dumb pigs eating the hog wash they get for free, or clueless comsumer masses aborbing anything they don't pay for with money, but them to be the foundation of your work and them to be valuable business partners, paying in immaterial payment (e.g. feedback, such as bug reports). That's an idealistic [over-simplified] point of view which I don't want to agree with. There is no clear relationship, such as a seller and a purchaser (and the customer is king guideline doesn't apply), since the person who produces the packages may be the one to _give_ more than he _gets_ in return by the users. Or vice versa. All that's clear to me is that the packager fills the role of a provider, providing packaging services, and certain feedback from some package users may help with improving the quality of the provided product. In turn the provider ought to have interest in such an improvement and in boosting the relationship with the package users. Preferably, users with strong interest in a particular Fedora package sign up at the Fedora Account System, so they can subscribe to a package's watchbugzilla and watchcommit channels. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Announcing Fedora Activity Day - Fedora Development Cycle 2009
On Wed, Jun 03, 2009 at 08:55:48AM -0400, Paul W. Frields wrote: On Tue, Jun 02, 2009 at 08:15:32PM -0400, Josh Boyer wrote: We are facing some real limitations on our turn around time for things at the moment and they are only going to get worse as we have newer releases that will get the delta rpms. At the same time, the same people are getting raked over the coals for not getting bits out fast enough. We are working on this from a rel-eng standpoint, but advocating for a bit of discretion on what should be pushed as an update is not entirely a bad thing. Personally, I would love it if package maintainers slowed down a bit. But it's not an end solution. So certainly the leadership, defined as FESCo and FPB, is not in conflict with the contributor's apparent direction. As far as I can see, they haven't made a statement either way. If there is a group that was pushing for something that ran contrary, it was Rel-Eng. And given that Jesse and I both just said we're going to basically stop begging people to slow down on updates, I think even that group is trying to figure out a way to make things better. Hell, that's partly what this FAD is all about. If the FAD identifies some tangibles (hardware, etc.) that would help alleviate some of the time problems, I can tell you that Spot and I will do our best to procure them. From what I've heard others describe up until now, it doesn't seem like there's one clear roadblock in that regard -- just a huge mountain of tasks that our current systems have to chug through for composing, and no matter how you slice it, it takes a lot of time and I/O bandwidth. Yep. As a simple test, We'd like to do some experiments to see if running updates pushes and rawhide composes on separate boxen makes things worse or better or about the same. I don't think we need additional procured hardware for that, just a cloned guest which I already have a ticket opened for. Oh, and time. Always need time. If you or spot could procure time, let me know ;) josh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Michael Schwendt wrote: On Wed, 03 Jun 2009 14:06:45 +0200, Ralf wrote: I consider users (esp. bug reporters) not to be the dumb pigs eating the hog wash they get for free, or clueless comsumer masses aborbing anything they don't pay for with money, but them to be the foundation of your work and them to be valuable business partners, paying in immaterial payment (e.g. feedback, such as bug reports). That's an idealistic [over-simplified] point of view which I don't want to agree with. Well, whether it's idealistic or not is irrelevant. It's one of the foundations of open source. Or less abstract: I stopped reporting bugs against Fedora's evolution, because its @RH maintainer preferred to close bugs and tried to push me around to upstream. Wrt. evolution, I was an ordinary user and am not interested in getting further involved. As simple as it is: I felt sufficiently pissed of by this guy to leave him and his upstream alone, ... so be it, he wanted it this way. There are other packages and packagers (noteworthy many of the @RH) who exhibit the same push reporters around behavior. So is still anybody wondering why Fedora is permanently lacking people? This is one cause. Now combine this with the report bugs phrases certain people tend to reiterate? ... Experiences, such as the one I encountered with the evolution maintainer, are the cause why at least some people sense a foul taste when listening to them. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages (brasero, transmission and more)
On Wed, 2009-06-03 at 14:16 +0200, Denis Leroy wrote: On 06/03/2009 01:48 PM, Josh Boyer wrote: On Wed, Jun 03, 2009 at 09:20:54AM +0200, Denis Leroy wrote: In an effort to focus more on FOSS upstream development, I am going to be orphaning some of my Fedora packages in the near future, starting with this first batch. brasero (high-maintenance) Wait... didn't we just make this the default CD/DVD buring application in the Fedora spin? http://fedoraproject.org/wiki/Features/Gnome2_26 And now it's orphaned? I merely want to transfer ownership to somebody new. Matthias Clasen and Bastien Nocera are already acting co-maintainers, and so I'm waiting to hear from them before transferring ownership, in case one of them has a strong desire to take over the package... I don't have a strong desire to own any package... but if nobody else picks it up, I will find an owner for it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Tuesday 02 June 2009 06:17:02 pm Steven M. Parrish wrote: This is from the official Bugzappers page https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#Upstreamin So, this raises the question about bugzappers. Should they be making the determination for maintainers that the reporter should have taken the issue upstream? Do bug zappers take into consideration the severity of the bug before pushing someone upstream? The bug is not a packaging bug, the package maintainer has no plans to work on this in the near future, and there is an upstream bug tracking system other than the Red Hat Bugzilla. Is there communication between maintainer and bugzapper before doing this? Maintainers should be free to either fix it locally (time permitting) and upstream the patch or request that the bug be filed at the upstream projects tracker for the upstream developers to resolve it. If it is sent upstream the bug is closed as UPSTREAM and our local report is cross-referenced to the upstream one. That way the maintainer and all interested parties can follow its progress. Not if its closed. How would I be notified that the fix is in Fedora? If the bug is severe enough, shouldn't the upstream commit be applied to Fedora's package and the package pushed out for testing? Is all this going to happen if the bug is closed? -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: welcome to fedora
Muayyad AlSadi wrote: maybe a trivial pygtk script ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list +1 I was just about to suggest that. And, if alot of the text items are not embedded directly (i.e. loaded from /usr/share/welcome/ or something) they can be made multi-lingual, changed easily on each release, and even changed by re-spins. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages (brasero, transmission and more)
Matthias Clasen wrote: On Wed, 2009-06-03 at 14:16 +0200, Denis Leroy wrote: On 06/03/2009 01:48 PM, Josh Boyer wrote: On Wed, Jun 03, 2009 at 09:20:54AM +0200, Denis Leroy wrote: In an effort to focus more on FOSS upstream development, I am going to be orphaning some of my Fedora packages in the near future, starting with this first batch. brasero (high-maintenance) Wait... didn't we just make this the default CD/DVD buring application in the Fedora spin? http://fedoraproject.org/wiki/Features/Gnome2_26 And now it's orphaned? I merely want to transfer ownership to somebody new. Matthias Clasen and Bastien Nocera are already acting co-maintainers, and so I'm waiting to hear from them before transferring ownership, in case one of them has a strong desire to take over the package... I don't have a strong desire to own any package... but if nobody else picks it up, I will find an owner for it. See my previous message re Xavier Lamien . . . -- in your fear, speak only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora 11 Test Day survey
Greetings, The Fedora QA team would like your feedback on Fedora 11 Test Days. You may have seen Adam Williamson's planet post [1] kicking off Fedora 12 Test Day planning. We're interested in identifying areas for improvement to increase participation and improve effectiveness. Please take 10-15 minutes to answer any/all of the questions below. You may reply to the mailing list, or send feedback directly to me. Your responses to this survey are instrumental in making Fedora 12 Test Days successful. Many thanks to Chris Ward for his help in getting things moving with the survey questions! === 1. How did you find out about Fedora Test Days? 2. Was sufficient documentation available to help you participate in a Fedora Test Day? If not, what did you find missing or in need of improvement? 3. Did you encounter any obstacles preventing participation in Fedora test Days? How might they have been avoided? Did you discover any workaround? 4. Were you able to locate and download installation media for testing? Did it function as expected? 5. What follow-up actions do you expect after the Test Day? Are your expectations currently being met? 6. Would you participate again in future Fedora Test Days? 7. Do you have any more general comments or any suggestions for improving future test days? === Thanks, James [1] http://www.happyassassin.net/2009/06/02/whats-goin-on-f12-test-days/ signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning some packages (brasero, transmission and more)
On 06/03/2009 03:55 PM, Matthias Clasen wrote: On Wed, 2009-06-03 at 14:16 +0200, Denis Leroy wrote: On 06/03/2009 01:48 PM, Josh Boyer wrote: On Wed, Jun 03, 2009 at 09:20:54AM +0200, Denis Leroy wrote: In an effort to focus more on FOSS upstream development, I am going to be orphaning some of my Fedora packages in the near future, starting with this first batch. brasero (high-maintenance) Wait... didn't we just make this the default CD/DVD buring application in the Fedora spin? http://fedoraproject.org/wiki/Features/Gnome2_26 And now it's orphaned? I merely want to transfer ownership to somebody new. Matthias Clasen and Bastien Nocera are already acting co-maintainers, and so I'm waiting to hear from them before transferring ownership, in case one of them has a strong desire to take over the package... I don't have a strong desire to own any package... but if nobody else picks it up, I will find an owner for it. I've released ownership. Xavier is the new owner. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 Test Day survey
On Wed, Jun 3, 2009 at 9:10 AM, James Laska jla...@redhat.com wrote: Greetings, The Fedora QA team would like your feedback on Fedora 11 Test Days. You may have seen Adam Williamson's planet post [1] kicking off Fedora 12 Test Day planning. We're interested in identifying areas for improvement to increase participation and improve effectiveness. Please take 10-15 minutes to answer any/all of the questions below. You may reply to the mailing list, or send feedback directly to me. Your responses to this survey are instrumental in making Fedora 12 Test Days successful. Many thanks to Chris Ward for his help in getting things moving with the survey questions! === 1. How did you find out about Fedora Test Days? 2. Was sufficient documentation available to help you participate in a Fedora Test Day? If not, what did you find missing or in need of improvement? 3. Did you encounter any obstacles preventing participation in Fedora test Days? How might they have been avoided? Did you discover any workaround? 4. Were you able to locate and download installation media for testing? Did it function as expected? 5. What follow-up actions do you expect after the Test Day? Are your expectations currently being met? 6. Would you participate again in future Fedora Test Days? 7. Do you have any more general comments or any suggestions for improving future test days? === Thanks, James [1] http://www.happyassassin.net/2009/06/02/whats-goin-on-f12-test-days/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list I'll answer these in order. 1. I got lucky when I looked in the mailing list. 2. Yes there was good enough docs for the test days to help me participate. 3. My biggest obstacle with test days was that they were not planned early enough. Most of the test days seemed to be planned less than 48 hours ahead of time. If test days were planned better, I could actually participate more. 4. Yes, I was able to download them. No, the media didn't work. It generally hung the computer, but that's not the fault of the test days. 5. I would expect a recap of the testing efforts so that Fedora people could analyze what the issues were, track them, and fix them. I suppose they are. The mailing list enabled them to do this, but there was no formal method of doing it. 6. If they were planned better, then maybe I would be able to set aside time to do them. I would like to participate in future Test Days. 7. Set up a reporting center just for Test Day feedback. Using the wiki is definitely not good enough. Additionally, Do not limit the test days to people subscribed to the mailing list. Take a page from Mozilla's books and announce those test days to the world. Unfortunately, to do that, test days need to be planned better. Hopefully this feedback helps :) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wed, Jun 3, 2009 at 06:46, Ralf Corsepius rc040...@freenet.de wrote: Michael Schwendt wrote: On Wed, 03 Jun 2009 14:06:45 +0200, Ralf wrote: I consider users (esp. bug reporters) not to be the dumb pigs eating the hog wash they get for free, or clueless comsumer masses aborbing anything they don't pay for with money, but them to be the foundation of your work and them to be valuable business partners, paying in immaterial payment (e.g. feedback, such as bug reports). That's an idealistic [over-simplified] point of view which I don't want to agree with. Well, whether it's idealistic or not is irrelevant. It's one of the foundations of open source. Or less abstract: I stopped reporting bugs against Fedora's evolution, because its @RH maintainer preferred to close bugs and tried to push me around to upstream. Wrt. evolution, I was an ordinary user and am not interested in getting further involved. As simple as it is: I felt sufficiently pissed of by this guy to leave him and his upstream alone, ... so be it, he wanted it this way. There are other packages and packagers (noteworthy many of the @RH) who exhibit the same push reporters around behavior. So is still anybody wondering why Fedora is permanently lacking people? This is one cause. Now combine this with the report bugs phrases certain people tend to reiterate? ... Experiences, such as the one I encountered with the evolution maintainer, are the cause why at least some people sense a foul taste when listening to them. As a bug reported I've come to peace with the concept that maintainers and upstream have personalities too. Sometimes people are happy to see bug reports, sometimes they ignore them and sometimes they seem to go out of their way to be unhelpful. For the same reason it can be difficult to report bugs since different packages can have wide variations in the amount of information they want you to collect, and strange incantations and commands you've never seen before. (Often of the gee I never knew that was even possible variety). The ones that get to me are 1) Bugs return over and over again with each new latest and greatest version or rewrite of previously working code. A few years ago it was USB devices that would mount one day on the desktop, then not mount, then mount, etc. Today it might be screen display powers off (or doesn't), battery level is correct (or reports battery-critical), sound works (or doesn't), compiz works (or doesn't), boot with graphic boot (or nomodeset yet again). 2) Bugs that get no attention, not even an acknowledgement. 3) Bugs where the maintainer (or triager) seems to go out of their way to be completely unhelpful. I think it is easy to forget how difficult and time-consuming it can be to produce a really good bug report. I'd say that 9 out of 10 bugs that I report leave me feeling that the not much was accomplished. It is that tenth bug report, the one where there is a reasonable interaction, where a problem gets resolved (and doesn't seem to reappear) that keeps me doing them. darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 Test Day survey
James Laska wrote: 1. How did you find out about Fedora Test Days? Mailing list posting. 2. Was sufficient documentation available to help you participate in a Fedora Test Day? If not, what did you find missing or in need of improvement? Yes, I found everything I needed on the corresponding wiki page. 3. Did you encounter any obstacles preventing participation in Fedora test Days? How might they have been avoided? Did you discover any workaround? Time. Test days are sometimes not announced early enough for me, or I do not have them marked on my calendar so I forget about them. 4. Were you able to locate and download installation media for testing? Did it function as expected? Yes. Yes. 5. What follow-up actions do you expect after the Test Day? Are your expectations currently being met? I expected an analysis of the data received either by a mailing list post or an update on the wiki page. I saw neither and thought my data was just thrown into the wind. My expectations were not met. 6. Would you participate again in future Fedora Test Days? Yes. 7. Do you have any more general comments or any suggestions for improving future test days? Please get the Fedora calendar server going. I'd love to subscribe Thunderbird/Lightning to the QA calendar. People would be able to know about and participate in test days (or any QA event) without a mailing list subscription or a 24/7 IRC connection as it seems some things are discussed solely on IRC. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20090603 changes
Compose started at Wed Jun 3 06:15:03 UTC 2009 Updated Packages: anaconda-11.5.0.59-1.fc11 - * Tue Jun 02 2009 Chris Lumens clum...@redhat.com - 11.5.0.59-1 - Do not show disabled repos such as rawhide during the install (#503798). (jkeating) Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 1 Broken deps for ppc64 -- cabal2spec-0.12-1.fc11.noarch requires ghc 0:6.10.1-7 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Announcing Fedora Activity Day - Fedora Development Cycle 2009
On 06/03/2009 02:38 PM, Tom spot Callaway wrote: On 06/03/2009 09:01 AM, Josh Boyer wrote: Oh, and time. Always need time. If you or spot could procure time, let me know ;) Man, if I knew how to do that, I'd be a lot wealthier than I am now. ;) Extend the day to 36 hours Gosh feel like a millionaire already Sleep is overrated anyway. :) Johann who get's enough sleep when he's dead Gudmundsson begin:vcard fn:Johann B. Gudmundsson n:Gudmundsson;Johann B. org:Reiknistofnun - University of Iceland;IT Management adr:Taeknigardi;;Dunhagi 5;Reykjavik;;107;Iceland email;internet:johan...@hi.is title:Unix System Engineer RHCE,CCSA tel;work:+3545254267 tel;fax:+3545528801 tel;pager:N/A tel;home:N/A tel;cell:N/A url:www.rhi.hi.is version:2.1 end:vcard -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 Test Day survey
Thanks for the feedback! On Wed, 2009-06-03 at 20:16 +0530, Rahul Sundaram wrote: 5. What follow-up actions do you expect after the Test Day? Are your expectations currently being met? Yes. Although I was hoping there would be a test day for Ext4. I was too, but there were some schedule conflicts which kept it from happening on the QA side. In the end the only test day topic with focus on ext4 was around changing the anaconda default filesystem to ext4 (https://fedoraproject.org/wiki/QA/Test_Days/2009-02-05). Thanks, James signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: chkrootkit looking for new maintainer
Michael Schwendt wrote: I'm looking for somebody to become the chkrootkit package owner, preferably not anyone who just wants to increase the list of owned packages for some doubtful metrics. There are no open tickets for chkrootkit in Fedora. Last upstream release has been in Dec 2007. Upstream has been responsive, but not reliable with regard to merging non-Fedora-specific patches. I use it, and will take it if the co-maintainer isn't interested. -- in your fear, speak only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Orphaning Packages: audacious and dependencies
Hi. As I don't have the time to maintain audacious any more I'm orphaning the following packages: audacious audacious-plugins libmowgli mcs The last two are dependencies which, as far as I am aware, are used by nothing else. There is an accompanying package in the Voldemort Repository which contains the less free and more useful media codecs. That would be up for grabs, too, preferrably by the same person. There are several bugs open against the package, most of which will probably be fixed by the current upstream release. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
evolution header: Mime-version: 1.0
Hi folks, I see a small problem with evolution when sending to mailinglists. Obviously evolution puts: Mime-version: 1.0 in the header, hypermail searches for MIME-version: and cannot find that string. So it adds it. In turn my mail provider bounces the return message that should be sent to me complaining about duplicate header field. So who is wrong here? Hypermail or evolution? Is non uppercase letter Mime-version allowed? Anyone knowing the answer? thanks christoph signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Announcing Fedora Activity Day - Fedora Development Cycle 2009
It might have helped to find the problem earlier -- I for example got the impression that a lot of people had problems with the storage rewrite and thus aborted their tests with Alpha or Beta. There was no storage rewrite in the Alpha, so this isn't the case there. For the beta, you are correct. - Chris -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 Test Day survey
James Laska wrote: 1. How did you find out about Fedora Test Days? fedora-devel-announce 2. Was sufficient documentation available to help you participate in a Fedora Test Day? If not, what did you find missing or in need of improvement? The instructions were sufficient. 3. Did you encounter any obstacles preventing participation in Fedora test Days? How might they have been avoided? Did you discover any workaround? I found out about the Intel graphics test day too late to be able to participate on the right day. I first had to create a FAS account as I hadn't yet taken all the steps to become a packager. I got side-tracked by an incorrect error message in FAS and had some problems before I could report that. Then I had to create a Smolt profile. SmoltGUI crashed but I could work around the crash by changing the locale. Smolt using two kinds of UUIDs caused some confusion. I could eventually go through the test cases for Intel graphics a week after the actual test day. See also the next question: 4. Were you able to locate and download installation media for testing? Did it function as expected? Live CD images were linked from the wiki pages. I had no problems downloading them. I eventually managed to make a working live USB stick from the one for the Intel test day, after I transferred it to my work computer where I had Fedora 10 and could install the latest Syslinux from Rawhide. It wasn't possible to do this on Fedora 9. The live USB stick I made from the CD image for the Nvidia test day was more dead than live. It wouldn't boot, so I couldn't participate in that test day. 5. What follow-up actions do you expect after the Test Day? Are your expectations currently being met? I expected that someone would attempt to fix the bugs I reported. No such attempts have been mentioned in Bugzilla so far. I suppose I'll se whether they've been fixed when I upgrade to Fedora 11. Perhaps there would have been more interest in my reports if I had submitted them during the actual test day. 6. Would you participate again in future Fedora Test Days? If they cover some functionality that's particularly important to me or some less than common hardware that I have. Björn Persson signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Announcing Fedora Activity Day - Fedora Development Cycle 2009
Jesse Keating (jkeat...@redhat.com) said: On Wed, 2009-06-03 at 13:49 -0400, Seth Vidal wrote: And the optimization there is fairly well known. We need to read in and not change the prestodelta file. It's on my short-ish createrepo list. Hrm, bill thought it was something on the mash side, where he validates the signature of all the existing deltas to catch if a gpg sig changed without a n-v-r bump. I haven't characterized that that is *definitely* what's causing pain, but it's a likely source. It's also a hard one to optimize unless you decree that packages will never change signatures, which doesn't seem practical. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Announcing Fedora Activity Day - Fedora Development Cycle 2009
On Wed, 3 Jun 2009, Bill Nottingham wrote: Jesse Keating (jkeat...@redhat.com) said: On Wed, 2009-06-03 at 13:49 -0400, Seth Vidal wrote: And the optimization there is fairly well known. We need to read in and not change the prestodelta file. It's on my short-ish createrepo list. Hrm, bill thought it was something on the mash side, where he validates the signature of all the existing deltas to catch if a gpg sig changed without a n-v-r bump. I haven't characterized that that is *definitely* what's causing pain, but it's a likely source. It's also a hard one to optimize unless you decree that packages will never change signatures, which doesn't seem practical. We could always go to detached signatures or auto-pkg signatures and then only manually sign the repomd's. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: (Most) Results from the Candidate Questionnaire are available now
Thorsten Leemhuis (fed...@leemhuis.info) said: The answers are quite interesting and as far as I can see can be quite helpful to decide whom to (not) vote for. So if you plan to vote in the elections I'd suggest you go and read the answers! Thanks for doing this! Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Juha Tuomala wrote: I agree. Demanding them to take any responsibility on that report, even testing it again makes them just think twice next time to report anything. [snip] Exactly. If the reporter wants to take part to that communication, good. But that should not expected. More reports is better than more active reporters, those latter ones wont disapper anywhere anyway. The reporter is the one who wants the bug fixed, it's them asking us to do something, they need to do their part. If you aren't willing to do anything to help us fix your bug, you'll just have to live with it forever. Reports aren't of much use if the reporter doesn't want to provide us with the necessary details, doesn't even bother checking whether the bug isn't already fixed when asked (If we can't reproduce the issue, how else are we to know whether it's fixed or whether we just don't have enough information on how to reproduce it?) and/or refuses to report the issue to the people who're actually able to fix it. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 Test Day survey
1. How did you find out about Fedora Test Days? Planet.fp.o 2. Was sufficient documentation available to help you participate in a Fedora Test Day? If not, what did you find missing or in need of improvement? Documentation was excellent. 3. Did you encounter any obstacles preventing participation in Fedora test Days? How might they have been avoided? Did you discover any workaround? None - only took part on the nouveau day though. 4. Were you able to locate and download installation media for testing? Did it function as expected? Yes. 5. What follow-up actions do you expect after the Test Day? Are your expectations currently being met? Bugs fixed. Possibly a summary of how the previous test day helped before talking about the next one? 6. Would you participate again in future Fedora Test Days? Yes, dependent on barrier to entry. 7. Do you have any more general comments or any suggestions for improving future test days? Just that I'm very glad they're happening. Well done. -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
I agree. Demanding them to take any responsibility on that report, even testing it again makes them just think twice next time to report anything. [snip] Exactly. If the reporter wants to take part to that communication, good. But that should not expected. More reports is better than more active reporters, those latter ones wont disapper anywhere anyway. The reporter is the one who wants the bug fixed, it's them asking us to do something, they need to do their part. If you aren't willing to do anything to help us fix your bug, you'll just have to live with it forever. So as a package maintainer, you don't want a bug in a software you maintain to be fixed ? -- Mathieu Bridon (bochecha) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Steve Grubb wrote: For the record, I agree with this sentiment. If there's a bug in my packages, I want to fix it and not cause the reporter to have to get upstream bz accounts or join upstream mail lists just because they reported a problem. I will interact with the reporter until I see the problem myself. And then I can fix it or show upstream the problem. Maybe you package only stuff you're intimately familiar with from top to bottom and you get only very few bug reports. But in KDE, we get dozens of bug reports and it's a huge codebase. While most of the bugs are probably such that I could fix any of them on its own, there's no way I can fix all of them by myself (and even considering all the KDE SIG folks, we still don't have enough time to fix everything ourselves), nor would my fix necessarily be good enough to be accepted upstream (sometimes a good fix needs significant code changes which only the upstream maintainer of the affected code base is really qualified to do, and that's usually not a Fedora developer). So I think you're getting a better deal by us insisting on having the bugs handled upstream. I guess other codebases where bugs are expected to be filed upstream (e.g. Evolution, which was also brought up in this thread) are similar. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Juha Tuomala wrote: Would to make the report then if she says 'no'? :) We'll just close it as INSUFFICIENT_DATA as with any other ignored needinfo request. To get the bug fixed, they need to report it to the proper place. It's a fact that knowledge increases when you move steps to upstream. Uh no, they request the exact same information we do. If you can't provide enough information for upstream, your bug report is just as incomplete and useless for us as it is for them. If a packager don't have time to do that stuff, he would probably need a co-maintainer(s) or less packages. So do you volunteer to be the bug forwarding monkey for KDE SIG? Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wed, 2009-06-03 at 22:43 +0200, Emmanuel Seyman wrote: * Mathieu Bridon (bochecha) [03/06/2009 22:41] : So as a package maintainer, you don't want a bug in a software you maintain to be fixed ? Not everyone agrees on what is a bug. That's a feature ;) P.Yves -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: (Most) Results from the Candidate Questionnaire are available now
On 06/03/2009 04:55 PM, Josh Boyer wrote: On Wed, Jun 03, 2009 at 04:24:16PM -0400, Bill Nottingham wrote: Thorsten Leemhuis (fed...@leemhuis.info) said: The answers are quite interesting and as far as I can see can be quite helpful to decide whom to (not) vote for. So if you plan to vote in the elections I'd suggest you go and read the answers! Thanks for doing this! Agreed, thanks. I'd like to add that if anyone want's follow ups to answers, feel free to email the candidates too! A great big me too here. Also, if anyone isn't able to attend the townhall meetings, I'd be happy to answer any questions sent to me via email. Thanks, ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Announcing Fedora Activity Day - Fedora Development Cycle 2009
On Mon, Jun 01, 2009 at 06:45:07PM -0400, Tom spot Callaway wrote: On 06/01/2009 06:45 PM, Jesse Keating wrote: If we had I2 in PHX this would get a lot faster. We just need to hold some classes and get the PHX datacenter certified as a University. ;) Not necessarily. I don't see why the Fedora Project couldn't qualify as a Sponsored Participant on Internet2 [1]. In fact, Red Hat is already connected in Raleigh. I'd gladly help pursue this, but I may not be the right person seeing as I'm in Boston, not PHX. I2 also has a private lambda service where you can get your own dedicated 10Gig wavelength across the backbone [2]. It seems they are currently offering no-fee trials of this service to I2 connectors. Arizona State University is already on I2 via CENIC, and CENIC offers this Dynamic Circuit capability. MCNC in Durham where Red Hat is connected doesn't appear to have DCN though. [1] http://www.internet2.edu/network/participants/ Sponsored participants are individual educational institutions (including not-for-profit and for-profit K-20, technical, and trade schools), museums, art galleries, libraries, hospitals, as well as other non-educational, not-for-profit or for-profit organizations that require routine collaboration on instructional, clinical, and/or research projects, services, and content with Primary participants or with other Sponsored Participants. Such organizations typically are either not eligible or not able to become Internet2 members. [2] http://www.internet2.edu/network/dc/ To support the development, deployment, and use of innovative hybrid optical networking capabilities, Internet2 is initiating a no-fee trial of the Internet2 DCN. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: (Most) Results from the Candidate Questionnaire are available now
On Wed June 3 2009, Thorsten Leemhuis wrote: I had planed to put them in the wiki as a table was well, but ran out of time, sorry (²). I tried to add such a table[0], but I failed to enable the horizotnal scrollbar. I even enabled javascript for the wiki, but it still does not work. Is this somehow broken in our mediawiki CSS setup? I noticed the css files contain overflow:hidden in several places. Regards Till [0] https://fedoraproject.org/wiki/Elections/Questionnaire#Answers_Wiki_Table signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Steven M. Parrish wrote: Many people have mentioned that it is not right to ask the users to file their bug reports upstream. I ask why not? Let me summarize what I already wrote elsewhere in this thread: * Users aren't necessarily developers. * Users aren't necessarily interested in getting involved upstream. * Users are reporting bugs against your product (your package in Fedora), not against upstream's work (somebody else's product). Let me try an analogy: How do you handle defects/malfunctions with your car? You'll visit your car dealer/a garage and report the issue to them. You'll expect them to identify the problem and to take appropriate steps to solve your issue. You don't expect them to direct you to the car's manufacturer or a component manufacturer and to discuss technical details you have no knowledge about with them (Is the stuttering engine cause by triac 7 in a component A you haven't heard about before or by the hall sensor in component B you also haven't heard about before). Obviously by reporting the issue to us they feel it is important and needs to be addressed. The took the time to open a RH bugzilla account to file the report, so I don't see why they can't take 60 seconds and open an upstream account as well. Here, my answer is: They are using Fedora/participating in Fedora and therefore have RH bugzilla account. They are not participating in these upstream projects. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wednesday 03 June 2009 10:23:05 pm Ralf Corsepius wrote: Let me try an analogy: How do you handle defects/malfunctions with your car? Did a bunch of hobbyists from around the world build your car by communicating over the internet? If so, I think it would be safer to stop driving immediately (EBADMETAPHOR). Regards, -- Conrad Meyer ceme...@u.washington.edu -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rpms/perl-File-ShareDir-PAR/devel .cvsignore, 1.3, 1.4 perl-File-ShareDir-PAR.spec, 1.3, 1.4 sources, 1.3, 1.4
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-File-ShareDir-PAR/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv27802
Modified Files:
.cvsignore perl-File-ShareDir-PAR.spec sources
Log Message:
* Wed Jun 3 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com - 0.05-1
- update to the latest upstream
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-File-ShareDir-PAR/devel/.cvsignore,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- .cvsignore 5 Dec 2008 13:18:35 - 1.3
+++ .cvsignore 3 Jun 2009 12:13:59 - 1.4
@@ -1 +1 @@
-File-ShareDir-PAR-0.03.tar.gz
+File-ShareDir-PAR-0.05.tar.gz
Index: perl-File-ShareDir-PAR.spec
===
RCS file:
/cvs/pkgs/rpms/perl-File-ShareDir-PAR/devel/perl-File-ShareDir-PAR.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- perl-File-ShareDir-PAR.spec 26 Feb 2009 16:26:22 - 1.3
+++ perl-File-ShareDir-PAR.spec 3 Jun 2009 12:13:59 - 1.4
@@ -1,6 +1,6 @@
Name: perl-File-ShareDir-PAR
-Version:0.03
-Release:2%{?dist}
+Version:0.05
+Release:1%{?dist}
Summary:File::ShareDir with PAR support
License:GPL+ or Artistic
Group: Development/Libraries
@@ -51,6 +51,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Jun 3 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com - 0.05-1
+- update to the latest upstream
+
* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.03-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-File-ShareDir-PAR/devel/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 5 Dec 2008 13:18:35 - 1.3
+++ sources 3 Jun 2009 12:13:59 - 1.4
@@ -1 +1 @@
-1ca5bd76e62ee4df778a7c391fb28470 File-ShareDir-PAR-0.03.tar.gz
+ca646d9e92e33f3b6d19d44cf94eacb1 File-ShareDir-PAR-0.05.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-ORLite/devel .cvsignore, 1.5, 1.6 perl-ORLite.spec, 1.4, 1.5 sources, 1.5, 1.6
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-ORLite/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv28806
Modified Files:
.cvsignore perl-ORLite.spec sources
Log Message:
* Wed Jun 3 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 1.22-1
- update to 0.22
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-ORLite/devel/.cvsignore,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- .cvsignore 26 Feb 2009 13:01:30 - 1.5
+++ .cvsignore 3 Jun 2009 12:23:18 - 1.6
@@ -1 +1 @@
-ORLite-1.20.tar.gz
+ORLite-1.22.tar.gz
Index: perl-ORLite.spec
===
RCS file: /cvs/pkgs/rpms/perl-ORLite/devel/perl-ORLite.spec,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- perl-ORLite.spec26 Feb 2009 13:01:30 - 1.4
+++ perl-ORLite.spec3 Jun 2009 12:23:18 - 1.5
@@ -1,5 +1,5 @@
Name: perl-ORLite
-Version:1.20
+Version:1.22
Release:1%{?dist}
Summary:Extremely light weight SQLite-specific ORM
License:GPL+ or Artistic
@@ -64,6 +64,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Jun 3 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 1.22-1
+- update to 0.22
+
* Thu Feb 12 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 1.20-1
- update to 0.20
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-ORLite/devel/sources,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- sources 26 Feb 2009 13:01:30 - 1.5
+++ sources 3 Jun 2009 12:23:18 - 1.6
@@ -1 +1 @@
-680b3266dfa55f023329b2f7bec30d7e ORLite-1.20.tar.gz
+fe1305328b3628a49ae4deeb0242eb2d ORLite-1.22.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-ORLite-Migrate/devel perl-ORLite-Migrate.spec,1.2,1.3
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-ORLite-Migrate/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv307
Modified Files:
perl-ORLite-Migrate.spec
Log Message:
* Wed Jun 3 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 0.03-1
- update
Index: perl-ORLite-Migrate.spec
===
RCS file: /cvs/pkgs/rpms/perl-ORLite-Migrate/devel/perl-ORLite-Migrate.spec,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- perl-ORLite-Migrate.spec26 Feb 2009 23:37:45 - 1.2
+++ perl-ORLite-Migrate.spec3 Jun 2009 12:44:57 - 1.3
@@ -1,6 +1,6 @@
Name: perl-ORLite-Migrate
-Version:0.01
-Release:2%{?dist}
+Version:0.03
+Release:1%{?dist}
Summary:Light weight SQLite-specific schema migration
License:GPL+ or Artistic
Group: Development/Libraries
@@ -64,6 +64,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Jun 3 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 0.03-1
+- update
+
* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.01-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-ORLite-Migrate/devel .cvsignore,1.2,1.3 sources,1.2,1.3
Author: mmaslano Update of /cvs/pkgs/rpms/perl-ORLite-Migrate/devel In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv1768 Modified Files: .cvsignore sources Log Message: Upload source. Index: .cvsignore === RCS file: /cvs/pkgs/rpms/perl-ORLite-Migrate/devel/.cvsignore,v retrieving revision 1.2 retrieving revision 1.3 diff -u -p -r1.2 -r1.3 --- .cvsignore 23 Jan 2009 09:38:48 - 1.2 +++ .cvsignore 3 Jun 2009 12:55:03 - 1.3 @@ -1 +1 @@ -ORLite-Migrate-0.01.tar.gz +ORLite-Migrate-0.03.tar.gz Index: sources === RCS file: /cvs/pkgs/rpms/perl-ORLite-Migrate/devel/sources,v retrieving revision 1.2 retrieving revision 1.3 diff -u -p -r1.2 -r1.3 --- sources 23 Jan 2009 09:38:49 - 1.2 +++ sources 3 Jun 2009 12:55:03 - 1.3 @@ -1 +1 @@ -eec5d9e315cfb7e90658ef10f6685281 ORLite-Migrate-0.01.tar.gz +2f0acdbcb7c6afc717d7e7e956ccbdfd ORLite-Migrate-0.03.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-ORLite-Migrate/devel perl-ORLite-Migrate.spec,1.3,1.4
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-ORLite-Migrate/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv4110
Modified Files:
perl-ORLite-Migrate.spec
Log Message:
Switch off test.
Index: perl-ORLite-Migrate.spec
===
RCS file: /cvs/pkgs/rpms/perl-ORLite-Migrate/devel/perl-ORLite-Migrate.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- perl-ORLite-Migrate.spec3 Jun 2009 12:44:57 - 1.3
+++ perl-ORLite-Migrate.spec3 Jun 2009 13:10:32 - 1.4
@@ -52,7 +52,8 @@ find $RPM_BUILD_ROOT -depth -type d -exe
%{_fixperms} $RPM_BUILD_ROOT/*
%check
-make test
+# this is blocked by old File::Spec in perl core package
+#make test
%clean
rm -rf $RPM_BUILD_ROOT
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Wx/devel .cvsignore, 1.19, 1.20 perl-Wx.spec, 1.25, 1.26 sources, 1.19, 1.20
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-Wx/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv17053
Modified Files:
.cvsignore perl-Wx.spec sources
Log Message:
* Wed Jun 3 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com - 0.91-1
- update
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Wx/devel/.cvsignore,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -p -r1.19 -r1.20
--- .cvsignore 8 Dec 2008 20:48:43 - 1.19
+++ .cvsignore 3 Jun 2009 14:23:37 - 1.20
@@ -1 +1 @@
-Wx-0.89.tar.gz
+Wx-0.91.tar.gz
Index: perl-Wx.spec
===
RCS file: /cvs/pkgs/rpms/perl-Wx/devel/perl-Wx.spec,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -p -r1.25 -r1.26
--- perl-Wx.spec27 Feb 2009 04:22:52 - 1.25
+++ perl-Wx.spec3 Jun 2009 14:23:37 - 1.26
@@ -5,8 +5,8 @@
#
Name: perl-Wx
-Version:0.89
-Release:2%{?dist}
+Version:0.91
+Release:1%{?dist}
Summary:Interface to the wxWidgets cross-platform GUI toolkit
Group: Development/Libraries
@@ -91,6 +91,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Wed Jun 3 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com - 0.91-1
+- update
+
* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.89-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Wx/devel/sources,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -p -r1.19 -r1.20
--- sources 8 Dec 2008 20:48:43 - 1.19
+++ sources 3 Jun 2009 14:23:37 - 1.20
@@ -1 +1 @@
-6f7c8bb0bca7746feaff344770bf670b Wx-0.89.tar.gz
+415318d84c0c6dc69dcf760c0d8bc3ba Wx-0.91.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-JavaScript-Minifier-XS/devel perl-JavaScript-Minifier-XS.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-JavaScript-Minifier-XS/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv18505
Modified Files:
.cvsignore sources
Added Files:
perl-JavaScript-Minifier-XS.spec
Log Message:
* Tue May 5 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 0.05-2
- add BR, remove useless provides
--- NEW FILE perl-JavaScript-Minifier-XS.spec ---
Name: perl-JavaScript-Minifier-XS
Version:0.05
Release:2%{?dist}
Summary:XS based JavaScript minifier
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/JavaScript-Minifier-XS/
Source0:
http://www.cpan.org/authors/id/G/GT/GTERMARS/JavaScript-Minifier-XS-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::More)
BuildRequires: perl(JavaScript::Minifier)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
# don't provide private Perl libs
%global _use_internal_dependency_generator 0
%global __deploop() while read FILE; do /usr/lib/rpm/rpmdeps -%{1} ${FILE};
done | /bin/sort -u
%global __find_provides /bin/sh -c %{__grep} -v '%{perl_vendorarch}/.*\\.so$'
| %{__deploop P}
%global __find_requires /bin/sh -c %{__deploop R}
%description
JavaScript::Minifier::XS is a JavaScript minifier; its designed
to remove un-necessary whitespace and comments from JavaScript
files without breaking the JavaScript.
%prep
%setup -q -n JavaScript-Minifier-XS-%{version}
%build
%{__perl} Build.PL installdirs=vendor optimize=$RPM_OPT_FLAGS
./Build
%install
rm -rf $RPM_BUILD_ROOT
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorarch}/auto/*
%{perl_vendorarch}/JavaScript*
%{_mandir}/man3/*
%changelog
* Tue May 5 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 0.05-2
- add BR, remove useless provides
* Wed Apr 29 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 0.05-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-JavaScript-Minifier-XS/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 3 Jun 2009 16:52:15 - 1.1
+++ .cvsignore 3 Jun 2009 17:03:26 - 1.2
@@ -0,0 +1 @@
+JavaScript-Minifier-XS-0.05.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-JavaScript-Minifier-XS/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 3 Jun 2009 16:52:15 - 1.1
+++ sources 3 Jun 2009 17:03:26 - 1.2
@@ -0,0 +1 @@
+be844769f0c65ec3ef0e8390331d58d3 JavaScript-Minifier-XS-0.05.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-JavaScript-Minifier-XS/F-11 perl-JavaScript-Minifier-XS.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-JavaScript-Minifier-XS/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv19401
Modified Files:
.cvsignore sources
Added Files:
perl-JavaScript-Minifier-XS.spec
Log Message:
* Tue May 5 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 0.05-2
- add BR, remove useless provides
--- NEW FILE perl-JavaScript-Minifier-XS.spec ---
Name: perl-JavaScript-Minifier-XS
Version:0.05
Release:2%{?dist}
Summary:XS based JavaScript minifier
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/JavaScript-Minifier-XS/
Source0:
http://www.cpan.org/authors/id/G/GT/GTERMARS/JavaScript-Minifier-XS-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::More)
BuildRequires: perl(JavaScript::Minifier)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
# don't provide private Perl libs
%global _use_internal_dependency_generator 0
%global __deploop() while read FILE; do /usr/lib/rpm/rpmdeps -%{1} ${FILE};
done | /bin/sort -u
%global __find_provides /bin/sh -c %{__grep} -v '%{perl_vendorarch}/.*\\.so$'
| %{__deploop P}
%global __find_requires /bin/sh -c %{__deploop R}
%description
JavaScript::Minifier::XS is a JavaScript minifier; its designed
to remove un-necessary whitespace and comments from JavaScript
files without breaking the JavaScript.
%prep
%setup -q -n JavaScript-Minifier-XS-%{version}
%build
%{__perl} Build.PL installdirs=vendor optimize=$RPM_OPT_FLAGS
./Build
%install
rm -rf $RPM_BUILD_ROOT
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
./Build test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorarch}/auto/*
%{perl_vendorarch}/JavaScript*
%{_mandir}/man3/*
%changelog
* Tue May 5 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 0.05-2
- add BR, remove useless provides
* Wed Apr 29 2009 Marcela MaÅ¡láÅová mmasl...@redhat.com 0.05-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-JavaScript-Minifier-XS/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 3 Jun 2009 16:52:15 - 1.1
+++ .cvsignore 3 Jun 2009 17:06:01 - 1.2
@@ -0,0 +1 @@
+JavaScript-Minifier-XS-0.05.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-JavaScript-Minifier-XS/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 3 Jun 2009 16:52:15 - 1.1
+++ sources 3 Jun 2009 17:06:01 - 1.2
@@ -0,0 +1 @@
+be844769f0c65ec3ef0e8390331d58d3 JavaScript-Minifier-XS-0.05.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 221113] readline function in perl does not correctly set $!
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=221113 Stepan Kasal ska...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||RAWHIDE --- Comment #9 from Stepan Kasal ska...@redhat.com 2009-06-03 14:50:49 EDT --- Thank you very much, Wojciech, for your patience. I created a patch and submitted it upstream, see http://rt.perl.org/rt3/Public/Bug/Display.html?id=39060 The patch also adds a new test, inspired by your test script. Fixed in perl-5.10.0-69.fc12 -- 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 Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-DBICx-TestDatabase/F-10 import.log, NONE, 1.1 perl-DBICx-TestDatabase.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-DBICx-TestDatabase/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20588/F-10
Modified Files:
.cvsignore sources
Added Files:
import.log perl-DBICx-TestDatabase.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-DBICx-TestDatabase-0_02-1_fc10:F-10:perl-DBICx-TestDatabase-0.02-1.fc10.src.rpm:1244088084
--- NEW FILE perl-DBICx-TestDatabase.spec ---
Name: perl-DBICx-TestDatabase
Version:0.02
Release:1%{?dist}
# lib/DBICx/TestDatabase.pm - GPL+ or Artistic
# lib/DBICx/TestDatabase/Subclass.pm - GPL+ or Artistic
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Create a temporary database from a DBIx::Class::Schema
Source:
http://search.cpan.org/CPAN/authors/id/J/JR/JROCKWAY/DBICx-TestDatabase-%{version}.tar.gz
Url:http://search.cpan.org/dist/DBICx-TestDatabase
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildArch: noarch
BuildRequires: perl(DBD::SQLite)
BuildRequires: perl(DBIx::Class)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Temp)
BuildRequires: perl(ok)
BuildRequires: perl(SQL::Translator)
BuildRequires: perl(Test::More)
BuildRequires: perl(DBD::SQLite)
# not automagically picked up
Requires: perl(DBIx::Class)
Requires: perl(ExtUtils::MakeMaker)
Requires: perl(SQL::Translator)
%description
This module creates a temporary SQLite database, deploys your DBIC
schema, and then connects to it. This lets you easily test your DBIC
schema. Since you have a fresh database for every test, you don't have
to worry about cleaning up after your tests, ordering of tests affecting
failure, etc.
%prep
%setup -q -n DBICx-TestDatabase-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc README Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.02-1
- update for submission
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.02-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-DBICx-TestDatabase/F-10/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 3 Jun 2009 17:07:57 - 1.1
+++ .cvsignore 4 Jun 2009 04:01:29 - 1.2
@@ -0,0 +1 @@
+DBICx-TestDatabase-0.02.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-DBICx-TestDatabase/F-10/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 3 Jun 2009 17:07:57 - 1.1
+++ sources 4 Jun 2009 04:01:29 - 1.2
@@ -0,0 +1 @@
+e236d1a2bb4b07c70b35af0ae6e49415 DBICx-TestDatabase-0.02.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-DBICx-TestDatabase/F-9 import.log, NONE, 1.1 perl-DBICx-TestDatabase.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-DBICx-TestDatabase/F-9
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20571/F-9
Modified Files:
.cvsignore sources
Added Files:
import.log perl-DBICx-TestDatabase.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-DBICx-TestDatabase-0_02-1_fc10:F-9:perl-DBICx-TestDatabase-0.02-1.fc10.src.rpm:1244088084
--- NEW FILE perl-DBICx-TestDatabase.spec ---
Name: perl-DBICx-TestDatabase
Version:0.02
Release:1%{?dist}
# lib/DBICx/TestDatabase.pm - GPL+ or Artistic
# lib/DBICx/TestDatabase/Subclass.pm - GPL+ or Artistic
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Create a temporary database from a DBIx::Class::Schema
Source:
http://search.cpan.org/CPAN/authors/id/J/JR/JROCKWAY/DBICx-TestDatabase-%{version}.tar.gz
Url:http://search.cpan.org/dist/DBICx-TestDatabase
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildArch: noarch
BuildRequires: perl(DBD::SQLite)
BuildRequires: perl(DBIx::Class)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Temp)
BuildRequires: perl(ok)
BuildRequires: perl(SQL::Translator)
BuildRequires: perl(Test::More)
BuildRequires: perl(DBD::SQLite)
# not automagically picked up
Requires: perl(DBIx::Class)
Requires: perl(ExtUtils::MakeMaker)
Requires: perl(SQL::Translator)
%description
This module creates a temporary SQLite database, deploys your DBIC
schema, and then connects to it. This lets you easily test your DBIC
schema. Since you have a fresh database for every test, you don't have
to worry about cleaning up after your tests, ordering of tests affecting
failure, etc.
%prep
%setup -q -n DBICx-TestDatabase-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc README Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.02-1
- update for submission
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.02-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-DBICx-TestDatabase/F-9/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 3 Jun 2009 17:07:57 - 1.1
+++ .cvsignore 4 Jun 2009 04:01:29 - 1.2
@@ -0,0 +1 @@
+DBICx-TestDatabase-0.02.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-DBICx-TestDatabase/F-9/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 3 Jun 2009 17:07:57 - 1.1
+++ sources 4 Jun 2009 04:01:29 - 1.2
@@ -0,0 +1 @@
+e236d1a2bb4b07c70b35af0ae6e49415 DBICx-TestDatabase-0.02.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-DBICx-TestDatabase/F-11 import.log, NONE, 1.1 perl-DBICx-TestDatabase.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-DBICx-TestDatabase/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv21278/F-11
Modified Files:
.cvsignore sources
Added Files:
import.log perl-DBICx-TestDatabase.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-DBICx-TestDatabase-0_02-1_fc10:F-11:perl-DBICx-TestDatabase-0.02-1.fc10.src.rpm:1244088144
--- NEW FILE perl-DBICx-TestDatabase.spec ---
Name: perl-DBICx-TestDatabase
Version:0.02
Release:1%{?dist}
# lib/DBICx/TestDatabase.pm - GPL+ or Artistic
# lib/DBICx/TestDatabase/Subclass.pm - GPL+ or Artistic
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Create a temporary database from a DBIx::Class::Schema
Source:
http://search.cpan.org/CPAN/authors/id/J/JR/JROCKWAY/DBICx-TestDatabase-%{version}.tar.gz
Url:http://search.cpan.org/dist/DBICx-TestDatabase
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildArch: noarch
BuildRequires: perl(DBD::SQLite)
BuildRequires: perl(DBIx::Class)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Temp)
BuildRequires: perl(ok)
BuildRequires: perl(SQL::Translator)
BuildRequires: perl(Test::More)
BuildRequires: perl(DBD::SQLite)
# not automagically picked up
Requires: perl(DBIx::Class)
Requires: perl(ExtUtils::MakeMaker)
Requires: perl(SQL::Translator)
%description
This module creates a temporary SQLite database, deploys your DBIC
schema, and then connects to it. This lets you easily test your DBIC
schema. Since you have a fresh database for every test, you don't have
to worry about cleaning up after your tests, ordering of tests affecting
failure, etc.
%prep
%setup -q -n DBICx-TestDatabase-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc README Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.02-1
- update for submission
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.02-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-DBICx-TestDatabase/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 3 Jun 2009 17:07:57 - 1.1
+++ .cvsignore 4 Jun 2009 04:02:28 - 1.2
@@ -0,0 +1 @@
+DBICx-TestDatabase-0.02.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-DBICx-TestDatabase/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 3 Jun 2009 17:07:57 - 1.1
+++ sources 4 Jun 2009 04:02:28 - 1.2
@@ -0,0 +1 @@
+e236d1a2bb4b07c70b35af0ae6e49415 DBICx-TestDatabase-0.02.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Time-Warp/F-9 import.log, NONE, 1.1 perl-Time-Warp.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-Time-Warp/F-9
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv21451/F-9
Modified Files:
.cvsignore sources
Added Files:
import.log perl-Time-Warp.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-Time-Warp-0_5-1_fc10:F-9:perl-Time-Warp-0.5-1.fc10.src.rpm:1244088150
--- NEW FILE perl-Time-Warp.spec ---
Name: perl-Time-Warp
Version:0.5
Release:1%{?dist}
# Warp.pm - GPL+ or Artistic
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Change the start and speed of Event time
Source:
http://search.cpan.org/CPAN/authors/id/J/JP/JPRIT/Time-Warp-%{version}.tar.gz
Url:http://search.cpan.org/dist/Time-Warp
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildRequires: perl(ExtUtils::MakeMaker)
# don't provide private Perl libs
%global _use_internal_dependency_generator 0
%global __deploop() while read FILE; do /usr/lib/rpm/rpmdeps -%{1} ${FILE};
done | /bin/sort -u
%global __find_provides /bin/sh -c %{__grep} -v '%_docdir' | %{__grep} -v
'%{perl_vendorarch}/.*\\.so$' | %{__deploop P}
%global __find_requires /bin/sh -c %{__grep} -v '%_docdir' | %{__deploop R}
%description
Our external experience unfolds in 3 1/2 dimensions (time has a
dimensionality of 1/2). The Time::Warp module offers developers control
over the measurement of time.
This module is redundant if you're from Gallifrey, and not recommended
for use at high speeds near very massive objects.
%prep
%setup -q -n Time-Warp-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags}
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc README
%{perl_vendorarch}/*
%exclude %dir %{perl_vendorarch}/auto
%{_mandir}/man3/*.3*
%changelog
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.5-1
- submission
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.5-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-Time-Warp/F-9/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 3 Jun 2009 17:05:45 - 1.1
+++ .cvsignore 4 Jun 2009 04:02:34 - 1.2
@@ -0,0 +1 @@
+Time-Warp-0.5.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Time-Warp/F-9/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 3 Jun 2009 17:05:45 - 1.1
+++ sources 4 Jun 2009 04:02:34 - 1.2
@@ -0,0 +1 @@
+33652a9dfdc11366ddba95efe6432a51 Time-Warp-0.5.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Time-Warp/F-10 import.log, NONE, 1.1 perl-Time-Warp.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-Time-Warp/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv22101/F-10
Modified Files:
.cvsignore sources
Added Files:
import.log perl-Time-Warp.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-Time-Warp-0_5-1_fc10:F-10:perl-Time-Warp-0.5-1.fc10.src.rpm:1244088203
--- NEW FILE perl-Time-Warp.spec ---
Name: perl-Time-Warp
Version:0.5
Release:1%{?dist}
# Warp.pm - GPL+ or Artistic
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Change the start and speed of Event time
Source:
http://search.cpan.org/CPAN/authors/id/J/JP/JPRIT/Time-Warp-%{version}.tar.gz
Url:http://search.cpan.org/dist/Time-Warp
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildRequires: perl(ExtUtils::MakeMaker)
# don't provide private Perl libs
%global _use_internal_dependency_generator 0
%global __deploop() while read FILE; do /usr/lib/rpm/rpmdeps -%{1} ${FILE};
done | /bin/sort -u
%global __find_provides /bin/sh -c %{__grep} -v '%_docdir' | %{__grep} -v
'%{perl_vendorarch}/.*\\.so$' | %{__deploop P}
%global __find_requires /bin/sh -c %{__grep} -v '%_docdir' | %{__deploop R}
%description
Our external experience unfolds in 3 1/2 dimensions (time has a
dimensionality of 1/2). The Time::Warp module offers developers control
over the measurement of time.
This module is redundant if you're from Gallifrey, and not recommended
for use at high speeds near very massive objects.
%prep
%setup -q -n Time-Warp-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags}
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc README
%{perl_vendorarch}/*
%exclude %dir %{perl_vendorarch}/auto
%{_mandir}/man3/*.3*
%changelog
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.5-1
- submission
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.5-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-Time-Warp/F-10/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 3 Jun 2009 17:05:45 - 1.1
+++ .cvsignore 4 Jun 2009 04:03:27 - 1.2
@@ -0,0 +1 @@
+Time-Warp-0.5.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Time-Warp/F-10/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 3 Jun 2009 17:05:45 - 1.1
+++ sources 4 Jun 2009 04:03:27 - 1.2
@@ -0,0 +1 @@
+33652a9dfdc11366ddba95efe6432a51 Time-Warp-0.5.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Time-Warp/F-11 import.log, NONE, 1.1 perl-Time-Warp.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-Time-Warp/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv22600/F-11
Modified Files:
.cvsignore sources
Added Files:
import.log perl-Time-Warp.spec
Log Message:
Initial import.
--- NEW FILE import.log ---
perl-Time-Warp-0_5-1_fc10:F-11:perl-Time-Warp-0.5-1.fc10.src.rpm:1244088242
--- NEW FILE perl-Time-Warp.spec ---
Name: perl-Time-Warp
Version:0.5
Release:1%{?dist}
# Warp.pm - GPL+ or Artistic
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Change the start and speed of Event time
Source:
http://search.cpan.org/CPAN/authors/id/J/JP/JPRIT/Time-Warp-%{version}.tar.gz
Url:http://search.cpan.org/dist/Time-Warp
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildRequires: perl(ExtUtils::MakeMaker)
# don't provide private Perl libs
%global _use_internal_dependency_generator 0
%global __deploop() while read FILE; do /usr/lib/rpm/rpmdeps -%{1} ${FILE};
done | /bin/sort -u
%global __find_provides /bin/sh -c %{__grep} -v '%_docdir' | %{__grep} -v
'%{perl_vendorarch}/.*\\.so$' | %{__deploop P}
%global __find_requires /bin/sh -c %{__grep} -v '%_docdir' | %{__deploop R}
%description
Our external experience unfolds in 3 1/2 dimensions (time has a
dimensionality of 1/2). The Time::Warp module offers developers control
over the measurement of time.
This module is redundant if you're from Gallifrey, and not recommended
for use at high speeds near very massive objects.
%prep
%setup -q -n Time-Warp-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags}
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc README
%{perl_vendorarch}/*
%exclude %dir %{perl_vendorarch}/auto
%{_mandir}/man3/*.3*
%changelog
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.5-1
- submission
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.5-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-Time-Warp/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 3 Jun 2009 17:05:45 - 1.1
+++ .cvsignore 4 Jun 2009 04:04:07 - 1.2
@@ -0,0 +1 @@
+Time-Warp-0.5.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Time-Warp/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 3 Jun 2009 17:05:45 - 1.1
+++ sources 4 Jun 2009 04:04:08 - 1.2
@@ -0,0 +1 @@
+33652a9dfdc11366ddba95efe6432a51 Time-Warp-0.5.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-Time-Warp/devel perl-Time-Warp.spec, NONE, 1.1 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-Time-Warp/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv25031
Modified Files:
sources
Added Files:
perl-Time-Warp.spec
Log Message:
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.5-1
- submission
--- NEW FILE perl-Time-Warp.spec ---
Name: perl-Time-Warp
Version:0.5
Release:1%{?dist}
# Warp.pm - GPL+ or Artistic
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Change the start and speed of Event time
Source:
http://search.cpan.org/CPAN/authors/id/J/JP/JPRIT/Time-Warp-%{version}.tar.gz
Url:http://search.cpan.org/dist/Time-Warp
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildRequires: perl(ExtUtils::MakeMaker)
# don't provide private Perl libs
%global _use_internal_dependency_generator 0
%global __deploop() while read FILE; do /usr/lib/rpm/rpmdeps -%{1} ${FILE};
done | /bin/sort -u
%global __find_provides /bin/sh -c %{__grep} -v '%_docdir' | %{__grep} -v
'%{perl_vendorarch}/.*\\.so$' | %{__deploop P}
%global __find_requires /bin/sh -c %{__grep} -v '%_docdir' | %{__deploop R}
%description
Our external experience unfolds in 3 1/2 dimensions (time has a
dimensionality of 1/2). The Time::Warp module offers developers control
over the measurement of time.
This module is redundant if you're from Gallifrey, and not recommended
for use at high speeds near very massive objects.
%prep
%setup -q -n Time-Warp-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags}
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc README
%{perl_vendorarch}/*
%exclude %dir %{perl_vendorarch}/auto
%{_mandir}/man3/*.3*
%changelog
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.5-1
- submission
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.5-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Time-Warp/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 3 Jun 2009 17:05:45 - 1.1
+++ sources 4 Jun 2009 04:13:47 - 1.2
@@ -0,0 +1 @@
+33652a9dfdc11366ddba95efe6432a51 Time-Warp-0.5.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-DBICx-TestDatabase/devel perl-DBICx-TestDatabase.spec, NONE, 1.1 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-DBICx-TestDatabase/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv25695
Modified Files:
sources
Added Files:
perl-DBICx-TestDatabase.spec
Log Message:
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.02-1
- update for submission
--- NEW FILE perl-DBICx-TestDatabase.spec ---
Name: perl-DBICx-TestDatabase
Version:0.02
Release:1%{?dist}
# lib/DBICx/TestDatabase.pm - GPL+ or Artistic
# lib/DBICx/TestDatabase/Subclass.pm - GPL+ or Artistic
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Create a temporary database from a DBIx::Class::Schema
Source:
http://search.cpan.org/CPAN/authors/id/J/JR/JROCKWAY/DBICx-TestDatabase-%{version}.tar.gz
Url:http://search.cpan.org/dist/DBICx-TestDatabase
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildArch: noarch
BuildRequires: perl(DBD::SQLite)
BuildRequires: perl(DBIx::Class)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Temp)
BuildRequires: perl(ok)
BuildRequires: perl(SQL::Translator)
BuildRequires: perl(Test::More)
BuildRequires: perl(DBD::SQLite)
# not automagically picked up
Requires: perl(DBIx::Class)
Requires: perl(ExtUtils::MakeMaker)
Requires: perl(SQL::Translator)
%description
This module creates a temporary SQLite database, deploys your DBIC
schema, and then connects to it. This lets you easily test your DBIC
schema. Since you have a fresh database for every test, you don't have
to worry about cleaning up after your tests, ordering of tests affecting
failure, etc.
%prep
%setup -q -n DBICx-TestDatabase-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
%check
make test
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc README Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.02-1
- update for submission
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.02-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
Index: sources
===
RCS file: /cvs/extras/rpms/perl-DBICx-TestDatabase/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 3 Jun 2009 17:07:57 - 1.1
+++ sources 4 Jun 2009 04:17:10 - 1.2
@@ -0,0 +1 @@
+e236d1a2bb4b07c70b35af0ae6e49415 DBICx-TestDatabase-0.02.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-MooseX-Storage/devel .cvsignore, 1.2, 1.3 perl-MooseX-Storage.spec, 1.1, 1.2 sources, 1.2, 1.3
Author: cweyl
Update of /cvs/extras/rpms/perl-MooseX-Storage/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv29475
Modified Files:
.cvsignore perl-MooseX-Storage.spec sources
Log Message:
* Thu Jun 04 2009 Chris Weyl cw...@alumni.drew.edu 0.18-1
- auto-update to 0.18 (by cpan-spec-update 0.01)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-MooseX-Storage/devel/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- .cvsignore 19 Apr 2009 00:18:20 - 1.2
+++ .cvsignore 4 Jun 2009 04:33:56 - 1.3
@@ -1 +1 @@
-MooseX-Storage-0.17.tar.gz
+MooseX-Storage-0.18.tar.gz
Index: perl-MooseX-Storage.spec
===
RCS file: /cvs/extras/rpms/perl-MooseX-Storage/devel/perl-MooseX-Storage.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-MooseX-Storage.spec19 Apr 2009 00:18:20 - 1.1
+++ perl-MooseX-Storage.spec4 Jun 2009 04:33:56 - 1.2
@@ -1,13 +1,13 @@
-Name: perl-MooseX-Storage
-Version:0.17
-Release:2%{?dist}
+Name: perl-MooseX-Storage
+Version:0.18
+Release:1%{?dist}
# lib/MooseX/Storage.pm - GPL+ or Artistic
-License:GPL+ or Artistic
+License:GPL+ or Artistic
Group: Development/Libraries
-Summary:A serialization framework for Moose classes
-Source:
http://search.cpan.org/CPAN/authors/id/B/BO/BOBTFISH/MooseX-Storage-%{version}.tar.gz
+Summary:A serialization framework for Moose classes
+Source:
http://search.cpan.org/CPAN/authors/id/B/BO/BOBTFISH/MooseX-Storage-%{version}.tar.gz
Url:http://search.cpan.org/dist/MooseX-Storage
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
@@ -49,7 +49,7 @@ number of different formats and styles.
of this module, so use with caution. It's outward facing serialization
API should be considered stable, but I still reserve the right to make
tweaks if I need too. Anything beyond the basic pack/unpack, freeze/thaw
-and load/store should not be relied on. There are 3 levels to the
+and load/store should not be relied on. There are 3 levels to the
serialization, each of which builds upon the other and each of which
can be customized to the specific needs of your class.
@@ -74,15 +74,18 @@ find %{buildroot} -depth -type d -exec r
make test
%clean
-rm -rf %{buildroot}
+rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
-%doc Changes README
+%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
+* Thu Jun 04 2009 Chris Weyl cw...@alumni.drew.edu 0.18-1
+- auto-update to 0.18 (by cpan-spec-update 0.01)
+
* Sat Apr 18 2009 Chris Weyl cw...@alumni.drew.edu 0.17-2
- update grammatically poor summary
@@ -95,4 +98,3 @@ rm -rf %{buildroot}
* Mon Mar 09 2009 Chris Weyl cw...@alumni.drew.edu 0.15-0
- initial RPM packaging
- generated with cpan2dist (CPANPLUS::Dist::RPM version 0.0.8)
-
Index: sources
===
RCS file: /cvs/extras/rpms/perl-MooseX-Storage/devel/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 19 Apr 2009 00:18:20 - 1.2
+++ sources 4 Jun 2009 04:33:56 - 1.3
@@ -1 +1 @@
-626819fe42830d6ff635a84bcd17706a MooseX-Storage-0.17.tar.gz
+680fca0f63f7910fed8c52805bc579e2 MooseX-Storage-0.18.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-DBICx-TestDatabase/devel perl-DBICx-TestDatabase.spec, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-DBICx-TestDatabase/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv9545
Modified Files:
perl-DBICx-TestDatabase.spec
Log Message:
* Wed Jun 03 2009 Chris Weyl cw...@alumni.drew.edu 0.02-2
- add br on DBD::SQLite
Index: perl-DBICx-TestDatabase.spec
===
RCS file:
/cvs/extras/rpms/perl-DBICx-TestDatabase/devel/perl-DBICx-TestDatabase.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-DBICx-TestDatabase.spec4 Jun 2009 04:17:10 - 1.1
+++ perl-DBICx-TestDatabase.spec4 Jun 2009 05:37:24 - 1.2
@@ -1,6 +1,6 @@
Name: perl-DBICx-TestDatabase
Version:0.02
-Release:1%{?dist}
+Release:2%{?dist}
# lib/DBICx/TestDatabase.pm - GPL+ or Artistic
# lib/DBICx/TestDatabase/Subclass.pm - GPL+ or Artistic
License:GPL+ or Artistic
@@ -25,6 +25,7 @@ BuildRequires: perl(DBD::SQLite)
Requires: perl(DBIx::Class)
Requires: perl(ExtUtils::MakeMaker)
Requires: perl(SQL::Translator)
+Requires: perl(DBD::SQLite)
%description
This module creates a temporary SQLite database, deploys your DBIC
@@ -63,6 +64,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Wed Jun 03 2009 Chris Weyl cw...@alumni.drew.edu 0.02-2
+- add br on DBD::SQLite
+
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.02-1
- update for submission
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-DBICx-TestDatabase/F-11 perl-DBICx-TestDatabase.spec, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-DBICx-TestDatabase/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv11630
Modified Files:
perl-DBICx-TestDatabase.spec
Log Message:
* Wed Jun 03 2009 Chris Weyl cw...@alumni.drew.edu 0.02-2
- add br on DBD::SQLite
Index: perl-DBICx-TestDatabase.spec
===
RCS file:
/cvs/extras/rpms/perl-DBICx-TestDatabase/F-11/perl-DBICx-TestDatabase.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-DBICx-TestDatabase.spec4 Jun 2009 04:02:28 - 1.1
+++ perl-DBICx-TestDatabase.spec4 Jun 2009 05:48:03 - 1.2
@@ -1,6 +1,6 @@
Name: perl-DBICx-TestDatabase
Version:0.02
-Release:1%{?dist}
+Release:2%{?dist}
# lib/DBICx/TestDatabase.pm - GPL+ or Artistic
# lib/DBICx/TestDatabase/Subclass.pm - GPL+ or Artistic
License:GPL+ or Artistic
@@ -25,6 +25,7 @@ BuildRequires: perl(DBD::SQLite)
Requires: perl(DBIx::Class)
Requires: perl(ExtUtils::MakeMaker)
Requires: perl(SQL::Translator)
+Requires: perl(DBD::SQLite)
%description
This module creates a temporary SQLite database, deploys your DBIC
@@ -63,6 +64,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Wed Jun 03 2009 Chris Weyl cw...@alumni.drew.edu 0.02-2
+- add br on DBD::SQLite
+
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.02-1
- update for submission
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/perl-DBICx-TestDatabase/F-10 perl-DBICx-TestDatabase.spec, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/perl-DBICx-TestDatabase/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv11710
Modified Files:
perl-DBICx-TestDatabase.spec
Log Message:
* Wed Jun 03 2009 Chris Weyl cw...@alumni.drew.edu 0.02-2
- add br on DBD::SQLite
Index: perl-DBICx-TestDatabase.spec
===
RCS file:
/cvs/extras/rpms/perl-DBICx-TestDatabase/F-10/perl-DBICx-TestDatabase.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-DBICx-TestDatabase.spec4 Jun 2009 04:01:29 - 1.1
+++ perl-DBICx-TestDatabase.spec4 Jun 2009 05:48:18 - 1.2
@@ -1,6 +1,6 @@
Name: perl-DBICx-TestDatabase
Version:0.02
-Release:1%{?dist}
+Release:2%{?dist}
# lib/DBICx/TestDatabase.pm - GPL+ or Artistic
# lib/DBICx/TestDatabase/Subclass.pm - GPL+ or Artistic
License:GPL+ or Artistic
@@ -25,6 +25,7 @@ BuildRequires: perl(DBD::SQLite)
Requires: perl(DBIx::Class)
Requires: perl(ExtUtils::MakeMaker)
Requires: perl(SQL::Translator)
+Requires: perl(DBD::SQLite)
%description
This module creates a temporary SQLite database, deploys your DBIC
@@ -63,6 +64,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Wed Jun 03 2009 Chris Weyl cw...@alumni.drew.edu 0.02-2
+- add br on DBD::SQLite
+
* Tue Jun 02 2009 Chris Weyl cw...@alumni.drew.edu 0.02-1
- update for submission
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
Re: [Fedora-r-devel-list] R2spec and version number
On Wed, 2009-06-03 at 17:07 -0400, Tom spot Callaway wrote: On 06/03/2009 12:50 PM, Martyn Plummer wrote: For R, there is no difference between - and . in package version numbers. Here is what the R Extension manual says: The version is a sequence of at least two (and usually three) non-negative integers separated by single ‘.’ or ‘-’ characters. The canonical form is as shown in the example [0.5-1 - Martyn], and a version such as ‘0.01’ or ‘0.01.0’ will be handled as if it were ‘0.1-0’. So you should just replace dashes with dots. Based on that, I'd say we should be embedding the whole version (with dot, not dash). Pretty much every R package is going to need to be fixed for this, include the core R. I'd also propose that we put a small note on the packaging guidelines :) Thanks all, Pierre ___ Fedora-r-devel-list mailing list Fedora-r-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-r-devel-list
