Re: pulseaudio maintainership status
On 29 Dec 2012 01:48, Chris Murphy li...@colorremedies.com wrote: On Dec 28, 2012, at 12:25 PM, Peter Robinson pbrobin...@gmail.com wrote: On Fri, Dec 28, 2012 at 3:34 PM, Brendan Jones brendan.jones...@gmail.com wrote: On 12/28/2012 12:33 AM, Kevin Kofler wrote: Steve Clark wrote: Then why is no one fixing the identified bugs? Because Lennart insists on backporting only individual fixes to Fedora releases as opposed to rebasing to a new version, and nobody has the time to identify and backport the relevant commits. IMHO, we should just upgrade PulseAudio to the latest version in an update. Kevin Kofler I fully agree. The effort it takes too identify fixes is too large. Also, upstream will not be as amenable in helping us diagnose bugs when we are so behind. I don't agree. We're moments from release and the 3.0 release hasn't been out for that long and it's likely that while it might fix the one bug it could introduce any number of other bugs. Yeah, the F18 ship has sailed, we're way past freeze. In fact it needs to be in Rawhide soon enough to get into F19. Its already there if you bothered to check. It was there from rc3 with it being updated to 3.0 shortly after release. I think this was even mentioned in this thread. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20121229 changes
Compose started at Sat Dec 29 08:15:13 UTC 2012 Broken deps for x86_64 -- [dogtag-pki] dogtag-pki-10.0.0-0.16.b3.fc19.noarch requires dogtag-pki-server-theme = 0:10.0.0 [ember] ember-0.6.3-3.fc19.x86_64 requires libOgreMain.so.1.7.4()(64bit) [epiphany-extensions] epiphany-extensions-3.6.0-1.fc19.x86_64 requires epiphany(abi) = 0:3.6 [evolution-rss] 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libevolution-utils.so()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libemiscwidgets.so()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libemail-utils.so()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libedataserverui-3.0.so.5()(64bit) 1:evolution-rss-0.3.92-3.fc19.x86_64 requires libcamel-1.2.so.42()(64bit) [freeipa] freeipa-server-3.1.0-1.fc19.x86_64 requires dogtag-pki-server-theme [freewrl] freewrl-1.22.13.1-3.fc18.i686 requires libGLEW.so.1.7 freewrl-1.22.13.1-3.fc18.x86_64 requires libGLEW.so.1.7()(64bit) libEAI-1.22.13.1-3.fc18.i686 requires libGLEW.so.1.7 libEAI-1.22.13.1-3.fc18.x86_64 requires libGLEW.so.1.7()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [ghc-wai-extra] ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSzlib-conduit-0.4.0.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSzlib-bindings-0.1.0.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSzlib-0.5.3.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSwai-1.2.0.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSvoid-0.5.6-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSvault-0.2.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSunordered-containers-0.2.1.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSunix-2.5.1.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStransformers-base-0.4.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStransformers-0.3.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStime-1.4-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHStext-0.11.2.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSsemigroups-0.8.3.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSresourcet-0.3.2.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSparsec-3.1.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSold-time-1.1.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSold-locale-1.0.0.4-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSnetwork-2.3.0.13-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSmtl-2.1.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSmonad-control-0.3.1.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSlifted-base-0.1.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSinteger-gmp-0.4.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHShttp-types-0.6.11-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHShashable-1.1.2.3-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSghc-prim-0.2.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSfilepath-1.3.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSfast-logger-0.0.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSdlist-0.5-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSdirectory-1.1.0.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSdeepseq-1.3.0.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSdata-default-0.4.0-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHScontainers-0.4.2.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSconduit-0.4.2-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHScase-insensitive-0.4.0.1-ghc7.4.1.so()(64bit) ghc-wai-extra-1.2.0.4-4.fc18.x86_64 requires libHSbytestring-0.9.2.1-ghc7.4.1.so()(64bit)
package reviews: new Release for every update
I noticed our package review process doesn't explicitly say After you make an update to the package, bump the 'Release' number and post a new link each time. This is a popular convention, but it doesn't seem to be formally documented. https://fedoraproject.org/wiki/Package_Review_Process Should this guidance be part of our instructions? - Ken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-18 Branched report: 20121229 changes
Compose started at Sat Dec 29 09:16:24 UTC 2012 Summary: Added Packages: 0 Removed Packages: 0 Upgraded Packages: 0 Compose finished at Sat Dec 29 16:03:38 UTC 2012 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pulseaudio maintainership status
On 12/28/2012 08:25 PM, Peter Robinson wrote: On Fri, Dec 28, 2012 at 3:34 PM, Brendan Jones brendan.jones...@gmail.com wrote: On 12/28/2012 12:33 AM, Kevin Kofler wrote: Steve Clark wrote: Then why is no one fixing the identified bugs? Because Lennart insists on backporting only individual fixes to Fedora releases as opposed to rebasing to a new version, and nobody has the time to identify and backport the relevant commits. IMHO, we should just upgrade PulseAudio to the latest version in an update. Kevin Kofler I fully agree. The effort it takes too identify fixes is too large. Also, upstream will not be as amenable in helping us diagnose bugs when we are so behind. I don't agree. We're moments from release and the 3.0 release hasn't been out for that long and it's likely that while it might fix the one bug it could introduce any number of other bugs. I know upstream is moving really fast these days, but I thinbk any risk is alleviated by Rex's backport - we can safely identify any showstoppers within a fedora release cycle. There's a working backport patch for a platform that isn't really supported in Fedora and it works on other virtual platforms without issue. While I would love to see 3.0 in Fedora 18 due to it's support for UCM which is used extensively in ARM I'm not even pushing it because I know it could break more than it might well fix. 1.1 for F17 is way to far behind IMHO given that upstream is now at 3.0. Why? it works and is relatively stable, there's a lot of change between 1.1, 2.0, 2.1 and 3.0 which could introduce any number of other bugs and regressions in a release that is suppose to be stable. Why? Upstream is now really active - insisting that they support software 2 major releases old is a bit much. If enough people are using rawhide and/or Rex's backport we should be able to keep close to upstream without risk. I think restricting ourselves to upstream major releases within the Fedora release cycle _becomes_ risky when we are so behind. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pulseaudio maintainership status
On 12/28/2012 08:25 PM, Peter Robinson wrote: On Fri, Dec 28, 2012 at 3:34 PM, Brendan Jones brendan.jones...@gmail.com wrote: On 12/28/2012 12:33 AM, Kevin Kofler wrote: Steve Clark wrote: Then why is no one fixing the identified bugs? Because Lennart insists on backporting only individual fixes to Fedora releases as opposed to rebasing to a new version, and nobody has the time to identify and backport the relevant commits. IMHO, we should just upgrade PulseAudio to the latest version in an update. Kevin Kofler I fully agree. The effort it takes too identify fixes is too large. Also, upstream will not be as amenable in helping us diagnose bugs when we are so behind. I don't agree. We're moments from release and the 3.0 release hasn't been out for that long and it's likely that while it might fix the one bug it could introduce any number of other bugs. I'm not suggesting we upgrade F18 now, but I think we should be open to the idea post release, and even for F17. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package reviews: new Release for every update
On 2012-12-29 17:01, Ken Dreyer wrote: I noticed our package review process doesn't explicitly say After you make an update to the package, bump the 'Release' number and post a new link each time. This is a popular convention, but it doesn't seem to be formally documented. https://fedoraproject.org/wiki/Package_Review_Process Should this guidance be part of our instructions? - Ken The GL nowadays allows updating of the spec without a release bump as long as nothing is released [1]. However, the changelog should still be updated one way or another. Also, in many cases the same link is reused, at least for the spec. I see nothing wrong in that That said, what's the problem you want to solve here? --alec [1] http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package reviews: new Release for every update
Alec Leamas: On 2012-12-29 17:01, Ken Dreyer wrote: I noticed our package review process doesn't explicitly say After you make an update to the package, bump the 'Release' number and post a new link each time. This is a popular convention, but it doesn't seem to be formally documented. https://fedoraproject.org/wiki/Package_Review_Process Should this guidance be part of our instructions? - Ken The GL nowadays allows updating of the spec without a release bump as long as nothing is released [1]. However, the changelog should still be updated one way or another. Also, in many cases the same link is reused, at least for the spec. I see nothing wrong in that That said, what's the problem you want to solve here? --alec Being able to track changes is very useful. I've seen on a few occasions reviewers mention that they can't tell what has changed in the spec since the previous version, as the new packager has overwritten the previous spec. I've also seen reviewers ask the new packager to document changes in the changelog as they go along, even before release, as it's quite helpful for both packager and reviewer. -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package reviews: new Release for every update
On Sat, 29 Dec 2012 18:23:35 +, Jamie Nguyen wrote: I've seen on a few occasions reviewers mention that they can't tell what has changed in the spec since the previous version, as the new packager has overwritten the previous spec. If the packager does that, it makes the rpmdev-diff command less useful, The src.rpm file name should be different for each new update to the spec file. I've also seen reviewers ask the new packager to document changes in the changelog as they go along, even before release, as it's quite helpful for both packager and reviewer. It's common practice to document spec changes in the %changelog. Packagers, who don't do that during review, often don't know yet how helpful the changelog can be when running into packaging issues later. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package reviews: new Release for every update
On 2012-12-29 19:45, Michael Schwendt wrote: On Sat, 29 Dec 2012 18:23:35 +, Jamie Nguyen wrote: I've seen on a few occasions reviewers mention that they can't tell what has changed in the spec since the previous version, as the new packager has overwritten the previous spec. If the packager does that, it makes the rpmdev-diff command less useful, The src.rpm file name should be different for each new update to the spec file. Mixed feelings... Although the purpose and benefits of this is obvious: - If we cannot applyt the new changleog GL with changes without version bump in a review process, when should they then be applicable?! - But without version bump, the srpm file will get the same name. And both srpm and spec have more or less fixed names for a given package and e-v-r. - the only really consistent scheme is using a directory for each change. Certainly doable but given all the obstacles specially new submitters meet, this might be to much? These things would perhaps be much easier if there was a better infrastructurekeeping the intital links as-is, but with a place handling the process once the ticket is assigned?! I've also seen reviewers ask the new packager to document changes in the changelog as they go along, even before release, as it's quite helpful for both packager and reviewer. It's common practice to document spec changes in the %changelog. Packagers, who don't do that during review, often don't know yet how helpful the changelog can be when running into packaging issues later. It might perhaps be helpful to add a note to the review process that a change in the spec+srpm should be treated as a 'change' in the changelog GL sense?! I'm a bit surprised I cannot find anything like that, thought we all did so :) Just my 5c... --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
texlua running for 8+ hours using 5GB of ram on yum update? (texlive-context-bin bug?)
My yum update on f18 took about 20 minutes installing 3380 packages. Cleanup: bash-4.2.39-1.fc18.x86_64 3377/3380 Cleanup: nss-softokn-freebl-3.14-5.fc18 3378/3380 Cleanup: glibc-2.16-24.fc18 3379/3380 Cleanup: tzdata-2012i-1.fc18.noarch 3380/3380 And then it just sat there and sat there.. Cpu(s): 1.7 us, 1.9 sy, 0.0 ni, 86.8 id, 9.2 wa, 0.2 hi, 0.2 si, 0.0 st KiB Mem: 16412252 total, 16259348 used, 152904 free, 2064256 buffers KiB Swap: 16777212 total, 1289788 used, 15487424 free, 1120880 cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 8268 root 20 0 5024m 4.8g 2688 R 22.5 30.5 7:51.49 texlua 2738 paul 20 0 2203m 359m 31m S 2.6 2.2 40:48.75 gnome-shell 79 root 20 0 000 S 1.0 0.0 1:47.27 kswapd0 $ ps auxw|grep texlua root 8268 37.5 32.7 5515148 5369112 pts/2 D+ 18:56 8:30 texlua /usr/bin/mtxrun --generate $ rpm -qf /usr/bin/mtxrun texlive-context-bin-2012-0.svn26861.10.20121205_r28449.fc18.noarch What is this? The man page hints of pdf generations. Why is this happening? Why is it taking 8+ hours? Why is it taking 5GB of RES RAM? These are several bugs that should be addressed. Endusers will not wait 8+ hours, so right now whoever owns this can be sure it will just get killed by impatient people. Some people won't have 5GB for this. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package reviews: new Release for every update
On Sat, 29 Dec 2012 20:20:25 +0100, Alec Leamas wrote: On 2012-12-29 19:45, Michael Schwendt wrote: On Sat, 29 Dec 2012 18:23:35 +, Jamie Nguyen wrote: I've seen on a few occasions reviewers mention that they can't tell what has changed in the spec since the previous version, as the new packager has overwritten the previous spec. If the packager does that, it makes the rpmdev-diff command less useful, The src.rpm file name should be different for each new update to the spec file. Mixed feelings... Although the purpose and benefits of this is obvious: - If we cannot applyt the new changleog GL with changes without version bump in a review process, when should they then be applicable?! Offering a src.rpm for review is very similar to releasing it in koji. Once built in koji, the NEVR is occupied and blocked, so future builds must bump R, at least. During review, you offer a release of a src.rpm. If it needs to be changed in any way, it becomes necessary to release an update to the src.rpm. For updates, especially those that don't fail to build, one typically bumps R at least, or else you couldn't simply update to the builds (because you would need to _reinstall_/replace an already installed package. If the packager modifies a src.rpm, the guidelines ask that a changelog entry is to be added. http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs The wording isn't fully safe. It's not a strict you must add a changelog entry any time you change the spec file or anything like that. Personally, I consider it okay if a package submitter doesn't bump R as long as %changelog entries are added. It's easy enough to append a number to downloaded srpms, so they could be diffed conveniently. It's also pretty much okay to flush/delete the changelog entries for the approved src.rpm prior to git import, and to reset R to 1. It depends on what has been changed during review and what could be important to keep in the changelog. - But without version bump, the srpm file will get the same name. And both srpm and spec have more or less fixed names for a given package and e-v-r. - the only really consistent scheme is using a directory for each change. Certainly doable but given all the obstacles specially new submitters meet, this might be to much? I don't think it's too much of a requirement for new packagers to upload new src.rpms and announce the new link in a comment. The spec download may stay the same for quick/convenient access (and because there is not version in its file name, of course). It might perhaps be helpful to add a note to the review process that a change in the spec+srpm should be treated as a 'change' in the changelog GL sense?! I'm a bit surprised I cannot find anything like that, thought we all did so :) It depends. Not everything needs to be documented painstakingly. It's not worth the effort. During review it's merely a matter of practising changelog maintenance. Also, I dunno how many package submitters don't maintain their changelogs during review or simply are too lazy to do that, but would do it for future updates in the Fedora package collection. If we try to force package submitters to add changelog entries during review, that will likely lead to many irrelevant entries, such as fixed summary, or lack of details, such as fixed license, with the reviewer having to comment on that, too. That could get tiresome. Packagers only need to be aware of the %changelog and apply common sense. ;) -- Fedora release 18 (Spherical Cow) - Linux 3.6.11-3.fc18.x86_64 loadavg: 0.30 0.23 0.23 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: texlua running for 8+ hours using 5GB of ram on yum update? (texlive-context-bin bug?)
On 12/29/2012 07:24 PM, Paul Wouters wrote: My yum update on f18 took about 20 minutes installing 3380 packages. Cleanup: bash-4.2.39-1.fc18.x86_64 3377/3380 Cleanup: nss-softokn-freebl-3.14-5.fc18 3378/3380 Cleanup: glibc-2.16-24.fc18 3379/3380 Cleanup: tzdata-2012i-1.fc18.noarch 3380/3380 And then it just sat there and sat there.. Cpu(s): 1.7 us, 1.9 sy, 0.0 ni, 86.8 id, 9.2 wa, 0.2 hi, 0.2 si, 0.0 st KiB Mem: 16412252 total, 16259348 used, 152904 free, 2064256 buffers KiB Swap: 16777212 total, 1289788 used, 15487424 free, 1120880 cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 8268 root 20 0 5024m 4.8g 2688 R 22.5 30.5 7:51.49 texlua 2738 paul 20 0 2203m 359m 31m S 2.6 2.2 40:48.75 gnome-shell 79 root 20 0 000 S 1.0 0.0 1:47.27 kswapd0 $ ps auxw|grep texlua root 8268 37.5 32.7 5515148 5369112 pts/2 D+ 18:56 8:30 texlua /usr/bin/mtxrun --generate $ rpm -qf /usr/bin/mtxrun texlive-context-bin-2012-0.svn26861.10.20121205_r28449.fc18.noarch What is this? The man page hints of pdf generations. Why is this happening? Why is it taking 8+ hours? Why is it taking 5GB of RES RAM? These are several bugs that should be addressed. Endusers will not wait 8+ hours, so right now whoever owns this can be sure it will just get killed by impatient people. Some people won't have 5GB for this. I'm just guessing in the dark here, but it is probably being invoked from a scriptlet. Look through all the packages that got touched in that transaction and see if any of them have scriplets that might have invoked texlua/mxtrun directly (or indirectly). ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FYI: Fedora 3.6.10-4.fc18 hanging on startup on VM Player
Hi, Hope this is not noise... Just installed Fedora 3.6.10-4.fc18 32 bit on 32 bit VM Player on 64 bit Windows 8 machine and it hangs on the blue background. Will try 64 bit VM Player tomorrow. Aaron -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI: Fedora 3.6.10-4.fc18 hanging on startup on VM Player - VirtualBox works okay though
On 30 December 2012 03:39, Aaron Gray aaronngray.li...@gmail.com wrote: Hi, Hope this is not noise... Just installed Fedora 3.6.10-4.fc18 32 bit on 32 bit VM Player on 64 bit Windows 8 machine and it hangs on the blue background. Will try 64 bit VM Player tomorrow. There was no 64 bit version of VMware player. VirtualBox seems to work fine so far. Aaron Aaron -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 890734] New: client denied by server configuration: /usr/share/rt3/html
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=890734 Bug ID: 890734 Summary: client denied by server configuration: /usr/share/rt3/html Product: Fedora Version: 18 Component: rt3 Severity: urgent Priority: unspecified Reporter: rc040...@freenet.de Description of problem: Apache-2.4's breaks authentication in /etc/httpd/conf.d/rt3.conf Symptoms: * Error messages similar to this in /var/log/httpd/error_log: [Sat Dec 29 07:40:47.542895 2012] [authz_core:error] [pid 2143] [client 192.168.1.104:46910] AH01630: client denied by server configuration: /usr/share/rt3/html * Error messages in rt3's Web GUI. Version-Release number of selected component (if applicable): All RH/Fedora versions with Apache-2.4 (currently F18 and rawhide). How reproducible: Always. -- 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=QPkqH082cAa=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 890736] New: perl-Net-DNS-0.72 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=890736 Bug ID: 890736 Summary: perl-Net-DNS-0.72 is available Product: Fedora Version: rawhide Component: perl-Net-DNS Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Reporter: upstream-release-monitor...@fedoraproject.org Latest upstream release: 0.72 Current version in Fedora Rawhide: 0.71 URL: http://search.cpan.org/dist/Net-DNS/ 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=PDAMpWR5Nxa=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
[rt3] Add mod_authz_core.c support to rt3.conf.
commit 1b22e908e2fdc142365ac3b972482aa34346fb46
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Sat Dec 29 14:41:17 2012 +0100
Add mod_authz_core.c support to rt3.conf.
rt3.conf.in |9 -
rt3.spec|5 -
2 files changed, 12 insertions(+), 2 deletions(-)
---
diff --git a/rt3.conf.in b/rt3.conf.in
index 27a4600..a6f0129 100644
--- a/rt3.conf.in
+++ b/rt3.conf.in
@@ -3,8 +3,15 @@ Alias /rt3 @RT3_WWWDIR@
PerlRequire @RT3_BINDIR@/webmux.pl
Directory @RT3_WWWDIR@
- AllowOverride All
Options ExecCGI FollowSymLinks
+ IfModule mod_authz_core.c
+# Apache 2.4
+Require all granted
+ /IfModule
+ IfModule !mod_authz_core.c
+# Apache 2.2
+AllowOverride All
+ /IfModule
RewriteEngine On
RedirectMatch permanent (.*)/$ $1/index.html
diff --git a/rt3.spec b/rt3.spec
index 0aedb2d..c9320b5 100644
--- a/rt3.spec
+++ b/rt3.spec
@@ -41,7 +41,7 @@
Name: rt3
Version: 3.8.15
-Release: 2%{?dist}
+Release: 3%{?dist}
Summary: Request tracker 3
Group: Applications/Internet
@@ -513,6 +513,9 @@ fi
%endif
%changelog
+* Sat Dec 29 2012 Ralf Corsépius corse...@fedoraproject.org - 3.8.15-3
+- Add mod_authz_core.c support to rt3.conf.
+
* Sat Dec 22 2012 Ralf Corsépius corse...@fedoraproject.org - 3.8.15-2
- Update README.fedora to use systemctl instead of /sbin/service.
- Rework man-page processing.
--
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
[rt3/f18] Add mod_authz_core.c support to rt3.conf.
Summary of changes: 1b22e90... Add mod_authz_core.c support to rt3.conf. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DateTime-Format-Mail] gzip the sample dates file in documentation (rhbz#890441)
commit 0062c9e1dd523205c08d860ca71215b4b637b0db
Author: Iain Arnell iarn...@gmail.com
Date: Sat Dec 29 09:16:27 2012 -0700
gzip the sample dates file in documentation (rhbz#890441)
perl-DateTime-Format-Mail.spec | 24 +++-
1 files changed, 11 insertions(+), 13 deletions(-)
---
diff --git a/perl-DateTime-Format-Mail.spec b/perl-DateTime-Format-Mail.spec
index 55c228a..d08cc8b 100644
--- a/perl-DateTime-Format-Mail.spec
+++ b/perl-DateTime-Format-Mail.spec
@@ -1,13 +1,12 @@
Name: perl-DateTime-Format-Mail
-Version:0.3001
-Release:15%{?dist}
+Version:0.3001
+Release:16%{?dist}
Summary:Convert between DateTime and RFC2822/822 formats
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/DateTime-Format-Mail
Source0:
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/DateTime-Format-Mail-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(Class::ISA)
@@ -40,6 +39,8 @@ people still get it wrong. This module aims to correct that.
%prep
%setup -q -n DateTime-Format-Mail-%{version}
+gzip -c t/sample_dates t/sample_dates.gz
+
# POD doesn't like Ecopy very much...
perl -pi -e 's/Ecopy/(C)/' `find lib/ -type f`
@@ -52,11 +53,9 @@ make %{?_smp_mflags}
mv LICENCE LICENSE
%install
-rm -rf %{buildroot}
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
+make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
-find %{buildroot} -type d -depth -exec rmdir {} 2/dev/null ';'
-chmod -R u+w %{buildroot}/*
+%{_fixperms} %{buildroot}/*
%check
@@ -66,19 +65,18 @@ rm t/00signature.t
make test
-%clean
-rm -rf %{buildroot}
-
-
%files
-%defattr(-,root,root,-)
%doc Artistic COPYING LICENSE Changes AUTHORS README CREDITS
-%doc t/sample_dates t/invalid.t
+%doc t/sample_dates.gz t/invalid.t
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
+* Sat Dec 29 2012 Iain Arnell iarn...@gmail.com 0.3001-16
+- gzip the sample dates file in documentation (rhbz#890441)
+- update spec for modern rpmbuild
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.3001-15
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
--
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 890441] Compress sample_dates
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=890441 Iain Arnell iarn...@gmail.com changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Last Closed||2012-12-29 11:44:01 --- Comment #1 from Iain Arnell iarn...@gmail.com --- Agreed. sample_dates file is now compressed in 0.3001-16. Built for rawhide only. -- 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=D3EMMIiPuEa=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 890734] client denied by server configuration: /usr/share/rt3/html
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=890734 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- rt3-3.8.15-3.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/rt3-3.8.15-3.fc18 -- 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=5Yc8mV8FW4a=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
Broken dependencies: perl-Authen-Simple
perl-Authen-Simple has broken dependencies in the epel-6 tree: On ppc64: perl-Authen-Simple-0.4-5.el6.noarch requires perl(Crypt::PasswdMD5) 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-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 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
