Re: Auto-expiring bugs are getting absurd
On Wed, Feb 05, 2014 at 01:51:41PM -0800, David Timothy Strauss wrote: Like this: https://bugzilla.redhat.com/show_bug.cgi?id=959071 I specifically followed up to say the issue continues in Fedora 19, and nothing changed. The bug tracker should not expire bugs if there's been a comment after the EOL warning. See https://fedorahosted.org/fesco/ticket/1198... but that didn't result in me or anyone else really doing anything this time around. But I think it's worthwhile to continue the conversation. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
different version of packages in testing and rawhide
Hi guys i have running rawhide in my laptop and is update , all work fine for me but i don't understand why update-testing have different version of packages in comparison with rawhide example the following builds have been pushed to Fedora 20 updates-testing NetworkManager-0.9.9.0-29.git20140131.fc20 abrt-java-connector-1.0.8-3.fc20 now the packages version of rawhide are NetworkManager-0.9.9.0-27.git20140131.fc21.x86_64 abrt-java-connector-1.0.8-1.fc21.x86_64 i'm confused -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, Feb 05, 2014 at 02:05:06PM -0800, David Timothy Strauss wrote: You just need to change the Version tag. That is not something I appear to have access to do. And, if I don't, very few people do. The person who *reported* the bug can (although there possibly may be some cases where that doesn't work, I can't find any) -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: different version of packages in testing and rawhide
On Thu, 2014-02-06 at 05:03 -0300, Carlos Morel-Riquelme wrote: Hi guys i have running rawhide in my laptop and is update , all work fine for me but i don't understand why update-testing have different version of packages in comparison with rawhide example the following builds have been pushed to Fedora 20 updates-testing NetworkManager-0.9.9.0-29.git20140131.fc20 abrt-java-connector-1.0.8-3.fc20 now the packages version of rawhide are NetworkManager-0.9.9.0-27.git20140131.fc21.x86_64 abrt-java-connector-1.0.8-1.fc21.x86_64 i'm confused These are errors on the parts of the packagers, basically. They are supposed to ensure that builds for newer releases are always versioned higher than builds for older releases (even if it's not really 'necessary' in the flow of how they've done the builds). So, if there isn't a bug filed on each one already, go ahead and file one :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: different version of packages in testing and rawhide
thank so much adam :) On Thu, Feb 6, 2014 at 5:17 AM, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-02-06 at 05:03 -0300, Carlos Morel-Riquelme wrote: Hi guys i have running rawhide in my laptop and is update , all work fine for me but i don't understand why update-testing have different version of packages in comparison with rawhide example the following builds have been pushed to Fedora 20 updates-testing NetworkManager-0.9.9.0-29.git20140131.fc20 abrt-java-connector-1.0.8-3.fc20 now the packages version of rawhide are NetworkManager-0.9.9.0-27.git20140131.fc21.x86_64 abrt-java-connector-1.0.8-1.fc21.x86_64 i'm confused These are errors on the parts of the packagers, basically. They are supposed to ensure that builds for newer releases are always versioned higher than builds for older releases (even if it's not really 'necessary' in the flow of how they've done the builds). So, if there isn't a bug filed on each one already, go ahead and file one :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: change Selinux context in %post?
On 02/05/2014 08:24 PM, Richard Shaw wrote:
Are there official guidelines on how to handle selinux contexts in packaging? I
can still only find the draft which
seems way more complicated than necessary for my needs.
I'm working on a package that uses mongodb internally (runs it's own instance).
Selinux is complaining because it has
mongodb creating the database (and logs) outside of the normal locations.
I think I can fix this with a chcon -t mongod_var_lib_t
%{_sharedstatedir}/db/location and chcon -t mongod_log_t
/log/path or something like that.
Is it a good idea to do this in %post?
I do not think there is general guideline.
As other suggested - it is bad idea to call chcon explicitly. You should rather write your own selinux policy (it is not
that hard, really) and call restorecon or fixfiles.
You should not call it in %post because selinux policy can be loaded after your %post. The story about this is little
bit longer and boring. The conclusion is - do that in %posttrans.
You can get some inspiration e.g. in:
https://git.fedorahosted.org/cgit/copr.git/tree/copr.spec
https://git.fedorahosted.org/cgit/copr.git/tree/selinux
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
proposal for changes to auto-expiring bugs
On Wed, Feb 05, 2014 at 02:50:59PM -0800, Adam Williamson wrote: The problem is that no-one seems to come up with an alternative that's any better. Leaving bugs on EOL versions open to rot away and be ignored is no use. We *could* give everyone privs to re-open closed bugs, I guess, and I personally don't think that would end terribly, but it's kind of a radical plan. I would like to see one of the following, in order of preference: 1. Step one: when a release hits EOL, move the bugs to NEEDINFO with a notice similar to the current one. (Essentially moving the current warning back a little bit.) Step one point five: I believe pretty much anyone can clear the NEEDINFO flag. Step two: when the *next* release hits EOL (and the release under consideration has been EOL for approximately 6 months), move any bugs still in NEEDINFO to a new closed resolution like CLOSED:EOL, with a message similar to the current EOL note. EOL wouldn't be visibile as an available status for bugzilla users to select when closing a bug in the interface, so it does not add to UI clutter, but also makes it easy for us to do reports distinguishing between intentional and eol closure. This gives a much longer timeframe where we're waiting for input, so by the time we actually close, the release has been EOL for a decent while (rather than now, at the I just got around to updating! point). This does risk some false positives (negatives? whatever) where NEEDINFO is cleared with works for me but the bug not closed, but that seems like a less serious problem. 2. As #1, but with no new CLOSED:EOL resolution. Instead, use WONTFIX or and add a ClosedEOL keyword automatically. This is uglier than the above but requires no bugzilla change. 3. As #1, but just leave bugs in NEEDINFO state forever. This would possibly require maintainers to update their searches / filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs from older releases. Any of these seem pretty easy and I think would improve the situation for users and bug reporters without badly increasing maintainer burden or being dishonest about our ability to fix all the things. Additionally, but requiring some development, we could add some heuristics like: don't autoclose bugs with many incoming duplicate pointers, or possibly (as David suggests) bugs with comments, or bugs which have been reopened, or (here I get handwavy). -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, 05 Feb 2014 14:50:59 -0800, Adam Williamson wrote: On Wed, 2014-02-05 at 22:48 +, Colin Macdonald wrote: On 05/02/14 22:42, David Timothy Strauss wrote: This is also not the first time this has happened to me. I'll chime in: when I first switched to Fedora (F14/15 era), I found this quite obnoxious, enough that I remember it. So there is also an issue of being a welcoming community to newcomers. The problem is that no-one seems to come up with an alternative that's any better. Leaving bugs on EOL versions open to rot away and be ignored is no use. We *could* give everyone privs to re-open closed bugs, I guess, and I personally don't think that would end terribly, but it's kind of a radical plan. The idea of not closing bugs that have comments after the EOL notification doesn't necessarily make things better, I don't think; we'd just have errors in the other direction. Say someone dropped a note 'oh yeah, this is working now!' - it would be silly not to close the bug, right? Has that been tried before? It sounds like a better approach. Where is the human to notice comments after EOL and act accordingly? How many tickets would be affected by a comment after EOL? What is the underlying problem here anyway? Too many unhandled tickets - EOL auto-close threatening - too many closed tickets to handle - how to escape from that loop? In several large upstream bug trackers it is no different. Are developers always informed about what doesn't work even when not responding to tickets? Why should users still take the time to submit problem reports if they don't get a response? algorithms are never perfect, but we do have to use them, as a perennially under-resourced project. I've posted about it in 2008 already, and I still think the auto-closing leads to hiding crap under the carpet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
- Original Message - Like this: https://bugzilla.redhat.com/show_bug.cgi?id=959071 I specifically followed up to say the issue continues in Fedora 19, and nothing changed. The bug tracker should not expire bugs if there's been a comment after the EOL warning. The bug bot is really very dumb [1] and rewrite is planned. So far it takes a list of bugs based on search query in CSV and runs bug after bug calls. So there's no way to check for messages. Also when I took look on some bugs it closed, there was one with two comments - it's fixed, it's not and to be honest, I was thinking about what to do with these. So I'm sorry for the bug closed, the new EOL closure message now contains wording that should avoid that not everyone is allowed to reopen bugs, we should do the same for EOL warning version change. Jaroslav [1] https://git.fedorahosted.org/cgit/fedora-project-schedule.git/tree/scripts/closebugs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
- Original Message - On Wed, Feb 05, 2014 at 02:50:59PM -0800, Adam Williamson wrote: The problem is that no-one seems to come up with an alternative that's any better. Leaving bugs on EOL versions open to rot away and be ignored is no use. We *could* give everyone privs to re-open closed bugs, I guess, and I personally don't think that would end terribly, but it's kind of a radical plan. I would like to see one of the following, in order of preference: 1. Step one: when a release hits EOL, move the bugs to NEEDINFO with a notice similar to the current one. (Essentially moving the current warning back a little bit.) Step one point five: I believe pretty much anyone can clear the NEEDINFO flag. Step two: when the *next* release hits EOL (and the release under consideration has been EOL for approximately 6 months), move any bugs still in NEEDINFO to a new closed resolution like CLOSED:EOL, with a message similar to the current EOL note. EOL wouldn't be visibile as an available status for bugzilla users to select when closing a bug in the interface, so it does not add to UI clutter, but also makes it easy for us to do reports distinguishing between intentional and eol closure. This gives a much longer timeframe where we're waiting for input, so by the time we actually close, the release has been EOL for a decent while (rather than now, at the I just got around to updating! point). This does risk some false positives (negatives? whatever) where NEEDINFO is cleared with works for me but the bug not closed, but that seems like a less serious problem. 2. As #1, but with no new CLOSED:EOL resolution. Instead, use WONTFIX or and add a ClosedEOL keyword automatically. This is uglier than the above but requires no bugzilla change. I'm not sure adding a new EOL status would be ok for Bugzilla guys, as far as I know, there were some efforts to cut down BZ statuses (ON_DEV for example), even it would be hidden. So keyword looks like much more easier solution. Jaroslav 3. As #1, but just leave bugs in NEEDINFO state forever. This would possibly require maintainers to update their searches / filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs from older releases. Any of these seem pretty easy and I think would improve the situation for users and bug reporters without badly increasing maintainer burden or being dishonest about our ability to fix all the things. Additionally, but requiring some development, we could add some heuristics like: don't autoclose bugs with many incoming duplicate pointers, or possibly (as David suggests) bugs with comments, or bugs which have been reopened, or (here I get handwavy). -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Thu, Feb 06, 2014 at 01:21:53PM +0100, Michael Schwendt wrote: Where is the human to notice comments after EOL and act accordingly? Theeeoretically, the package maintainer. In the prototypical version of this back in the ancient days, I actually put myself on the CC list of all of the closed bugs. But there are several times more bugs than there used to be, and I think that would consume a whole full-time person at least for a while. How many tickets would be affected by a comment after EOL? It's kind of hard to construct the exact search because the Fedora EOL script takes some time to run, and I don't think bugzilla allows anything like comment from not $GIVENUSER after comment from $GIVENUSER. If anyone does know how to do that, help wanted. :) I've posted about it in 2008 already, and I still think the auto-closing leads to hiding crap under the carpet. I think it's acknowledgement that we don't have resources to fix all of the crap. But I'd like if we could better identify the important cases where we actually *should* make sure issues are addressed, while finding the right balance between maintainer and user/reported burdens. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Thu, Feb 06, 2014 at 07:30:44AM -0500, Jaroslav Reznik wrote: 2. As #1, but with no new CLOSED:EOL resolution. Instead, use WONTFIX or and add a ClosedEOL keyword automatically. This is uglier than the above but requires no bugzilla change. I'm not sure adding a new EOL status would be ok for Bugzilla guys, as far as I know, there were some efforts to cut down BZ statuses (ON_DEV for example), even it would be hidden. So keyword looks like much more easier solution. I think it depends on the reasons for cutting down on statuses (or in this case, resolutions). If it's for performance reasons or some other practical concern, okay. But if it's because the plethora of options is confusing to users, I think hiding it from the UI should be okay. We could ask. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: change Selinux context in %post?
On Thu, Feb 6, 2014 at 2:49 AM, Miroslav Suchý msu...@redhat.com wrote:
On 02/05/2014 08:24 PM, Richard Shaw wrote:
Are there official guidelines on how to handle selinux contexts in
packaging? I can still only find the draft which
seems way more complicated than necessary for my needs.
I'm working on a package that uses mongodb internally (runs it's own
instance). Selinux is complaining because it has
mongodb creating the database (and logs) outside of the normal locations.
I think I can fix this with a chcon -t mongod_var_lib_t
%{_sharedstatedir}/db/location and chcon -t mongod_log_t
/log/path or something like that.
Is it a good idea to do this in %post?
I do not think there is general guideline.
As other suggested - it is bad idea to call chcon explicitly. You should
rather write your own selinux policy (it is not that hard, really) and call
restorecon or fixfiles.
Got it.
You should not call it in %post because selinux policy can be loaded after
your %post. The story about this is little bit longer and boring. The
conclusion is - do that in %posttrans.
Ok, good to know.
You can get some inspiration e.g. in:
https://git.fedorahosted.org/cgit/copr.git/tree/copr.spec
https://git.fedorahosted.org/cgit/copr.git/tree/selinux
Thanks!
I've gotten this far on my own. I used semanage and some google-fu to come
up with this that seems to fix the problem. I'm not sure if there's a
better way (i.e. a more least privilege route) but I have the following
in file_contexts.local:
/var/lib/unifi/logs(/.*)?system_u:object_r:mongod_var_lib_t:s0
/var/lib/unifi/data(/.*)?system_u:object_r:mongod_var_lib_t:s0
And the port problem in ports.local:
portcon tcp 27117 system_u:object_r:mongod_port_t:s0
Now, how to turn that into a policy file...
Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Upgrade ICU to 52.1 with soname bump
Hi, On Saturday, 2014-01-25 09:47:28 -0700, Kevin Fenzi wrote: If time permits I'd like to do an upgrade of ICU to 52.1 next week, which leads to the usual soname bump. As quite a lot of packages are affected by this, is anyone objecting and can point out a better time for the upgrade? I was carried away with LibreOffice release and then FOSDEM, so this got postponed. Hum... perhaps I am missing something, but I don't see anything that is directly affected. There's no packages that buildrequire or require icu? Or am I looking at the wrong package? I guess you mean libicu? Yes, sure, with ICU I referred the entire suite, the important part here being libicu and all its libs. Are there any changes in the 50-52.1 jump that would need patches/changes? Or should it just mostly be a rebuild? Should be a rebuild only. Do you have any provenpackager(s) who can help you rebuild things? Maybe, but he's already overloaded ;) If not, I'll probably announce it on Monday and do the upgrade on Wednesday. Seems fine. So maybe next week.. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key ID: 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Support the FSFE, care about Free Software! https://fsfe.org/support/?erack pgp7vWli7jzas.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
dnf-0.4.13
Hello, dnf-0.4.13 is out [1], [2]. F20 version will follow shortly. We ship Delta RPM support, bash completion and keepcache again in this version. Remember to come meet the team at DevConf.cz this weekend. Ales [1] http://dnf.baseurl.org/2014/02/06/dnf-0-4-13-released/ [2] http://akozumpl.github.io/dnf/release_notes.html#id24 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Tue, Feb 4, 2014 at 11:11 AM, H. Guémar hgue...@fedoraproject.orgwrote: I'm not fond of keeping spins around when we're focusing on products. That gives the message that they are second-class citizens in Fedora. In my view, this not supposed to be a discussion about numbering classes / keeping score. Rather, I view spins and products as _substantially_ different: spins are more or less focused on providing upstream software (perhaps with fixed bugs, or with good curation); products are much more focused on doing extra new work to integrate, work that doesn't have any non-Fedora upstream. So, saying that every spin is/should be a product-in-making doesn't match with the way I think about this. Note that this distinction does not automatically imply anything as to visibility, promotion, or being release blocking: We could easily promote a specific spin _more_ than a specific product (say, promote Fedora Audio Product, Fedora Rails 4 spin, Fedora Cloud Product, Fedora KDE spin, Fedora Desktop, Fedora Server - the order is obviously nonsense but you get the idea). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: change Selinux context in %post?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/06/2014 02:39 PM, Richard Shaw wrote: On Thu, Feb 6, 2014 at 2:49 AM, Miroslav Suchý msu...@redhat.com wrote: On 02/05/2014 08:24 PM, Richard Shaw wrote: Are there official guidelines on how to handle selinux contexts in packaging? I can still only find the draft which seems way more complicated than necessary for my needs. I'm working on a package that uses mongodb internally (runs it's own instance). Selinux is complaining because it has mongodb creating the database (and logs) outside of the normal locations You need to tell SELinux about the labels. semanage fcontext -e /var/lib/mysql PATHTO/mysql restorecon -R -v PATHTO/mysql Is probably what you want. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLzyGsACgkQrlYvE4MpobNYWQCeJZf17KvHSr6JfoKRSTx7oopb RgoAn1OmUd7nLkr6alO1g5Ct58KQrwHz =yJZG -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: change Selinux context in %post?
On Thu, Feb 6, 2014 at 11:37 AM, Daniel J Walsh dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/06/2014 02:39 PM, Richard Shaw wrote: On Thu, Feb 6, 2014 at 2:49 AM, Miroslav Suchý msu...@redhat.com wrote: On 02/05/2014 08:24 PM, Richard Shaw wrote: Are there official guidelines on how to handle selinux contexts in packaging? I can still only find the draft which seems way more complicated than necessary for my needs. I'm working on a package that uses mongodb internally (runs it's own instance). Selinux is complaining because it has mongodb creating the database (and logs) outside of the normal locations You need to tell SELinux about the labels. semanage fcontext -e /var/lib/mysql PATHTO/mysql restorecon -R -v PATHTO/mysql Is probably what you want. Ok, I ended up getting to the same place using -a mongod_var_lib_t... Now how to turn that into a policy I can package? I ended up with this as the requirements to create a functional package: /var/lib/unifi/logs(/.*)?system_u:object_r:mongod_var_lib_t:s0 /var/lib/unifi/data(/.*)?system_u:object_r:mongod_var_lib_t:s0 portcon tcp 27117 system_u:object_r:mongod_port_t:s0 Thanks, Ricahrd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Adjust wiki for ARM BeagleBone Black
Hey guys, I adjusted this documentation in wiki: https://fedoraproject.org/wiki/Architectures/ARM/F20/Installation#For_the_BeagleBone_Black Added this important step to create image of Fedora 20 for BeagleBone Black board. Best Regards firemanxbr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Thu, 2014-02-06 at 04:00 -0500, Matthew Miller wrote: Additionally, but requiring some development, we could add some heuristics like: don't autoclose bugs with many incoming duplicate pointers, or possibly (as David suggests) bugs with comments, or bugs which have been reopened, or (here I get handwavy). Your whole proposal more or less *is* the heuristic 'don't autoclose bugs with comments', because of how needinfo works in RH bugzilla. It's not a status (as you imply by writing NEEDINFO) but a flag. If you set the needinfo flag not against a specific person but against 'anyone', then by default, the next person who posts a comment of any kind will clear the flag - they have to uncheck a little box if they want to *not* clear the flag. I still don't actually think it's a bad proposal, just wanted to be sure the implications of using the needinfo flag were clear :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New UEFI guide on the wiki
On Feb 6, 2014, at 12:39 AM, Dariusz J. Garbowski thufo...@yahoo.co.uk wrote: On 05/02/14 05:46 PM, Przemek Klosowski wrote: On 02/04/2014 06:18 PM, Chris Murphy wrote: And then we can definitely justify making them bigger. 550MB, or even 1GB. It's neutral to plus for performance for either HDDs or SSDs (faux short stroked in the former, and overprovisioned for the latter). Does anyone know why the convention is to create the ESP as the first partition? At times in the past there was a race between BIOS support for large disks and hard disk size, and BIOS boot code could not reach the far sectors of the disk. This even leaked into Linux sometimes, Right but BIOS only ever expected to have to read LBA 0, so it stands to reason someone's not testing whether it can jump beyond LBA 28-bit addressing if it's an ancient BIOS implementation; or beyond the MBR 32-bit address limit. But since the UEFI spec is predicated on LBA 48-bit addressing, I think my diplomatic language would be WTF vendor if UEFI firmware face planted on an ESP at the end of a 5TB drive. I should test it. Oh hey, it works with whatever UEFI VirtualBox uses. This is the layout. Firmware finds shim.efi way out well beyond 3TB, and GRUB is finding its grub.cfg way out there as well and boots the system fine. Disk /dev/sda: 1024000 sectors, 4.8 TiB […] Number Start (sector)End (sector) Size Code Name 1 10238871552 1023966 551.0 MiB EF00 EFI System 22048 1026047 500.0 MiB 0700 3 1026048 10238871551 4.8 TiB 0700 It still happens: I just had a case of this on Dell R620 (Ivy Bridge Xeon) with over 3TB disk space and RHEL 6.5... Grub couldn't reach it's files to boot OS. RHEL 6.5 uses ancient GRUB 0.97 so the problem could be with the boot loader, or the firmware. However, without having this computer physical present, how can you tell it uses UEFI and not BIOS? I certainly can't. Dell's spec sheet for it says in part From bezel to BIOS to packaging which seems like just a tagline, not a spec per se. But then the support page explicitly refers to it as BIOS: Dell Server BIOS PowerEdge R620 Version 2.1.3 http://www.dell.com/support/drivers/us/en/04/DriverDetails/Product/poweredge-r620?driverId=T2RVCosCode=WS8R2fileId=3329675946languageCode=encategoryId=BI In general, finding out whether a system's firmware is BIOS or UEFI is not easy. Either they don't say, as if it isn't a selling point, yet telling me it uses the, e.g. Intel C600 chipset isn't too obscure. HP pretty much universally refers to the UEFI firmware updates as BIOS updates. Idiotic. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Thu, 6 Feb 2014 04:00:17 -0500 Matthew Miller mat...@fedoraproject.org wrote: I would like to see one of the following, in order of preference: 1. Step one: when a release hits EOL, move the bugs to NEEDINFO with a notice similar to the current one. (Essentially moving the current warning back a little bit.) Step one point five: I believe pretty much anyone can clear the NEEDINFO flag. Step two: when the *next* release hits EOL (and the release under consideration has been EOL for approximately 6 months), move any bugs still in NEEDINFO to a new closed resolution like CLOSED:EOL, with a message similar to the current EOL note. So, all those bugs stay open on the EOL version until EOL+1? That seems poor to me. What do we do if someone clears needinfo and says: Yes, this still affects me, I am running EOL release. Please fix it. We cannot, the EOL release is closed, no more updates or support. How does leaving it open there help? EOL wouldn't be visibile as an available status for bugzilla users to select when closing a bug in the interface, so it does not add to UI clutter, but also makes it easy for us to do reports distinguishing between intentional and eol closure. Is this possible? This gives a much longer timeframe where we're waiting for input, so by the time we actually close, the release has been EOL for a decent while (rather than now, at the I just got around to updating! point). This does risk some false positives (negatives? whatever) where NEEDINFO is cleared with works for me but the bug not closed, but that seems like a less serious problem. Yeah, thats another issue with this... they would stick around in that case until the maintainer or someone came in and cleared them. 2. As #1, but with no new CLOSED:EOL resolution. Instead, use WONTFIX or and add a ClosedEOL keyword automatically. This is uglier than the above but requires no bugzilla change. 3. As #1, but just leave bugs in NEEDINFO state forever. This would possibly require maintainers to update their searches / filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs from older releases. It would also be misleading, IMHO. Hey reporter, I need info to fix this Here you go, here's the info you wanted from my Fedora 7 machine, please provide update kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
a stop job is running for User Manager for 0
I'm using a minimal netinstall version of fedora20 for testing using KVM. We very often cycle these machines (once per test, we run hundreds of tests) Regularly, we get tests failing because the VM does not boot within 60 seconds, and seems to hang at: a stop job is running for User Manager for 0 The machine is still in single user mode, so I cannot get any more information out of it. The message is rather useless, because it does not tell me anything about the problem. Which job is still running? What is it waiting for? What's a User Manager? Who is 0? I'm not even sure at what component we are looking for to report a bug :( Does anyone have more information for me? Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: a stop job is running for User Manager for 0
Am 06.02.2014 20:43, schrieb Paul Wouters: I'm using a minimal netinstall version of fedora20 for testing using KVM. We very often cycle these machines (once per test, we run hundreds of tests) Regularly, we get tests failing because the VM does not boot within 60 seconds, and seems to hang at: a stop job is running for User Manager for 0 here you go https://bugzilla.redhat.com/show_bug.cgi?id=1023820 https://bugzilla.redhat.com/show_bug.cgi?id=1010572 https://bugzilla.redhat.com/show_bug.cgi?id=1057811 https://bugzilla.redhat.com/show_bug.cgi?id=1057618 https://bugzilla.redhat.com/show_bug.cgi?id=1023788#c2 now idea how this systemd made it in F20/RHEL7-Beta1 and why it takes that long to fix so pretty clear bugs nor why prelink is not banned at all in the distribution signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: a stop job is running for User Manager for 0
On Thu, 6 Feb 2014, Reindl Harald wrote: Regularly, we get tests failing because the VM does not boot within 60 seconds, and seems to hang at: a stop job is running for User Manager for 0 here you go https://bugzilla.redhat.com/show_bug.cgi?id=1023820 https://bugzilla.redhat.com/show_bug.cgi?id=1010572 https://bugzilla.redhat.com/show_bug.cgi?id=1057811 https://bugzilla.redhat.com/show_bug.cgi?id=1057618 https://bugzilla.redhat.com/show_bug.cgi?id=1023788#c2 now idea how this systemd made it in F20/RHEL7-Beta1 and why it takes that long to fix so pretty clear bugs nor why prelink is not banned at all in the distribution Note that my test systems have never had prelink installed (and I've done my best to get prelink banished forever over the years) It does seem to point to systemd related issues, although the only user on these systems is root. I'll try and boot with more verbosity and see what I can find out. Thanks, Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: a stop job is running for User Manager for 0
Am 06.02.2014 20:59, schrieb Paul Wouters: On Thu, 6 Feb 2014, Reindl Harald wrote: Regularly, we get tests failing because the VM does not boot within 60 seconds, and seems to hang at: a stop job is running for User Manager for 0 here you go https://bugzilla.redhat.com/show_bug.cgi?id=1023820 https://bugzilla.redhat.com/show_bug.cgi?id=1010572 https://bugzilla.redhat.com/show_bug.cgi?id=1057811 https://bugzilla.redhat.com/show_bug.cgi?id=1057618 https://bugzilla.redhat.com/show_bug.cgi?id=1023788#c2 now idea how this systemd made it in F20/RHEL7-Beta1 and why it takes that long to fix so pretty clear bugs nor why prelink is not banned at all in the distribution Note that my test systems have never had prelink installed (and I've done my best to get prelink banished forever over the years) one of the issues *looks* like prelink related that's why i listed more than one bugreport It does seem to point to systemd related issues, although the only user on these systems is root. which is user 0 that is yours, an not only yours https://bugzilla.redhat.com/show_bug.cgi?id=1023820 however, systemd in F20 and RHEL17 is the most broken release after F15, F16-F19 where improvements, F20 in case of systemd is a massive step backwards in case of stability and bugs sadly, because the rest of F20 is really stable and clean https://bugzilla.redhat.com/show_bug.cgi?id=1023788 is simply *unacceptable* because it was reported *long* before final release, is more than 3 months old and reproduceable with every single reboot/shutdown via ssh signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Gsoc idea feedback and suggestions.
Hey, This is Vidun. I would like to get involved in the Google Summer Of Code program with Fedora. I have an idea in mind which I would like to suggest and probably work on. The idea description as of now is too vague but I hope it drives my point. I'm looking for suggestions and feedback from the community so that I know it this kind of project fits into the scope of Fedora GSOC. The idea initially came up as a difficulty I faced when handling RTC(real time communication) for web project to handle and push notifications, alerts, messages etc. As from a lazy view point this can be easily accomplished with polling but that does not make it real time and also RTC with polling is at the expense of the client runner. There are several third party business's like Pusher that solve this problem by using their server for RTC but developers face the problem of privacy when it comes to sensitive data and they set a cap for the number of messages that can be pushed for a certain paid plan. As it can be clearly seen that using this model is both expensive and error prone as it is not in the control of the developers, so if the main server is down it would result in unexpected behaviors in applications. Some of the problems that developers face when implementing their own RTC message pushing. 1. Most of the hosting companies do not support web-sockets. This is troublesome for established companies to migrate host to support RTC. 2. Privacy issues. 3. Additional work load for developers. Developing web-socket apps is not easy. Successful implementation would solve the following problems. 1. Security for messages. 2. Developers can bootstrap this project and concentrate on the core application. 3. Ability to alter working to suit the particular Application model. I'm waiting for a green flag so that I can work on the detailed draft for the application during my week end. Regards, Vidun k. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Feb 6, 2014 11:06 AM, Kevin Fenzi ke...@scrye.com wrote: On Thu, 6 Feb 2014 04:00:17 -0500 Matthew Miller mat...@fedoraproject.org wrote: I would like to see one of the following, in order of preference: 1. Step one: when a release hits EOL, move the bugs to NEEDINFO with a notice similar to the current one. (Essentially moving the current warning back a little bit.) Step one point five: I believe pretty much anyone can clear the NEEDINFO flag. Step two: when the *next* release hits EOL (and the release under consideration has been EOL for approximately 6 months), move any bugs still in NEEDINFO to a new closed resolution like CLOSED:EOL, with a message similar to the current EOL note. So, all those bugs stay open on the EOL version until EOL+1? That seems poor to me. What do we do if someone clears needinfo and says: Yes, this still affects me, I am running EOL release. Please fix it. We cannot, the EOL release is closed, no more updates or support. How does leaving it open there help? EOL wouldn't be visibile as an available status for bugzilla users to select when closing a bug in the interface, so it does not add to UI clutter, but also makes it easy for us to do reports distinguishing between intentional and eol closure. Is this possible? This gives a much longer timeframe where we're waiting for input, so by the time we actually close, the release has been EOL for a decent while (rather than now, at the I just got around to updating! point). This does risk some false positives (negatives? whatever) where NEEDINFO is cleared with works for me but the bug not closed, but that seems like a less serious problem. Yeah, thats another issue with this... they would stick around in that case until the maintainer or someone came in and cleared them. 2. As #1, but with no new CLOSED:EOL resolution. Instead, use WONTFIX or and add a ClosedEOL keyword automatically. This is uglier than the above but requires no bugzilla change. 3. As #1, but just leave bugs in NEEDINFO state forever. This would possibly require maintainers to update their searches / filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs from older releases. It would also be misleading, IMHO. Hey reporter, I need info to fix this Here you go, here's the info you wanted from my Fedora 7 machine, please provide update kevin -- What do you all think about adding a note to bugs against Fedora N-1 when Fedora N is released, ie: You filed this bug against Fedora 19, and Fedora 20 has recently been released. A new Fedora release includes a version update for many packages, and your issue may have been resolved. Please consider checking to see if your issue persists in Fedora 20 and updating this ticket accordingly. Any bugs remaining open when support ends for Fedora 19, shortly after the release of Fedora 21, unless the issue affects Fedora 20 or Fedora 21. Not polished copy, obviously, but giving the reporter some more warning/prodding can't hurt. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: a stop job is running for User Manager for 0
On Thu, 6 Feb 2014, Reindl Harald wrote: which is user 0 that is yours, an not only yours https://bugzilla.redhat.com/show_bug.cgi?id=1023820 This workaround solved my problem: https://bugzilla.redhat.com/show_bug.cgi?id=1023788#c2 basically: cat /etc/systemd/system/sshd-shutdown.service [Unit] Description=kill all sshd sessions Requires=mutil-user.target [Service] ExecStart=/usr/bin/killall sshd Type=oneshot [Install] WantedBy=shutdown.target reboot.target poweroff.target systemctl daemon-reload systemctl enable sshd-shutdown.service Thanks for the pointer Harald! I do hope the systemd people can fix the real problem with sshd. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Thu, Feb 06, 2014 at 09:49:26AM -0800, Adam Williamson wrote: Your whole proposal more or less *is* the heuristic 'don't autoclose bugs with comments', because of how needinfo works in RH bugzilla. It's not a status (as you imply by writing NEEDINFO) but a flag. If you set the needinfo flag not against a specific person but against 'anyone', then by default, the next person who posts a comment of any kind will clear the flag - they have to uncheck a little box if they want to *not* clear the flag. Thanks, yes. Once upon a time in the decent past (like, embarrassingly long ago) it *was* a status, and apparently way too much of that is still in my brain. I went back and reread what I wrote, and I think it still makes sense with your clarification. The above was certainly exactly why I propose this -- it's not just moving around what we happen to call things, but has an actual positive change to the user experience. It is the case that it being a flag rather than a status makes it a bit more complicated to set up searches for bugs which are open but don't have the flag set. But it's still doable, so I hope that doesn't undermine it too much. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Request to take over package amavisd-new
Hello, Last week, I notified the devel list about Steven Pritchard (FAS: steve) been unresponsive [1], and after many unsuccessful attempts to get bug #695589 fixed [2], I request to take over the package amavisd-new. Any objection? Thank you. [1] https://lists.fedoraproject.org/pipermail/devel/2014-January/194940.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=695589 -- Juan Orti GPG Key: DEEBD08B - http://jorti.fedorapeople.org/pubkey.asc Blog: https://apuntesderoot.wordpress.com/ signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 656 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 146 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 110 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 85 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12091/bip-0.8.9-1.el5 75 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12169/gc-7.1-6.el5 26 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0132/graphviz-2.12-10.el5 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0400/mediawiki119-1.19.11-2.el5 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0418/libyaml-0.1.2-5.el5 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0410/zarafa-7.1.8-1.el5,php53-mapi-7.1.8-1.el5 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0433/puppet-2.7.25-1.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0471/lighttpd-1.4.34-1.el5.1 The following builds have been pushed to Fedora EPEL 5 updates-testing RBTools-0.5.7-1.el5 bind-to-tinydns-0.4.3-5.20140205git32dc9263.el5 lighttpd-1.4.34-1.el5.1 Details about builds: RBTools-0.5.7-1.el5 (FEDORA-EPEL-2014-0459) Tools for use with ReviewBoard Update Information: Bugfixes primarily for Perforce integration http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.5/ http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.4/ http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.3/ Upstream release 0.5.2 This version of RBTools is required in order to operate with recent (1.7+) versions of Review Board. Note that the modern Review Board server is not supported on EPEL5, but this client component is. http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.3/ Upstream release 0.5.2 This version of RBTools is required in order to operate with recent (1.7+) versions of Review Board. Note that the modern Review Board server is not supported on EPEL5, but this client component is. http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.5/ http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.4/ http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.3/ Upstream release 0.5.2 This version of RBTools is required in order to operate with recent (1.7+) versions of Review Board. Note that the modern Review Board server is not supported on EPEL5, but this client component is. http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.3/ Upstream release 0.5.2 This version of RBTools is required in order to operate with recent (1.7+) versions of Review Board. Note that the modern Review Board server is not supported on EPEL5, but this client component is. ChangeLog: * Wed Feb 5 2014 Stephen Gallagher sgall...@redhat.com 0.5.7-1 - New upstream release 0.5.7 - http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.7/ - New upstream release 0.5.6 - http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.6/ * Wed Jan 15 2014 Stephen Gallagher sgall...@redhat.com 0.5.5-1 - New upstream release 0.5.5 - http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.5/ - New upstream release 0.5.4 - http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.4/ - Deprecation: * post-review is deprecated (and has been for a while). It now shows a deprecation warning in order to remind me to use rbt post. - Bug Fixes: * rbt patch: * rbt patch no longer fails to commit on Git if there are untracked files. * Fixed committing changes when the description has unicode characters. * Fixed compatibility with Review Board 2.0 beta. * rbt post: * Fixed R1:R2 syntax for --revision-range for Git repositories. * Fixed name-based lookups for repositories with Subversion. * rbt setup-repo: * Fixed error output when failing to write the .reviewboardrc file. * post-review: * Added --svn-show-copies-as-adds to post-review. * Mon Jan 6 2014 Stephen Gallagher sgall...@redhat.com - 0.5.3-1 - New upstream release 0.5.3 - http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.3/ * Thu Aug 15 2013 Stephen Gallagher sgall...@redhat.com - 0.5.2-1 - New upstream release 0.5.2 - http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.2/ * Fri Aug 2 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.5.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild * Thu May 30 2013 Stephen Gallagher sgall...@redhat.com - 0.5.1-1 - New upstream release 0.5.1 - http://www.reviewboard.org/docs/releasenotes/rbtools/0.5.1/ - Drop upstreamed ez_setup patch - New Features: * Improved the readability of rbt status output * Added
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 656 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 85 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6 49 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12427/seamonkey-2.21-3.esr2.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0378/quassel-0.9.2-1.el6 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0398/socat-1.7.2.3-1.el6 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0395/libpng10-1.0.60-6.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0401/libyaml-0.1.3-4.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0409/zarafa-7.1.8-1.el6 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0429/mediawiki119-1.19.11-2.el6 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0426/tpp-1.3.1-17.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0466/python-gnupg-0.3.6-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0465/lighttpd-1.4.34-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing GMT-4.5.11-1.el6 GMT-coastlines-2.2.4-1.el6 RBTools-0.5.7-1.el6 asciinema-0.9.7-5.el6 bind-to-tinydns-0.4.3-12.20140205git32dc9263.el6 dar-2.4.12-1.el6 docker-io-0.8.0-1.el6 lighttpd-1.4.34-1.el6 llvm-3.4-9.el6 mock-1.1.36-1.el6 python-gnupg-0.3.6-1.el6 transifex-1.2.1-5.el6 Details about builds: GMT-4.5.11-1.el6 (FEDORA-EPEL-2014-0468) Generic Mapping Tools Update Information: Update to 4.5.11. The only non-bug change was adding the latest dimensions for recent Sandwell/Smith img files that go up to 85°, and adding definition file dat.def for mgd77 ASCII DAT format to the x2sys supplement. We also had to modify the –S option in pscontour.c to address a bug. This GMT release also coincides with the latest GSHHG release version 2.2.4 which adds a few missing lakes to California and fixes an error in the Baffin Island coastline and removes skinny spikes from numerous features. Below is the list of bug corrections for individual library files or programs: - gmt_customio.c : The magic recognition of native bit grids failed due to bad math. Wrote wrong number of bytes per record for odd-width Sun rasterfiles. - gmt_grdio.c : Would restrict grid region in grdimage.c despite doing a global map with azimuthal projections. - gmt_io.c : Formats for degree annotations using colons should never end in a trailing colon. Could not properly decode yyodd (no delimiter) time coordinates like 12Oct24. The GMT_import_table function checked for greenwich before assigning the input data. - gmt_init.c : Shifted JD origin by one day (24 Nov, instead of 25 Nov). - gmt_map.c : The oblique Mercator would get the pole on the wrong hemisphere. When -Jx is used with longitudes we must use the wesn clipping and outside functions, not the Cartesian ones. Fixed clipping problem in GMT_wesn_clip for regions larger than 180 but less than 360. GMT_grdproject_init did not handle increments that had been specified as units, e.g., -D30e. - gmt_plot.c : Did not check for map-jumping in GMT_plot_rectangle (psxy -SJ). - gmt_proj.c : Inverse -JR blew up at origin; now added a check. Needed to allow for minor round-off when determining if a point is beyond the horizon for -JG general perspective projection. blockmean.c : Did not use data near west column nodes that were off by 360 for gridline registered grids. - blockmedian.c : Did not use data near west column nodes that were off by 360 for gridline registered grids. - blockmode.c : Did not use data near west column nodes that were off by 360 for gridline registered grids. - filter1d.c : Susceptible to round-off when determining t of first and last output point when -T was not given. - gmtmath.c : The MIN and MAX operators ignored NaNs, but result should be NaN if one of the operands equal NaN. Wrong index order in rarely used SVD part of LSQFIT. - gmtset.c : Did not write values to .gmtdefaults4 if BASEMAP_TYPE was graph or inside. - grdfft.c : Fix normalization for std.dev of power estimate in -E. - grdimage.c : Fix bug represented by the globalgrid.sh test script for mix of -R selections and pixel/gridline choices. - grdblend.c : Despite geographic grids there were no check to shift a grid region by ±360 to match specified output region. - grdlandmask.c : Did not set output as geographic after using -Jx1d. - grdmath.c : The MIN and MAX operators ignored NaNs, but result
Re: Request to take over package amavisd-new
On Thu, 06 Feb 2014 22:07:52 +0100, Juan Orti Alcaine wrote: Hello, Last week, I notified the devel list about Steven Pritchard (FAS: steve) been unresponsive [1], and after many unsuccessful attempts to get bug #695589 fixed [2], I request to take over the package amavisd-new. Any objection? Thank you. [1] https://lists.fedoraproject.org/pipermail/devel/2014-January/194940.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=695589 No objections. There are a couple of packagers where the non-responsive maintainer procedure doesn't work well, because after a long period of inactivity the maintainer returns only briefly and temporarily. In some cases that has lead to starting the procedure again after some months. We need more maintainers per package, so if there is interest in the package, that's great IMO. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: proposal for changes to auto-expiring bugs
On Thu, Feb 06, 2014 at 11:06:07AM -0700, Kevin Fenzi wrote: So, all those bugs stay open on the EOL version until EOL+1? That seems poor to me. What do we do if someone clears needinfo and says: Yes, this still affects me, I am running EOL release. Please fix it. We cannot, the EOL release is closed, no more updates or support. How does leaving it open there help? It doesn't, but I think the trouble of closing those by hand is overall less than the problem of closing too many bugs EOL wouldn't be visibile as an available status for bugzilla users to select when closing a bug in the interface, so it does not add to UI clutter, but also makes it easy for us to do reports distinguishing between intentional and eol closure. Is this possible? I believe so -- you only make the transition available to the Fedora EOL user account. But because it's bugzilla, this kind of thing may involve writing some Perl, and I'm sympathetic to the bugzilla maintenance team not wanting to deal with that. (That's the main reason for suggesting the second option, of setting a keyword instead.) This does risk some false positives (negatives? whatever) where NEEDINFO is cleared with works for me but the bug not closed, but that seems like a less serious problem. Yeah, thats another issue with this... they would stick around in that case until the maintainer or someone came in and cleared them. Yes, but see the other message. At the very least, I bet it will be dozens or at worst hundreds, which is a managable amount for people interested in helping with EOL triage. On the other side, we have many thousands of auto-closed bugs right now. And I think that triage work would really only be needed if we end up feeling that we've tilted the balance too far in the direction of making the package maintainers clean up. 3. As #1, but just leave bugs in NEEDINFO state forever. This would possibly require maintainers to update their searches / filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs from older releases. It would also be misleading, IMHO. Hey reporter, I need info to fix this In this case, the message would be something like We're sorry we weren't able to resolve this bug within the lifespan of Fedora ##. We do appreciate the report, and we may be able to fix it in the next release. Could you please confirm that this is still an issue in the latest release of Fedora? Thank you. With this message, if needinfo is cleared, and then the bug isn't touched for a long time, it would probably be a good candidate for human triage. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
yum-builddep bash completion
Does any packager use yum-builddep bash completion and would like to explain it to me? https://bugzilla.redhat.com/884303 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: yum-builddep bash completion
On 02/06/2014 01:42 PM, Michael Schwendt wrote: Does any packager use yum-builddep bash completion and would like to explain it to me? https://bugzilla.redhat.com/884303 I don't know about that in particular, but one handy trick is to use bash complete-filename (M-/) instead of the general complete (TAB). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Adjust wiki for ARM BeagleBone Black
I adjusted this documentation in wiki: https://fedoraproject.org/wiki/Architectures/ARM/F20/Installation#For_the_BeagleBone_Black Added this important step to create image of Fedora 20 for BeagleBone Black board. this important step being what exactly? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Request to take over package amavisd-new
Yes please take it. This package on EPEL has permission problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1052853] Unnecessary dependencies
https://bugzilla.redhat.com/show_bug.cgi?id=1052853 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Throwable-0.102080-11. |perl-Throwable-0.102080-11. |fc20|fc19 --- Comment #7 from Fedora Update System upda...@fedoraproject.org --- perl-Throwable-0.102080-11.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=4G3eBGQ0qSa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1058723] FTBFS: perl-DBD-Pg-2.19.3-5.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058723 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-DBD-Pg-2.19.3-6.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=zRVIWVS3r3a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Adjust wiki for ARM BeagleBone Black
Peter, Changed in this part: Change one option in this file(only BeagleBone Black): vi /run/media/$USER/uboot/uEnv.txt abcboard=am335x-bone abcboard=am335x-boneblack Added. firemanxbr On Thu, Feb 6, 2014 at 9:32 PM, Peter Robinson pbrobin...@gmail.com wrote: I adjusted this documentation in wiki: https://fedoraproject.org/wiki/Architectures/ARM/F20/Installation#For_the_BeagleBone_Black Added this important step to create image of Fedora 20 for BeagleBone Black board. this important step being what exactly? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 970742] Test-File-ShareDir 0.3.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=970742 --- Comment #2 from Ken Dreyer ktdre...@ktdreyer.com --- Created attachment 860373 -- https://bugzilla.redhat.com/attachment.cgi?id=860373action=edit Update to Test::File::ShareDir 0.3.3. Hi Iain, Path::Tiny is now in Fedora (bug 1003660). Here's a patch against master/rawhide. F21 scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6503255 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=6MlVZn3goSa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: f20, anaconda, net install and video out of range ....
On Mon, 2014-02-03 at 14:28 -0500, Adam Jackson wrote: Why would it not install xorg-x11-drv-cirrus when it sees the physical card? We don't have anything like the kernel's modaliases for X drivers, at least not exposed in a way anaconda could use. Of course, it's possible to do this. all you need is some poor sap to maintain something like this: http://svnweb.mageia.org/soft/ldetect-lst/trunk/lst/pcitable?view=markup I was that poor sap, for a year or two. It was not an enjoyable experience. Yes, I know pciids exists: it's a useful resource if you're the poor sap who has to maintain a list like that, but it doesn't solve everything (it doesn't do the actual driver mapping, for a start). What X does is dumb, and very simple: it basically looks at the manufacturer ID and picks a driver based on that. If you've got a Cirrus card, you're getting cirrus. If you've got an ATI card, you're getting 'ati'. If you've got an NVIDIA card, you're getting nouveau. I think it has a very few quirks and exceptions, but really not many. Even if we 'exposed' X's autodetection stuff, it wouldn't be doing a whole lot of device-by-device distinctions. If some poor sap is willing to spend literally dozens of hours a release painstakingly hand-weeding something like M*a's ldetect-lst you can get some minor benefits, like doing this kind of distinction where we want to load the native driver for a real card but not qemu's emulated cirrus. Or blacklist cards known not to currently work with their native driver. Or load the correct generation of proprietary driver, if your distribution cares about proprietary drivers. (Or combine the above, like THIS nvidia card needs THIS proprietary driver, THIS one doesn't work right with the proprietary driver so we should use nouveau, and THIS one doesn't work with anything so let's load the fallback driver.) But it's incredibly dull work and the benefit really isn't that _huge_. I feel like my time is probably more productively spent, overall, doing other things. Of course, we're 'just' talking about one case, but once you start building this kind of manual device/driver table, it tends to take on a mind of its own and start multiplying. I'm rather attached to the policy of Just Saying No. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaned packages
On Thu, Feb 6, 2014 at 4:13 AM, Toshio Kuratomi a.bad...@gmail.com wrote: npajkovs: Weird, In Dec 2013 he(staff@RH) did an update to ipraf-ng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1058709] FTBFS: perl-DBD-SQLite-1.40-2.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058709 --- Comment #9 from Fedora Update System upda...@fedoraproject.org --- perl-DBD-SQLite-1.37-5.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=OTXkhIqqlPa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1052853] Unnecessary dependencies
https://bugzilla.redhat.com/show_bug.cgi?id=1052853 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Throwable-0.102080-11. ||fc20 Resolution|--- |ERRATA Last Closed||2014-02-06 22:11:47 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- perl-Throwable-0.102080-11.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=7DBVru3LJEa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1058723] FTBFS: perl-DBD-Pg-2.19.3-5.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058723 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-DBD-Pg-2.19.3-4.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=l5Y98n4Btma=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1058709] FTBFS: perl-DBD-SQLite-1.40-2.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058709 --- Comment #8 from Fedora Update System upda...@fedoraproject.org --- perl-DBD-SQLite-1.40-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=tUSeCoNy2Ia=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1062424] perl-Capture-Tiny: insecure temporary file usage
https://bugzilla.redhat.com/show_bug.cgi?id=1062424 Murray McAllister mmcal...@redhat.com changed: What|Removed |Added Alias||CVE-2014-1875 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=pcgo17n6s4a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1062424] CVE-2014-1875 perl-Capture-Tiny: insecure temporary file usage
https://bugzilla.redhat.com/show_bug.cgi?id=1062424 Murray McAllister mmcal...@redhat.com changed: What|Removed |Added Summary|perl-Capture-Tiny: insecure |CVE-2014-1875 |temporary file usage|perl-Capture-Tiny: insecure ||temporary file usage -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=UuFjWRPNVCa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1062424] CVE-2014-1875 perl-Capture-Tiny: insecure temporary file usage
https://bugzilla.redhat.com/show_bug.cgi?id=1062424 Murray McAllister mmcal...@redhat.com changed: What|Removed |Added CC||mmcal...@redhat.com --- Comment #3 from Murray McAllister mmcal...@redhat.com --- This issue was assigned CVE-2014-1875: http://seclists.org/oss-sec/2014/q1/272 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=6YIHRHbE0qa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Packages installing files to /etc/rpm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2014 03:23 AM, Ville Skyttä wrote: A number of packages install files to /etc/rpm in Rawhide; the proper place for macros.* is /usr/lib/rpm/macros.d for rpm = 4.11. And no matter what the location, these files should not be marked as %config. ... s4504kr gnustep-make s4504kr,salimma Fixed in gnustep-make-2.6.6-2 - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: michel-...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS9HwXAAoJEEr1VKujapN6uLcH/RwBJ6BLneiEgtLxPzOAtHwa MwBbO1R3NkOc4HtB03e+YqlewYVbFXZhgQDF5rUYU0SMc/y6Yyh0uHFsvtOtuycj l5cNxMsIG3CiF1xuVeDkDVdWwyFX7UtzbW0MgdzrPvJA22c8s63fmlleED/rzz2V 75PXMhnbGtTwYKRH2rhcFUsFSfVFm6O661S8+jAk+quLLZc/qsA7IbacUFcHBJzV VklCPDp+sx1R50YIcuNBuMzZ4Vj8feQGWZ98nbCETCo4tytZIA74TsN8N90maNHD ZrJrVXsYK5KJOYHSEikRihBlg00pP6e8Hx5Aj2QAupKTQN89nQ6DvzGaOo6hZcU= =UbX4 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Adjust wiki for ARM BeagleBone Black
That's not necessary abcboard is not used and has been removed from newer uboot builds uEnv.text files. Dennis On February 7, 2014 3:13:27 AM CET, Marcelo Barbosa fireman...@fedoraproject.org wrote: Peter, Changed in this part: Change one option in this file(only BeagleBone Black): vi /run/media/$USER/uboot/uEnv.txt abcboard=am335x-bone abcboard=am335x-boneblack Added. firemanxbr On Thu, Feb 6, 2014 at 9:32 PM, Peter Robinson pbrobin...@gmail.com wrote: I adjusted this documentation in wiki: https://fedoraproject.org/wiki/Architectures/ARM/F20/Installation#For_the_BeagleBone_Black Added this important step to create image of Fedora 20 for BeagleBone Black board. this important step being what exactly? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Sent from my Android device with K-9 Mail. Please excuse my brevity.-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Thu, 2014-02-06 at 13:21 +0100, Michael Schwendt wrote: Has that been tried before? It sounds like a better approach. Not while I've been around, at least. Where is the human to notice comments after EOL and act accordingly? There are always a minimum of two people active on any ticket who can change it in any way: the reporter and the assignee. How many tickets would be affected by a comment after EOL? Don't know, probably wouldn't be too hard to look. What is the underlying problem here anyway? I've never been hugely convinced there is one, but the problem people *claim* there is is that closing bugs on EOL releases gives a bad impression to people who report the bugs. Too many unhandled tickets - EOL auto-close threatening - too many closed tickets to handle - how to escape from that loop? In several large upstream bug trackers it is no different. Are developers always informed about what doesn't work even when not responding to tickets? Why should users still take the time to submit problem reports if they don't get a response? Why do you think they're any more likely to get a response if the bug stays open? algorithms are never perfect, but we do have to use them, as a perennially under-resourced project. I've posted about it in 2008 already, and I still think the auto-closing leads to hiding crap under the carpet. We already don't have enough time to look after all the open bugs we have. Why are things going to be better if we have more? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Upstream releases monitoring globbing support?
Hi, Good news to hear that cnucnu has supported glob, I've seen Jens has enabled all hackage packages from a horrible long list to ghc-* one line only. Should we do this for Perl packages also? Thanks. -- -- Yours sincerely, Christopher Meng Noob here. http://cicku.me -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Upstream releases monitoring globbing support?
Hi, On Wed, Feb 05, 2014 at 06:51:43PM +0800, Christopher Meng wrote: Good news to hear that cnucnu has supported glob, I've seen Jens has enabled all hackage packages from a horrible long list to ghc-* one line only. Should we do this for Perl packages also? I plan to make this for Perl packages as well, but it requires some adjustments to support special cases such as * perl-Fedora-Rebuild Fedora-Rebuild-v([^-/_\s]+)\.tar\b http://ppisar.fedorapeople.org/Fedora-Rebuild/ properly. But this is on my TODO list. Currently the perl package list is not as uniform as the others I already modified were (e.g. ghc, where every package used the same regex/URL), otherwise it would work for perl packages as well. Regards Till -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Upstream releases monitoring globbing support?
On Wed, Feb 05, 2014 at 12:36:12PM +0100, Petr Pisar wrote: On Wed, Feb 05, 2014 at 06:51:43PM +0800, Christopher Meng wrote: Good news to hear that cnucnu has supported glob, I've seen Jens has enabled all hackage packages from a horrible long list to ghc-* one line only. Should we do this for Perl packages also? Not all packages are from CPAN, not all maintainers want to receive upstream updates. If someone does not want notifications for their packages, they can add their name to this list: https://fedoraproject.org/wiki/Upstream_release_monitoring#Package_Owner_Ignore_List Or is there a rule that more specific match wins? That could be used to override perl-* glob for non-CPAN packages. This is what is on my TODO list. :-) And adding support for a package ignore list. Regards Till -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Upstream releases monitoring globbing support?
On Wed, Feb 05, 2014 at 03:18:04PM +0100, Ralf Corsepius wrote: It's not about indiviiduals it's about defaults and it's about the harm your defaults are causing: 1000s of emails plastering various mailing lists and inboxes. Actually I do not care whether or not perl packages are monitored. But the current situation does not seem to cause much harm, because there is hardly any negative feedback about the current situation. Also enough maintainers cared to add about 800 packages manually to the monitoring system. Regards Till -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Upstream releases monitoring globbing support?
On Wed, Feb 05, 2014 at 12:46:58PM +0100, Ralf Corsepius wrote: On 02/05/2014 12:44 PM, Till Maas wrote: If someone does not want notifications for their packages, they can add their name to this list: https://fedoraproject.org/wiki/Upstream_release_monitoring#Package_Owner_Ignore_List IMO, such stuff MUST be opt-in, not opt-out. I added your username already a long time ago, so you/your packages are not affected. Regards Till -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: dspam
dspam has broken dependencies in the epel-7 tree: On x86_64: dspam-3.10.2-9.el7.x86_64 requires perl(Mail::MboxParser) On ppc64: dspam-3.10.2-9.el7.ppc64 requires perl(Mail::MboxParser) On x86_64: dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::lines3d) dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::lines) dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::bars) On ppc64: dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::lines3d) dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::lines) dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::bars) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the epel-7 tree: On x86_64: perl-PDL-2.7.0-2.el7.1.x86_64 requires perl(Prima::MsgBox) On ppc64: perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(Prima::MsgBox) perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(PDL::Slatec) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: w3c-markup-validator
w3c-markup-validator has broken dependencies in the epel-7 tree: On x86_64: w3c-markup-validator-1.3-4.el7.noarch requires perl(HTML::Template) On ppc64: w3c-markup-validator-1.3-4.el7.noarch requires perl(SGML::Parser::OpenSP) = 0:0.991 w3c-markup-validator-1.3-4.el7.noarch requires perl(HTML::Template) On x86_64: w3c-markup-validator-libs-1.3-4.el7.noarch requires html401-dtds On ppc64: w3c-markup-validator-libs-1.3-4.el7.noarch requires html401-dtds Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File DBD-Pg-3.0.0.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-DBD-Pg: 58c2613bcb241279aca4c111ba16db48 DBD-Pg-3.0.0.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBD-Pg] 3.0.0 bump
commit 73de2d1e6c0d17f3ebe48f63ac8f5557246649dc
Author: Jitka Plesnikova jples...@redhat.com
Date: Thu Feb 6 11:36:43 2014 +0100
3.0.0 bump
.gitignore |1 +
...for-the-PrintWarn-test-as-Postgres-got-le.patch | 27 --
perl-DBD-Pg.spec | 30 +--
sources|2 +-
4 files changed, 22 insertions(+), 38 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index fd0989c..f82fe3c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@ DBD-Pg-2.17.1.tar.gz
/DBD-Pg-2.18.0.tar.gz
/DBD-Pg-2.19.2.tar.gz
/DBD-Pg-2.19.3.tar.gz
+/DBD-Pg-3.0.0.tar.gz
diff --git a/perl-DBD-Pg.spec b/perl-DBD-Pg.spec
index 649fc81..a5c8c34 100644
--- a/perl-DBD-Pg.spec
+++ b/perl-DBD-Pg.spec
@@ -1,47 +1,55 @@
Name: perl-DBD-Pg
Summary:A PostgreSQL interface for perl
-Version:2.19.3
-Release:6%{?dist}
+Version:3.0.0
+Release:1%{?dist}
License:GPLv2+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/T/TU/TURNSTEP/DBD-Pg-%{version}.tar.gz
-# Adapt to changes in Postgres 9.3, in upstream after 2.19.3, bug #1058723,
-# CPAN RT#88865
-Patch0:
DBD-Pg-2.19.3-Use-DEBUG1-for-the-PrintWarn-test-as-Postgres-got-le.patch
URL:http://search.cpan.org/dist/DBD-Pg/
BuildRequires: perl(Carp)
-BuildRequires: perl(constant)
+BuildRequires: perl(Config)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Spec)
BuildRequires: perl(lib)
+BuildRequires: perl(strict)
+BuildRequires: perl(vars)
+BuildRequires: perl(warnings)
BuildRequires: postgresql-devel = 7.4
# Run-time:
# Prevent bug #443495
-BuildRequires: perl(DBI) = 1.607
+BuildRequires: perl(DBI) = 1.614
+BuildRequires: perl(DynaLoader)
BuildRequires: perl(Exporter)
BuildRequires: perl(version)
# Tests:
+%tests_req perl(charnames)
+%tests_req perl(constant)
%tests_req perl(Cwd)
%tests_req perl(Data::Dumper)
-%tests_req perl(Test::More) = 0.61
+%tests_req perl(Test::More) = 0.88
%tests_req perl(Test::Simple)
%tests_req perl(Time::HiRes)
+%tests_req perl(utf8)
%tests_req postgresql-server
# Optional tests:
%tests_req perl(Encode)
%tests_req perl(File::Temp)
# test sub-package requirements
%tests_subpackage_requires perl(Carp)
+%tests_subpackage_requires perl(Config)
%tests_subpackage_requires perl(Data::Peek)
%tests_subpackage_requires perl(DBD::Pg)
%tests_subpackage_requires perl(DBI)
%tests_subpackage_requires perl(File::Spec)
%tests_subpackage_requires perl(lib)
+%tests_subpackage_requires perl(strict)
+%tests_subpackage_requires perl(vars)
+%tests_subpackage_requires perl(warnings)
%tests_subpackage_requires perl(YAML)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-Requires: perl(DBI) = 1.52
+Requires: perl(DBI) = 1.614
# Missed by the find provides script:
Provides: perl(DBD::Pg) = %{version}
@@ -57,7 +65,6 @@ to PostgreSQL databases.
%prep
%setup -q -n DBD-Pg-%{version}
-%patch0 -p1
# Move testme.tmp.pl into tests sub-package
mv testme.tmp.pl t/
sed -i -e '/^testme.tmp.pl$/ s/^/t\//' MANIFEST
@@ -91,6 +98,9 @@ make test
%changelog
+* Wed Feb 05 2014 Jitka Plesnikova jples...@redhat.com - 3.0.0-1
+- 3.0.0 bump
+
* Wed Jan 29 2014 Petr Pisar ppi...@redhat.com - 2.19.3-6
- Adapt to changes in Postgres 9.3 (bug #1058723)
diff --git a/sources b/sources
index 0968acc..e5b6b1a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-026ea19f89aee12051bce23d797e824b DBD-Pg-2.19.3.tar.gz
+58c2613bcb241279aca4c111ba16db48 DBD-Pg-3.0.0.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1061113] perl-Text-Aligner-0.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1061113 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Text-Aligner-0.10-1.fc ||21 Resolution|--- |RAWHIDE Last Closed||2014-02-06 05:45:06 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=qLOCYsv6boa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1061108] perl-DBD-Pg-3.0.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1061108 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-DBD-Pg-3.0.0-1.fc21 Resolution|--- |RAWHIDE Last Closed||2014-02-06 05:45:26 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=LFPq2qKgLaa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1044943] perl-Gtk2 GUI programs fails to start when using DBD::Pg
https://bugzilla.redhat.com/show_bug.cgi?id=1044943 --- Comment #11 from do...@uhusystems.com --- Tried my program and the test cases with the upgraded perl-Glib, and everything works fine. Thanks. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fIcXnPwadsa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1044943] perl-Gtk2 GUI programs fails to start when using DBD::Pg
https://bugzilla.redhat.com/show_bug.cgi?id=1044943 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |ERRATA Last Closed||2014-02-06 06:57:20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=J3IMzWtGqPa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1060465] Review Request: perl-Excel-Writer-XLSX - Create a new file in the Excel 2007+ XLSX format
https://bugzilla.redhat.com/show_bug.cgi?id=1060465 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com Assignee|nob...@fedoraproject.org|psab...@redhat.com Flags||fedora-review? --- Comment #2 from Petr Šabata psab...@redhat.com --- I'm taking the review and will sponsor you once the package is in a reasonable state. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=mBqJI72VBEa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Upstream releases monitoring globbing support?
On 02/05/2014 06:26 PM, Till Maas wrote: On Wed, Feb 05, 2014 at 03:18:04PM +0100, Ralf Corsepius wrote: It's not about indiviiduals it's about defaults and it's about the harm your defaults are causing: 1000s of emails plastering various mailing lists and inboxes. Actually I do not care whether or not perl packages are monitored. But the current situation does not seem to cause much harm, because there is hardly any negative feedback about the current situation. Not unlikely. People maintaining only a few packages will only receive a few mail. I am receiving many of them, often duplicates and triple from various origins + followups from bugzilla + koji. All in all they are adding a significant contribution to the SPAM flood koji Co already are emitting. If you want to get an imagination, about the amount I am receiving, check out the perl-list's archive: https://lists.fedoraproject.org/pipermail/perl-devel/2014-February/date.html and imagine you'd receive all of these mails 2-3 times. Also enough maintainers cared to add about 800 packages manually to the monitoring system. Well, I guess these 800 packages condense down to a very small number of individuals. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-qpid_proton
perl-qpid_proton has broken dependencies in the rawhide tree: On x86_64: perl-qpid_proton-0.6-1.fc21.x86_64 requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.x86_64 requires perl(qpid::proton::ExceptionHandling) On i386: perl-qpid_proton-0.6-1.fc21.i686 requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.i686 requires perl(qpid::proton::ExceptionHandling) On armhfp: perl-qpid_proton-0.6-1.fc21.armv7hl requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.armv7hl requires perl(qpid::proton::ExceptionHandling) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Catalyst-Controller-HTML-FormFu
perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide tree: On x86_64: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On i386: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On armhfp: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1062227] New: perl-PerlIO-locale-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1062227 Bug ID: 1062227 Summary: perl-PerlIO-locale-0.09 is available Product: Fedora Version: rawhide Component: perl-PerlIO-locale Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.09 Current version/release in Fedora Rawhide: 0.08-8.fc20 URL: http://search.cpan.org/dist/PerlIO-locale/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=INxU48x14Na=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1062229] New: perl-Text-CSV_XS-1.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1062229 Bug ID: 1062229 Summary: perl-Text-CSV_XS-1.04 is available Product: Fedora Version: rawhide Component: perl-Text-CSV_XS Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 1.04 Current version/release in Fedora Rawhide: 1.03-1.fc21 URL: http://search.cpan.org/dist/Text-CSV_XS/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=yHsMzzJJQfa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1061114] perl-URI-Find-Simple-1.05 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1061114 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-URI-Find-Simple-1.04 |perl-URI-Find-Simple-1.05 |is available|is available --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 1.05 Current version/release in Fedora Rawhide: 1.03-7.fc20 URL: http://search.cpan.org/dist/URI-Find-Simple/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=mROz5lbKRTa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1061115] perl-URI-Title-1.88 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1061115 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-URI-Title-1.87 is |perl-URI-Title-1.88 is |available |available --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 1.88 Current version/release in Fedora Rawhide: 1.86-7.fc21 URL: http://search.cpan.org/dist/URI-Title/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=0FAxe08cqra=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Dancer-1.3121.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Dancer: 145e26f42b12c8bffec1bcf64fd831e4 Dancer-1.3121.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Dancer] 1.3121 bump
commit 5819def68a23fed87f8c3ab6716070fd2f6739b9
Author: Jitka Plesnikova jples...@redhat.com
Date: Thu Feb 6 15:25:03 2014 +0100
1.3121 bump
.gitignore |1 +
perl-Dancer.spec |7 ++-
sources |2 +-
3 files changed, 8 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 25c7747..382af88 100644
--- a/.gitignore
+++ b/.gitignore
@@ -22,3 +22,4 @@
/Dancer-1.3118.tar.gz
/Dancer-1.3119.tar.gz
/Dancer-1.3120.tar.gz
+/Dancer-1.3121.tar.gz
diff --git a/perl-Dancer.spec b/perl-Dancer.spec
index bb133f8..355707f 100644
--- a/perl-Dancer.spec
+++ b/perl-Dancer.spec
@@ -1,5 +1,5 @@
Name: perl-Dancer
-Version:1.3120
+Version:1.3121
Release:1%{?dist}
Summary:Lightweight yet powerful web application framework
License:GPL+ or Artistic
@@ -17,7 +17,9 @@ BuildRequires: perl(Cwd)
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Encode)
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Fcntl)
BuildRequires: perl(File::Basename)
+BuildRequires: perl(File::Copy)
BuildRequires: perl(File::Path)
BuildRequires: perl(File::Spec)
BuildRequires: perl(File::Temp)
@@ -113,6 +115,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Feb 06 2014 Jitka Plesnikova jples...@redhat.com - 1.3121-1
+- 1.3121 bump
+
* Thu Jan 02 2014 Jitka Plesnikova jples...@redhat.com - 1.3120-1
- 1.3120 bump
diff --git a/sources b/sources
index eafb9a3..b1bd2e2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-00b769c198ab91be23a03e558d737b4f Dancer-1.3120.tar.gz
+145e26f42b12c8bffec1bcf64fd831e4 Dancer-1.3121.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1062267] New: IPC::Run3::run3($command, \undef) clobbers STDIN
https://bugzilla.redhat.com/show_bug.cgi?id=1062267
Bug ID: 1062267
Summary: IPC::Run3::run3($command, \undef) clobbers STDIN
Product: Fedora
Version: 20
Component: perl-IPC-RUN3
Assignee: rc040...@freenet.de
Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
External Bug ID: CPAN 52317
If IPC::Run3::run3() is invoked with \undef for command's standard input, it
will clobber STDIN, so STDIN is unusable after return from run3():
Reproducer:
$ printf '1\n2\n'| perl -MIPC::Run3 -e 'while () { print; run3([q{true}],
\undef) }'
1
This should print:
1
2
But it stops after first loop.
Observed in perl-IPC-Run3-0.046-3.fc20.noarch, F20.
Reported to upstream, patch is there.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=CaSYOvvwS4a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1062267] IPC::Run3::run3($command, \undef) clobbers STDIN
https://bugzilla.redhat.com/show_bug.cgi?id=1062267 --- Comment #1 from Petr Pisar ppi...@redhat.com --- Created attachment 860208 -- https://bugzilla.redhat.com/attachment.cgi?id=860208action=edit Proposed fix -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fS66sZvKu0a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1060465] Review Request: perl-Excel-Writer-XLSX - Create a new file in the Excel 2007+ XLSX format
https://bugzilla.redhat.com/show_bug.cgi?id=1060465 --- Comment #3 from Petr Šabata psab...@redhat.com --- Items marked as TODO are optional but recommended fixes; FIX are review blockers. TODO: Drop the BuildRoot tag unless you plan to push this into EPEL5 too. This is no longer needed. TODO: The same applies to line 31 (rm -rf $RPM_BUILD_ROOT) and the whole %clean section. TODO: Remove %defattr, this is no longer required, not even in EPEL. TODO: I think the same applies to removing empty directories on line 36. TODO: Utilize DESTDIR instead of PERL_INSTALL_ROOT, line 33. TODO: Package the `examples' directory in %doc. TODO: Remove META.json from %doc; this file is of no use to the end users. Dependencies: You'll need to BuildRequire all the use'd and require'd modules to prevent possible future build failures caused by buildroot changes. FIX: BR perl TODO: BR perl(autouse) FIX: BR perl(Carp) TODO: BR perl(Date::Calc) -- this is an optional test dependency TODO: BR perl(Date::Manip) -- ditto FIX: BR perl(Encode) FIX: BR perl(Exporter) TODO: BR perl(File::Basename) FIX: BR perl(File::Copy) FIX: BR perl(File::Find) TODO: BR perl(integer) TODO: BR perl(IO::File) FIX: BR perl(lib) FIX: BR perl(List::Util) TODO: BR perl(strict) FIX: BR perl(Test::More) TODO: BR perl(utf8) TODO: BR perl(warnings) FIX: Drop the perl(Test::Simple) BR, it's not used anywhere. TODO: You (run-) require specific versions of Archive::Zip and File::Temp. You should filter out the unversioned automatically detected requires from the resulting RPM. This page will tell you how to achieve that: https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering FIX: Your changelog entry is malformed. Use one of the formats mentioned in the guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Changelogs -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=HslAEm8Rqsa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1062267] IPC::Run3::run3($command, \undef) clobbers STDIN
https://bugzilla.redhat.com/show_bug.cgi?id=1062267
--- Comment #2 from Ralf Corsepius rc040...@freenet.de ---
(In reply to Petr Pisar from comment #0)
If IPC::Run3::run3() is invoked with \undef for command's standard input, it
will clobber STDIN, so STDIN is unusable after return from run3():
Reproducer:
$ printf '1\n2\n'| perl -MIPC::Run3 -e 'while () { print; run3([q{true}],
\undef) }'
1
This should print:
1
2
But it stops after first loop.
Observed in perl-IPC-Run3-0.046-3.fc20.noarch, F20.
Reported to upstream, patch is there.
Thanks for the report.
Presuming you to have tested all this carefully and just being into it and me
not having enough time to look into this today, feel free to apply the patch to
git.
Otherwise, I'll look into it, tomorrow.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=4NWaAMhVxka=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-Table] META updates only
commit 0a90acc99784a2ad118c75ffedc6e47997876a43
Author: Petr Šabata con...@redhat.com
Date: Thu Feb 6 16:13:50 2014 +0100
META updates only
- Fix a changelog bogus date
.gitignore |1 +
perl-Text-Table.spec |8 ++--
sources |2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d0a2a64..7ed03d1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -11,3 +11,4 @@ Text-Table-1.114.tar.gz
/Text-Table-1.126.tar.gz
/Text-Table-1.127.tar.gz
/Text-Table-1.128.tar.gz
+/Text-Table-1.129.tar.gz
diff --git a/perl-Text-Table.spec b/perl-Text-Table.spec
index 7823765..678944f 100644
--- a/perl-Text-Table.spec
+++ b/perl-Text-Table.spec
@@ -1,5 +1,5 @@
Name: perl-Text-Table
-Version:1.128
+Version:1.129
Release:1%{?dist}
Summary:Organize Data in Tables
License:ISC
@@ -59,6 +59,10 @@ perl Build.PL installdirs=vendor
%{_mandir}/man3/*
%changelog
+* Thu Feb 06 2014 Petr Šabata con...@redhat.com - 1.129-1
+- META updates only
+- Fix a changelog bogus date
+
* Tue Oct 29 2013 Petr Šabata con...@redhat.com - 1.128-1
- 1.128 bump
@@ -110,7 +114,7 @@ perl Build.PL installdirs=vendor
* Mon May 30 2011 Petr Sabata con...@redhat.com 1.121-1
- 1.121 bump
-* Fri May 16 2011 Marcela Mašláňová mmasl...@redhat.com 1.120-1
+* Mon May 16 2011 Marcela Mašláňová mmasl...@redhat.com 1.120-1
- 1.120 bump
- clean deffattr
- license changed since 1.120 to ISC = BSD (2 clause)
diff --git a/sources b/sources
index 3935827..4b5e1fe 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d6ac37f87ee80b975f13549d2e5720d1 Text-Table-1.128.tar.gz
+13c07d0bf8d3c9b2f889232a318d0101 Text-Table-1.129.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Text-Table-1.129.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Text-Table: 13c07d0bf8d3c9b2f889232a318d0101 Text-Table-1.129.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1060483] perl-Text-Table-1.129 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1060483 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Text-Table-1.129-1.fc2 ||1 Resolution|--- |RAWHIDE Last Closed||2014-02-06 10:18:23 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=hmLaED0hGda=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File PerlIO-locale-0.09.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-PerlIO-locale: 5cb7241c0e9c7ff7c87a0d9759bcdcea PerlIO-locale-0.09.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-PerlIO-locale] 0.09 bump
commit d665170e1a5aac08921429238ba6788f996f8d4d
Author: Petr Písař ppi...@redhat.com
Date: Thu Feb 6 16:37:13 2014 +0100
0.09 bump
.gitignore |1 +
perl-PerlIO-locale.spec | 26 +-
sources |2 +-
3 files changed, 19 insertions(+), 10 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0285e68..ec55b60 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/PerlIO-locale-0.07.tar.gz
/PerlIO-locale-0.08.tar.gz
+/PerlIO-locale-0.09.tar.gz
diff --git a/perl-PerlIO-locale.spec b/perl-PerlIO-locale.spec
index b9c812e..21d8060 100644
--- a/perl-PerlIO-locale.spec
+++ b/perl-PerlIO-locale.spec
@@ -1,21 +1,27 @@
Name: perl-PerlIO-locale
-Version:0.08
-Release:8%{?dist}
+Version:0.09
+Release:1%{?dist}
Summary:PerlIO layer to use the encoding of the current locale
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/PerlIO-locale/
Source0:
http://www.cpan.org/authors/id/R/RG/RGARCIA/PerlIO-locale-%{version}.tar.gz
+BuildRequires: perl
+BuildRequires: perl(Config)
BuildRequires: perl(ExtUtils::MakeMaker)
-# Tests:
+# Run-time:
BuildRequires: perl(PerlIO::encoding)
+BuildRequires: perl(strict)
+BuildRequires: perl(XSLoader)
+# Tests:
+BuildRequires: perl(I18N::Langinfo)
BuildRequires: perl(POSIX)
BuildRequires: perl(Test::More)
-BuildRequires: perl(XSLoader)
+BuildRequires: perl(warnings)
# Optional tests:
BuildRequires: perl(Test::Pod) = 1.14
BuildRequires: perl(Test::Pod::Coverage) = 1.04
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%{?perl_default_filter}
@@ -33,26 +39,28 @@ the locale currently in effect, if perl can guess it.
%setup -q -n PerlIO-locale-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
make %{?_smp_mflags}
%install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
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
make test
%files
-%doc ChangeLog README
+%doc README
%{perl_vendorarch}/auto/*
%{perl_vendorarch}/PerlIO*
%{_mandir}/man3/*
%changelog
+* Thu Feb 06 2014 Petr Pisar ppi...@redhat.com - 0.09-1
+- 0.09 bump
+
* Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.08-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 16006fa..5d6b966 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-7ad4586a56809cd04f49eaed57cf5603 PerlIO-locale-0.08.tar.gz
+5cb7241c0e9c7ff7c87a0d9759bcdcea PerlIO-locale-0.09.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1062227] perl-PerlIO-locale-0.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1062227 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-PerlIO-locale-0.09-1.f ||c21 Resolution|--- |RAWHIDE Last Closed||2014-02-06 10:50:26 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This just corrects build script. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=EBbhTwLEyNa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File URI-Find-Simple-1.05.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-URI-Find-Simple: b10a94a80fefe044cf9d9b34158b6718 URI-Find-Simple-1.05.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-URI-Find-Simple] 1.05 bump
commit bbd723c1627a0b8704aa4111049a40ceed6c0a30
Author: Petr Šabata con...@redhat.com
Date: Thu Feb 6 17:13:02 2014 +0100
1.05 bump
.gitignore|1 +
perl-URI-Find-Simple.spec | 21 +
sources |2 +-
3 files changed, 15 insertions(+), 9 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ef13e05..f47c29c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/URI-Find-Simple-1.03.tar.gz
+/URI-Find-Simple-1.05.tar.gz
diff --git a/perl-URI-Find-Simple.spec b/perl-URI-Find-Simple.spec
index 06e0882..611a5fb 100644
--- a/perl-URI-Find-Simple.spec
+++ b/perl-URI-Find-Simple.spec
@@ -1,19 +1,22 @@
Name: perl-URI-Find-Simple
-Version:1.03
-Release:7%{?dist}
+Version:1.05
+Release:1%{?dist}
Summary:Simple interface to URI::Find
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/URI-Find-Simple/
Source0:
http://www.cpan.org/authors/id/T/TO/TOMI/URI-Find-Simple-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(lib)
+BuildRequires: perl
BuildRequires: perl(Carp)
BuildRequires: perl(Encode)
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(lib)
+BuildRequires: perl(strict)
BuildRequires: perl(Test::More)
BuildRequires: perl(URI::Find)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+BuildRequires: perl(warnings)
+Requires: perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo
$version))
%description
URI::Find is all very well, but sometimes you just want a list of the links
@@ -31,20 +34,22 @@ perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-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 \;
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} +
%{_fixperms} %{buildroot}/*
%check
make test
%files
-%doc Changes
+%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Thu Feb 06 2014 Petr Šabata con...@redhat.com - 1.05-1
+- 1.05 bump
+
* Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.03-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 843e496..315aeae 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a3d62887ea6b6a17559364e8a31fcd8f URI-Find-Simple-1.03.tar.gz
+b10a94a80fefe044cf9d9b34158b6718 URI-Find-Simple-1.05.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1062267] IPC::Run3::run3($command, \undef) clobbers STDIN
https://bugzilla.redhat.com/show_bug.cgi?id=1062267 --- Comment #3 from Petr Pisar ppi...@redhat.com --- I spent long time to understand what lead upstream to use the current code as the patch actually reverts it. The perl documentation regarding file handle globs and underlying file descriptors is very sparse. I did some tests and everything seems good with the patch, but I'd like somebody to review it. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=se2fKKFdEia=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1061114] perl-URI-Find-Simple-1.05 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1061114 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-URI-Find-Simple-1.05-1 ||.fc21 Resolution|--- |RAWHIDE Last Closed||2014-02-06 11:19:06 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Vazb3c3spSa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File URI-Title-1.88.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-URI-Title: ff54866adac948b0e5b0bb0736e70be0 URI-Title-1.88.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-URI-Title] 1.88 bugfix bump
commit 085c344eafcb3d807e552f4ca07c26f96430d56e
Author: Petr Šabata con...@redhat.com
Date: Thu Feb 6 17:55:35 2014 +0100
1.88 bugfix bump
.gitignore |1 +
URI-Title-1.86-live-tests.patch | 28
perl-URI-Title.spec | 11 ++-
sources |2 +-
4 files changed, 8 insertions(+), 34 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7b82a8e..1fc6ed6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/URI-Title-1.85.tar.gz
/URI-Title-1.86.tar.gz
+/URI-Title-1.88.tar.gz
diff --git a/perl-URI-Title.spec b/perl-URI-Title.spec
index 76d73dd..a19040e 100644
--- a/perl-URI-Title.spec
+++ b/perl-URI-Title.spec
@@ -1,13 +1,12 @@
Name: perl-URI-Title
-Version:1.86
-Release:7%{?dist}
+Version:1.88
+Release:1%{?dist}
Summary:Get the titles of things on the web in a sensible way
# Mentioned in URI::Title POD
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/URI-Title/
Source0:
http://www.cpan.org/authors/id/T/TO/TOMI/URI-Title-%{version}.tar.gz
-Patch0: URI-Title-1.86-live-tests.patch
BuildArch: noarch
BuildRequires: perl(base)
BuildRequires: perl(lib)
@@ -49,7 +48,6 @@ So, let's solve these issues once.
%prep
%setup -q -n URI-Title-%{version}
-%patch0 -p1
%build
perl Makefile.PL INSTALLDIRS=vendor
@@ -64,11 +62,14 @@ find %{buildroot} -type f -name .packlist -exec rm -f {} \;
make test
%files
-%doc Changes title.pl
+%doc Changes eg/title.pl
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Thu Feb 06 2014 Petr Šabata con...@redhat.com - 1.88-1
+- 1.88 bugfix bump
+
* Tue Jan 28 2014 Petr Šabata con...@redhat.com - 1.86-7
- Fix the live test failures (#1058734, rt#92091)
- Minor spec cleanup
diff --git a/sources b/sources
index 374..0c2987a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c3bf145bdc908c2b0ba8a596b82f2976 URI-Title-1.86.tar.gz
+ff54866adac948b0e5b0bb0736e70be0 URI-Title-1.88.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1061115] perl-URI-Title-1.88 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1061115 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-URI-Title-1.88-1.fc21 Resolution|--- |RAWHIDE Last Closed||2014-02-06 12:00:59 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=CKDU63xxita=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1062424] perl-Capture-Tiny: insecure temporary file usage
https://bugzilla.redhat.com/show_bug.cgi?id=1062424 Martin Prpic mpr...@redhat.com changed: What|Removed |Added CC||bgoll...@redhat.com, ||drie...@redhat.com, ||jples...@redhat.com, ||mmasl...@redhat.com, ||perl-devel@lists.fedoraproj ||ect.org, ||perl-maint-l...@redhat.com, ||pfrie...@redhat.com, ||psab...@redhat.com, ||tdaw...@redhat.com, ||tkra...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=gmLDteJ0Jra=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1062424] perl-Capture-Tiny: insecure temporary file usage
https://bugzilla.redhat.com/show_bug.cgi?id=1062424 Martin Prpic mpr...@redhat.com changed: What|Removed |Added Whiteboard|impact=low,public=20140206, |impact=low,public=20140206, |reported=20140206,source=os |reported=20140206,source=os |s-sec,cvss2=1.9/AV:L/AC:M/A |s-sec,cvss2=1.9/AV:L/AC:M/A |u:N/C:N/I:P/A:N,fedora-all/ |u:N/C:N/I:P/A:N,fedora-all/ |perl-Capture-Tiny=affected, |perl-Capture-Tiny=affected, |rhscl-1/perl-Capture-Tiny=a |rhscl-1/perl516-perl-Captur |ffected,rhel-7/perl-Capture |e-Tiny=affected,rhel-7/perl |-Tiny=affected |-Capture-Tiny=affected -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=J8SNHq3Vewa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
