Re: Bug reporting URL field in packages
On Tue, 6 Oct 2009, Jon Masters wrote:
On Tue, 2009-10-06 at 10:43 -0700, Jesse Keating wrote:
So I guess the real question is do we want our packages built in koji to
assume a bug URL of fedora, even when used in downstream projects?
I think that's a giant assumption - if the maintainer didn't put that
URL in the package themselves, what makes you think automatically
putting it in there is going to achieve anything different? ;)
I advocate letting people choose for themselves.
Well, there's no semantics attached to the bugurl tag so it's up to distro
policies what to use it for: distro bugtracker or upstream bugtracker for
that package.
One option that would allow remapping the bug address to whatever
local configuration says would be leaving part of the bugurl tag as an
unexpanded macro, so our buildsys would define bugurl like this:
%bugurl %%{_bugurl_os}/%{name}
With that, the %{name} part is expanded at build time to effectively the
source rpm name, and the rest is up to query-time expansion. The extension
could return empty if the macro expansion fails (ie when _bugurl_os isn't
defined). Something like fedora-release could provide the %_bugurl_os
definition by default, and downstream distros, IT admins etc could
override it to whatever appropriate. It also permits controlling the
bugurl for packages from different sources like 3rd party repositories.
And changing the bug tracker base address doesn't require mass-rebuild.
That's trivial to implement, but would that be sufficient to cover the
concerns over arbitrary downstream distros pointing to Fedora bugtracker
etc, or should I just let it be?
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Retiring ksensors, possibly id3lib as well?
2009/10/8 Kevin Kofler kevin.kof...@chello.at: Lyos Gemini Norezel wrote: However... have you considered trying gnome-applet-sensors? gnome-applet-* doesn't work under KDE, that stuff only works in gnome-panel. It seems odd to continue such a package despite upstream being defunct. As I no longer use ksensors, if you wish to maintain this package... I will happily surrender maintainership to you. I picked it up, thanks! Thanks Kevin, i use it here as well. -- LG Thomas Dubium sapientiae initium -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: TeXLive 2009 autoprovides/autorequires
On Mon, Oct 05, 2009 at 01:20:02AM -0400, Ben Boeckel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I upgraded to F12 recently and enabled the TeXLive 2009 packages. One thing that the massive split has created is that package dependencies are not made at all. I had to manually install some packages to satisfy some dependencies. I created these (rudimentary) .prov and .req scripts (attached) to try and kickstart something. The upstream metadata do indeed contain incomplete dependecy information. I'm not sure how upstream generates the metadata but it makes sense to add dependencies present in STY files to the packages. I'm not fan of adding a new texlive.prov/req to rpm. It is indeed a general solution but it needs direct hacks and maintenance at rpm side. We can take advantage of the fact that we actually have the whole TeX distribution when packaging TeX Live so that I would rather implement the STY dependency calculator to the TL package generator. Maybe a good name for such deps would be tex-sty(foo) in order to distinguish style dependencies from the others. As they are, they don't do versioning yet (seems that some packages do versioning with LaTeX commands) nor does it support \RequirePackage being split over multiple lines (similar with \ProvidesPackage). I also may not be handling all of the possibilities of where the provides and requires information may be in the files. The versioning is tricky here as the description in the STY files is available only in textual form with intention to parse it by brain and not by script :) Jindrich - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJKyYICAAoJEKaxavVX4C1XnjgQAOuvMB9WMhtkzN7h+IjHcRu2 u4WFJRLVB4J/8zpPz/mxFbGIbeeJSjaUde+7oRuz2RV1jD9bC4P3sP4bRQN77Xrc ffC1lOI1X6S3+AQt/nUonJnmG0/vqdeILWp/AulBNngpzb7w50Kj3iWGg+Zws5gy tTDBCp9dZJNkXylqI6UNjduMghvI41p2md2l7cd1gzudmXvLWaZMDFBQ81OZJt1g RE5JBi7+1OkNfINEjShKg+o/SlllZvT4u5erHWy7Fb/rOUGPX7qbj9ZqwZaQNWqU Dpr/8TSrXmsiuKk7tr+jL+GAtdB+fx18ZDV4E3umvmqzG+0KzIj6WmuW/DEyotRs qdqryzxSeZwtTjScBHAQG+TWlkm9X24hjnKnbyqIRvT81hawxPI/e6RAXTuuDUl8 R+53le3RG6/mMy7MDD6Aky1h37R+4uIpmNpIb7JaNHhtfRanROxUw1Ii1Fjh5d45 qA8i2pWaHPRC3OEMhaIgTFO1yHSWC5uLZ75K0owWKVQzo/UqFNAJwlGdIefM4YHD mSGesiawXEMAK0Ggfy2YxcNYPfhErk6cy7vGS/TlQhouO6utJVkc/a4sjmZj7rlb 3EvpRn3M/YGqeWg9536I8L9ugVFDnEwq958DRznB0FKCVpycnph1zMofGviLkrVv vjL/wtA8bfitn/xgR24o =8Hkv -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Jindrich Novy jn...@redhat.com http://people.redhat.com/jnovy/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Retiring gai, gai-temp, gai-pal
The current thread on ksensors, id3lib has reminded me to give gnome-applet-sensors another try right now. In F11. It works for me while that hasn't been true before (troubles with acpi thrm or no sensors). As a result, I'd like to retire GAI (General Applet Interface Library) and two of the applets that are in the Fedora Package Collection: gai-temp gai-pal gai There has not been any new release since 2005. Several patches have been mailed upstream, but later without any response. No other GAI applets have ever been included in the Fedora Package Collection. I plan to keep the packages only for F-11 and F-10, but not for F-12 and newer. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Easy review swap
https://bugzilla.redhat.com/show_bug.cgi?id=527971 OCaml framework for Functional Reactive Programming (FRP) The whole library is a single file, it's rpmlint clean, and there's a Koji scratch build. I'll swap for a similarly easy review. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Thu, Oct 08, 2009 at 10:54:54 +0100, Terry Barnaby ter...@beam.ltd.uk wrote: Are you confident that F12 will make 3D usable under Linux on the majority of mainstream graphics cards ? It's not going to provide 3d for nvidia, though it is hoped that nouveau will be somewhat improved. Intel and all much of ATI (through at least r600 series) is supposed to get working 3d with kernel mode setting. Due to the range of graphics hardware and the differences between them, I would have thought that a significant amount of user testing and bug fixing would need to be done to achieve this. I tried the F12 ATI graphics testing day and although a good idea the 3D tests were very limited and due to the amount of effort a user has to put in I guess limited in scope. Although people, myself included, feed back bugs upstream into the freedesktop GIT repository I would have thought that a larger audience was required ... So you'd prefer to force F11 users to do testing whether they want to or not? I would have thought that more people would be likely to try out the graphics updates if it is easy for them to install on their running systems and use in their normal usage patterns rather than have to maintain a separate test system just to test and feed back issues ... It isn't going to be simple to do this. With the modesetting changes there are a lot of interactions between parts and you need to change a number of things (X, mesa, drm, kernel) at once to have a working system. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On 10/08/2009 01:51 PM, Bruno Wolff III wrote: On Thu, Oct 08, 2009 at 10:54:54 +0100, Terry Barnabyter...@beam.ltd.uk wrote: Are you confident that F12 will make 3D usable under Linux on the majority of mainstream graphics cards ? It's not going to provide 3d for nvidia, though it is hoped that nouveau will be somewhat improved. Intel and all much of ATI (through at least r600 series) is supposed to get working 3d with kernel mode setting. Due to the range of graphics hardware and the differences between them, I would have thought that a significant amount of user testing and bug fixing would need to be done to achieve this. I tried the F12 ATI graphics testing day and although a good idea the 3D tests were very limited and due to the amount of effort a user has to put in I guess limited in scope. Although people, myself included, feed back bugs upstream into the freedesktop GIT repository I would have thought that a larger audience was required ... So you'd prefer to force F11 users to do testing whether they want to or not? No, I don't what to force testing on anyone (although F11 has done that already :) ) I was just suggesting that a separate yum archive with the packages necessary to test the later graphics development code that will be in F12 could be made available for people to try out easily with their F11 systems. They can optionally try these. I think it will allow 3D to work for many people (from my experience of the latest GIT versions) although others would not be so lucky. They can easily back these changes out if they have more issues than the standard graphics system. I would have thought that more people would be likely to try out the graphics updates if it is easy for them to install on their running systems and use in their normal usage patterns rather than have to maintain a separate test system just to test and feed back issues ... It isn't going to be simple to do this. With the modesetting changes there are a lot of interactions between parts and you need to change a number of things (X, mesa, drm, kernel) at once to have a working system. Yes, there are quite a few changes, that is why it is difficult for people to test the changes ... Although I would have though that for the most part it would be just building the appropriate set of the F12 packages for F11. Ah well, I will probably have to wait for F12 or F13 before I can truly move from F8 :( -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Package updates not replaced by newer package in -testing
A few days ago, I built deltarpm-3.4-18.fc11 which resplit off a subpackage that had accidentally been merged into the main package in deltarpm-3.4-17.fc11. I pushed -18 into -testing, and assumed (since it was newer than -17) that -17 wouldn't get pushed to stable automatically. Now I've just received an email from koji saying that -17 has been pushed to updates from updates-testing. I've just pushed -18 into updates, but is there any way to avoid a one or two day delay where -17 makes it into updates before -18 does? Jonathan signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Package updates not replaced by newer package in -testing
2009/10/8 Jonathan Dieter jdie...@gmail.com: A few days ago, I built deltarpm-3.4-18.fc11 which resplit off a subpackage that had accidentally been merged into the main package in deltarpm-3.4-17.fc11. I pushed -18 into -testing, and assumed (since it was newer than -17) that -17 wouldn't get pushed to stable automatically. Now I've just received an email from koji saying that -17 has been pushed to updates from updates-testing. I've just pushed -18 into updates, but is there any way to avoid a one or two day delay where -17 makes it into updates before -18 does? How was it automatic pushed to stable? Automatic karma push? Disable that then. Or unpush it. That's all *i* know. -- LG Thomas Dubium sapientiae initium -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Thu, 2009-10-08 at 10:54 +0100, Terry Barnaby wrote: I would have thought that more people would be likely to try out the graphics updates if it is easy for them to install on their running systems and use in their normal usage patterns rather than have to maintain a separate test system just to test and feed back issues ... This is why live images are useful. Boot the live image, do some of your normal work, throw it away when done and don't disrupt your already installed OS. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Thu, 2009-10-08 at 11:29 +0300, Panu Matilainen wrote:
With that, the %{name} part is expanded at build time to effectively the
source rpm name, and the rest is up to query-time expansion. The extension
could return empty if the macro expansion fails (ie when _bugurl_os isn't
defined). Something like fedora-release could provide the %_bugurl_os
definition by default, and downstream distros, IT admins etc could
override it to whatever appropriate. It also permits controlling the
bugurl for packages from different sources like 3rd party repositories.
And changing the bug tracker base address doesn't require mass-rebuild.
That's trivial to implement, but would that be sufficient to cover the
concerns over arbitrary downstream distros pointing to Fedora bugtracker
etc, or should I just let it be?
Hrm, how does it help for 3rd party packages? They would hardcode the
entire string into their rpms?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
signature.asc
Description: This is a digitally signed message part
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091008 changes
Compose started at Thu Oct 8 06:15:12 UTC 2009 Broken deps for ppc64 -- python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot Removed package compat-wxGTK26 Updated Packages: GConf2-2.28.0-2.fc12 * Wed Oct 07 2009 Matthias Clasen mcla...@redhat.com - 2.28.0-2 - Fix a problem with schema translations aria2-1.6.1-1.fc12 -- * Thu Oct 08 2009 Rahul Sundaram sunda...@fedoraproject.org - 1.6.1-1 - Fixes memory leak in HTTP/FTP downloads and other minor bug fixes - http://aria2.svn.sourceforge.net/viewvc/aria2/trunk/NEWS?revision=1569 bognor-regis-0.4.10-3.fc12 -- * Wed Oct 07 2009 Peter Robinson pbrobin...@gmail.com 0.4.10-3 - Add upstream patch to fix a crash brasero-2.28.1-2.fc12 - * Wed Oct 07 2009 Bastien Nocera bnoc...@redhat.com 2.28.1-2 - Fix command-line parsing (#527484) dbus-1.2.16-8.fc12 -- * Wed Oct 07 2009 Matthias Clasen mcla...@redhat.com - 1:1.2.16-7 - Add missing diagrams to the docs (#527650) * Wed Oct 07 2009 Matthias Clasen mcla...@redhat.com - 1:1.2.16-8 - Drop capabilities (#518541) evolution-2.28.0-2.fc12 --- * Fri Oct 02 2009 Matthew Barnes mbar...@redhat.com - 2.28.0-2.fc12 - Tweak desktop file for GNOME Shell. glib2-2.22.2-1.fc12 --- * Wed Oct 07 2009 Matthias Clasen mcla...@redhat.com - 2.22.2-1 - Update to 2.22.2 gnome-media-2.28.1-1.fc12 - * Wed Oct 07 2009 Bastien Nocera bnoc...@redhat.com 2.28.1-1 - Update to 2.28.1 gnome-panel-2.28.0-2.fc12 - * Wed Oct 07 2009 Matthias Clasen mcla...@redhat.com 2.28.0-2 - Add a default location to the clock applet gupnp-0.13.1-1.fc12 --- * Wed Oct 07 2009 Peter Robinson pbrobin...@gmail.com 0.13.1-1 - Update to 0.13.1 moblin-gtk-engine-1.0.2-1.fc12 -- * Wed Oct 07 2009 Peter Robinson pbrobin...@gmail.com 1.0.2-1 - New upstream 1.0.2 release moblin-panel-myzone-0.0.7-1.fc12 * Wed Oct 07 2009 Peter Robinson pbrobin...@gmail.com 0.0.7-1 - New upstream 0.0.7 release moblin-session-0.12-6.fc12 -- * Wed Oct 07 2009 Peter Robinson pbrobin...@gmail.com 0.12-6 - Shorten desktop name to plain Moblin mojito-0.21.2-1.fc12 * Fri Oct 02 2009 Peter Robinson pbrobin...@gmail.com 0.21.2-1 - Update to 0.21.2 mutter-2.28.0-2.fc12 * Wed Oct 07 2009 Owen Taylor otay...@redhat.com - 2.28.0-1 - Update to 2.28.0 openldap-2.4.18-5.fc12 -- * Wed Oct 07 2009 Jan Zeleny jzel...@redhat.com 2.4.18-5 - updated smbk5pwd patch to be linked with libldap (#526500) * Wed Sep 30 2009 Jan Zeleny jzel...@redhat.com 2.4.18-4 - buffer overflow patch from upstream - added /etc/openldap/slapd.d and /etc/openldap/slapd.conf.bak to files owned by openldap-servers plymouth-0.8.0-0.2009.29.09.6.fc12 -- * Wed Oct 07 2009 Ray Strode rstr...@redhat.com 0.8.0-0.2009.29.09.5 - Prevent firstboot's X from crashing on radeon hardware. This should only affect multihead users, but for some reason it's getting some single head users as well. * Wed Oct 07 2009 Ray Strode rstr...@redhat.com 0.8.0-0.2009.29.09.6 - Fix the reason radeon single head users were affected. * Tue Oct 06 2009 Ray Strode rstr...@redhat.com 0.8.0-0.2009.29.09.4 - Prevent firstboot's X from crashing on intel hardware polkit-gnome-0.95-0.git20090913.6.fc12 -- * Wed Oct 07 2009 Matthias Clasen mcla...@redhat.com - 0.95.0.git20090913.6 - Prevent the statusicon from eating whitespace rhythmbox-0.12.5-5.fc12 --- * Wed Oct 07 2009 Bastien Nocera bnoc...@redhat.com 0.12.5-5 - Remove work-around for brasero bug rubygem-actionmailer-2.3.4-2.fc12 - * Wed Oct 07 2009 David Lutterkort lut...@redhat.com - 1:2.3.4-2 - Bump Epoch to ensure upgrade path from F-11 rubygem-actionpack-2.3.4-2.fc12 --- * Wed Oct 07 2009 David Lutterkort lut...@redhat.com - 1:2.3.4-2 - Bump Epoch to ensure upgrade path from F-11 rubygem-activerecord-2.3.4-2.fc12 - * Wed Oct 07 2009 David Lutterkort lut...@redhat.com - 1:2.3.4-2 - Bump Epoch to ensure upgrade path from F-11 rubygem-activeresource-2.3.4-2.fc12 --- * Wed Oct 07 2009 David Lutterkort lut...@redhat.com - 1:2.3.4-2 - Bump Epoch to ensure upgrade path from F-11 rubygem-activesupport-2.3.4-2.fc12 -- * Wed Oct 07 2009 David Lutterkort lut...@redhat.com - 1:2.3.4-2 - Bump Epoch to ensure upgrade path from F-11 rubygem-rails-2.3.4-2.fc12 -- * Wed Oct 07 2009 David Lutterkort lut...@redhat.com - 1:2.3.4-2 - Bump Epoch to ensure upgrade path from F-11
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Thu, 2009-10-08 at 14:05 +0100, Terry Barnaby wrote: No, I don't what to force testing on anyone (although F11 has done that already :) ) I was just suggesting that a separate yum archive with the packages necessary to test the later graphics development code that will be in F12 could be made available for people to try out easily with their F11 systems. They can optionally try these. I think it will allow 3D to work for many people (from my experience of the latest GIT versions) although others would not be so lucky. They can easily back these changes out if they have more issues than the standard graphics system. Then please feel free to make one. :) I don't mean that in a snide fashion, but it really is the answer. As noted, having our X.org developers spend time on such a repository directly subtracts that amount of time from the time they would otherwise spend actually developing the drivers (our X.org maintainers are also major upstream developers) and fixing reported bugs. Given that there is a lot of development work to do on these drivers (which is why you find the newer versions better...) and a lot of bugs to fix (we generally barely keep up with the rate of bugs filed as it is), we don't see that as a good trade-off. You'd get backported drivers for stable releases, but the rate of development of the actual upstream drivers would be noticeably slowed, and fewer reported bugs would ultimately get fixed. Backporting packages is not intrinsically very difficult, though it is somewhat time-consuming, so it's something for which a far greater candidate pool exists than X driver development. Thus, the suggestion that someone else do it. For instance, you. It seems you've already successfully built the latest versions of things locally; if you can do that, you can put them in a package and put the package in a repository, it's not a very hard process and it's all documented on the Wiki. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Package updates not replaced by newer package in -testing
On Thu, 2009-10-08 at 07:44 -0700, Toshio Kuratomi wrote: This is partially my fault -- my network connection hasn't been good for the last day so instead of clearing with you which Fedora releases had the new package, I just looked quickly at bodhi and didn't see any obsoletes so I requested it be pushed to stable. I now remember that obsoletes had to be disabled in bodhi due to other bugs :-( so that didn't clue me in. Sorry, mea culpa. rel-eng can unpush packages -- but it might be better if they could just push the new set with the fixed deltarpm instead. No problem, I'll open a ticket for the new version to be pushed. I should have communicated that I'd pushed a new version to testing. Thanks again for your work, Jonathan signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Trying to build jackrabbit
Trying to build apache jackrabbit 1.6.0 on F12. Getting: + export MAVEN_REPO_LOCAL=/builddir/build/BUILD/jackrabbit-1.6.0/.m2/repository + MAVEN_REPO_LOCAL=/builddir/build/BUILD/jackrabbit-1.6.0/.m2/repository + mkdir -p /builddir/build/BUILD/jackrabbit-1.6.0/.m2/repository + mvn-jpp -Dmaven.repo.local=/builddir/build/BUILD/jackrabbit-1.6.0/.m2/repository install javadoc:javadoc /usr/lib/jvm/java [INFO] Scanning for projects... Downloading: file:///usr/share/maven2/repository/JPP/maven2/default_poms/org.apache.jackrabbit-parent.pom [WARNING] Skipping non filebased repository http://repo1.maven.org/maven2 in full offline mode [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:jackrabbit-parent:pom:1.6.0 Reason: Cannot find parent: org.apache.jackrabbit:parent for project: null:jackrabbit-parent:pom:1.6.0 for project null:jackrabbit-parent:pom:1.6.0 Any ideas? http://www.cora.nwra.com/~orion/fedora/jackrabbit-1.6.0-1.fc11.src.rpm Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-10-02
On Wednesday 07 October 2009 06:16:50 pm Matthias Clasen wrote: On Wed, 2009-10-07 at 17:11 -0400, Steve Grubb wrote: On Friday 02 October 2009 01:56:21 pm Jon Stanley wrote: Meeting summary --- * incomplete features (jds2001, 17:04:12) * AGREED: Lower Process Capabilities is retained, dbus changes are being committed to complete the feature. (jds2001, 17:38:58) I'm wondering if this is still in work? I just checked koji and dbus was rebuilt today, but without applying the patch here: https://bugzilla.redhat.com/show_bug.cgi?id=518541 I really want to mark this feature 100% done. All that needs to be done is change the BuildRequires to libcap-ng-devel and apply the attached patch. I just asked Colin, who looked at the patch. There must have been some miscommunication, since he had expected you to do the build for F12 Sometime earlier this year something was changed in the package db that requires you to be a proven packager to touch other people's packages. I found this out when I tried to rebuild all the dependencies for the audit-libs soname number bump back in August. ...let me do a build now. Thanks. The Lower Process Capabilities Feature is now 100% complete. Wiki page has been updated. The testing plan has been updated. Now we just need testing. :) -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Thu, Oct 08, 2009 at 14:05:22 +0100, I was just suggesting that a separate yum archive with the packages necessary to test the later graphics development code that will be in F12 could be made available for people to try out easily with their F11 systems. They can optionally try these. I think it will allow 3D to work for many people It is probably just as good for the user to try out rawhide and see if it is worth going to F12. And it's a lot less work for developers and graphics seems to have a developer bottleneck, so I think savign their effort is beneficial to the project. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Wed, Oct 07, 2009 at 15:15:06 +0100, Terry Barnaby ter...@beam.ltd.uk wrote: The graphics system in F11 is horribly broken for 3D, at least on Intel 845, ATI 200 and ATI 300 chipsets. Certainly the Blender program will not run on any of my computers (5 different graphics hardware versions). I was able to start testing my rv280 based ATI 9200 card this morning and I was able to do stuff in tremulous, so it looks like 3d is working again. For F11 I had needed to use no modeset which broke 3d. I still have some more testing to do and I need to set up at least one modeline since modeline detection doesn't work for me (probably because my monitor doesn't do EDID correctly or at all). So it might be worth you trying out F12. Note that I used a very recent kernel and ati driver which might not have been tagged for the beta. This seemed to be an improvement over my first reboot after going to F12 which had stuff a day or so older. I am going to be very happy if this preliminary result bears out under further testing. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Thu, 8 Oct 2009, Jesse Keating wrote:
On Thu, 2009-10-08 at 11:29 +0300, Panu Matilainen wrote:
With that, the %{name} part is expanded at build time to effectively the
source rpm name, and the rest is up to query-time expansion. The extension
could return empty if the macro expansion fails (ie when _bugurl_os isn't
defined). Something like fedora-release could provide the %_bugurl_os
definition by default, and downstream distros, IT admins etc could
override it to whatever appropriate. It also permits controlling the
bugurl for packages from different sources like 3rd party repositories.
And changing the bug tracker base address doesn't require mass-rebuild.
That's trivial to implement, but would that be sufficient to cover the
concerns over arbitrary downstream distros pointing to Fedora bugtracker
etc, or should I just let it be?
Hrm, how does it help for 3rd party packages? They would hardcode the
entire string into their rpms?
They could hardcode the entire string or use their own macro for it, like
%{_bugurl_myrepo} and provide a macro in their -release package that
provides the macro definition.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug reporting URL field in packages
On Thu, 2009-10-08 at 21:00 +0300, Panu Matilainen wrote:
They could hardcode the entire string or use their own macro for it, like
%{_bugurl_myrepo} and provide a macro in their -release package that
provides the macro definition.
Oh I see, yeah that could work.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
signature.asc
Description: This is a digitally signed message part
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Easy review swap
Richard W.M. Jones wrote: https://bugzilla.redhat.com/show_bug.cgi?id=527971 OCaml framework for Functional Reactive Programming (FRP) The whole library is a single file, it's rpmlint clean, and there's a Koji scratch build. I'll swap for a similarly easy review. Rich. I could trade you the papi package for review. It isn't quite as simple, but I have gone through the fedora package review checklist and made a couple iterations on the papi srpm: https://bugzilla.redhat.com/show_bug.cgi?id=525346 Review Request: papi - Performance Application Programming Interface A scratch build has been put through koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=1722841 -Will -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On 10/08/2009 05:37 PM, Adam Williamson wrote: On Thu, 2009-10-08 at 14:05 +0100, Terry Barnaby wrote: No, I don't what to force testing on anyone (although F11 has done that already :) ) I was just suggesting that a separate yum archive with the packages necessary to test the later graphics development code that will be in F12 could be made available for people to try out easily with their F11 systems. They can optionally try these. I think it will allow 3D to work for many people (from my experience of the latest GIT versions) although others would not be so lucky. They can easily back these changes out if they have more issues than the standard graphics system. Then please feel free to make one. :) I don't mean that in a snide fashion, but it really is the answer. As noted, having our X.org developers spend time on such a repository directly subtracts that amount of time from the time they would otherwise spend actually developing the drivers (our X.org maintainers are also major upstream developers) and fixing reported bugs. Given that there is a lot of development work to do on these drivers (which is why you find the newer versions better...) and a lot of bugs to fix (we generally barely keep up with the rate of bugs filed as it is), we don't see that as a good trade-off. You'd get backported drivers for stable releases, but the rate of development of the actual upstream drivers would be noticeably slowed, and fewer reported bugs would ultimately get fixed. Backporting packages is not intrinsically very difficult, though it is somewhat time-consuming, so it's something for which a far greater candidate pool exists than X driver development. Thus, the suggestion that someone else do it. For instance, you. It seems you've already successfully built the latest versions of things locally; if you can do that, you can put them in a package and put the package in a repository, it's not a very hard process and it's all documented on the Wiki. I was thinking of doing that, I have done this sort of thing before, until the drivers/drm/mesa needed changes in the XServer which is dependent on a lot of things. I would then be fighting a battle with the main updates repositories for evermore, well until F12 which will then bring in its own set of problems -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Thu, 2009-10-08 at 19:33 +0100, Terry Barnaby wrote: Backporting packages is not intrinsically very difficult, though it is somewhat time-consuming, so it's something for which a far greater candidate pool exists than X driver development. Thus, the suggestion that someone else do it. For instance, you. It seems you've already successfully built the latest versions of things locally; if you can do that, you can put them in a package and put the package in a repository, it's not a very hard process and it's all documented on the Wiki. I was thinking of doing that, I have done this sort of thing before, until the drivers/drm/mesa needed changes in the XServer which is dependent on a lot of things. I would then be fighting a battle with the main updates repositories for evermore, well until F12 which will then bring in its own set of problems well, yes, and that's the exact reason it would be finicky and time-consuming and not a good way for our X developers to spend their time :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: preupgrade from f11 to rawhide broken? python traceback
On Wed, Oct 07, 2009 at 08:19:28AM -0400, Seth Vidal wrote: On Wed, 7 Oct 2009, Pasi Kärkkäinen wrote: On Thu, Oct 01, 2009 at 10:51:36PM +0300, Pasi Kärkkäinen wrote: Traceback (most recent call last): File /usr/share/preupgrade/preupgrade-cli.py, line 305, in module pu.main(myrelease) File /usr/share/preupgrade/preupgrade-cli.py, line 270, in main self.generate_repo(cachedir, comps) # TODO: callback? File /usr/lib/python2.6/site-packages/preupgrade/__init__.py, line 651, in generate_repo misc.generate_repodata(dir,comps,callback) File /usr/lib/python2.6/site-packages/preupgrade/misc.py, line 131, in generate_repodata generate_repodata(dir, comps, callback) File /usr/lib/python2.6/site-packages/preupgrade/misc.py, line 148, in generate_repodata_f9 mdgen.doRepoMetadata() File /usr/lib/python2.6/site-packages/createrepo/__init__.py, line 829, in doRepoMetadata rp.getPrimary(complete_path, csum) File /usr/lib64/python2.6/site-packages/sqlitecachec.py, line 45, in getPrimary self.repoid)) TypeError: Parsing primary.xml error: attributes construct error Known problem? How to fix it? this is the second time I've seen this one - if you can find the primary.xml in /var/cache/yum/anaconda* directory, I'd appreciate seeing it. # ls /var/cache/yum fedora preupgrade updates # cd /var/cache/yum # find -iname '*primary*' ./updates/77201d8b7218d4edb8d0762c1aa1cbbe5975fdc571d0787f1920a0a204b1188d-primary.sqlite ./preupgrade/f854960bfcacf06e2a8cb03cf3928a38c8e4e2fa860bed984a0edb89555600cf-primary.sqlite ./preupgrade/.repodata/primary.xml.gz ./preupgrade/.repodata/primary.xml.gz.sqlite ./fedora/6a8bfab8ebcbc79f9827f5b16bc1bd1573c068f141bf47c6f216e72dd8b60ff0-primary.sqlite I put it available online here: http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz Firefox complains about it btw.. XML Parsing Error: not well-formed Location: http://pasik.reaktio.net/fedora/rawhide-primary.xml.gz Line Number 42622, Column 68: rpm:entry name=group(saslauth) flags=EQ epoch=0 ver=Saslauthd/ ---^ Does this help? Did you have time to take a look at it? Other people seem to be having the same problem.. update to yum from f11-updates (3.2.24) and the problem goes away. -sv Indeed, yum 3.2.24 fixed the problem. Thanks! -- Pasi -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora 12 Final Release Date Rescheduled to 2009-11-17
Update from the previous announcement on changes to the Fedora 12 schedule described here: https://www.redhat.com/archives/fedora-devel-announce/2009-October/msg3.html The deadline affecting the data center move which was putting a final release date if 2009-11-17 into question has been extended. As a result we are now able to go forward with the original decision from the 2009-10-05 Release Engineering meeting to move the final release date of Fedora 12 to 2009-11-17. All of the schedules have been updated to reflect these changes. Key milestones: https://fedoraproject.org/wiki/Releases/12 Detailed team schedules and ics (calendar) files: http://poelstra.fedorapeople.org/schedules/f-12/ John ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Fri, 2009-10-09 at 09:19 +1000, Dave Airlie wrote: On Thu, 2009-10-08 at 09:37 -0700, Adam Williamson wrote: Then please feel free to make one. :) I don't mean that in a snide fashion, but it really is the answer. As noted, having our X.org developers spend time on such a repository directly subtracts that amount of time from the time they would otherwise spend actually developing the drivers (our X.org maintainers are also major upstream developers) and fixing reported bugs. I thought about doing something like this the other day, but really if we had something like Ubuntu PPA, which I think is on the longterm plans for Fedora then it would be a lot easier to do. At the moment its just too distracting to do. The thing with doing updates for F11 is the regression rate due to lack of QA, I put Mesa packages into updates-testing that fixed a lot of r300/r500 bugs back at the start of F11 and it went into testing a few weeks later and broke Intel, I got 0 reports during that u-t phase about breakage. So now I have a package in stable that lets 3D works for x num of people and breaks compiz for y number. The problem is that PPAs/KoPeRs are going to get much less testing than stuff in updates-testing, so if you don't think you are getting enough testing in updates-testing I really don't see how KoPeRs will solve that problem. Personally I'd suggest pushing to updates-testing but wait a _long_ time (maybe even never) before pushing to stable. Of course you are kind of screwed in having a package which might work fine on one machine, but fail on many others. I think for F12 updates we could really do with some sort of side repo setup, so we could have a stability period where QA could happen on packages that may end up in updates a month or two later. How would this be different from updates-testing? If you install yum-plugin-aliases it even has predefined aliases lsuT and upT to get the list of updates from testing, and update to them. bodhi has support for it etc. -- James Antill ja...@fedoraproject.org Fedora -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James Antill wrote: The problem is that PPAs/KoPeRs are going to get much less testing than stuff in updates-testing, so if you don't think you are getting enough testing in updates-testing I really don't see how KoPeRs will solve that problem. Personally I'd suggest pushing to updates-testing but wait a _long_ time (maybe even never) before pushing to stable. Of course you are kind of screwed in having a package which might work fine on one machine, but fail on many others. I think for F12 updates we could really do with some sort of side repo setup, so we could have a stability period where QA could happen on packages that may end up in updates a month or two later. How would this be different from updates-testing? If you install yum-plugin-aliases it even has predefined aliases lsuT and upT to get the list of updates from testing, and update to them. bodhi has support for it etc. The problem with forcing two pipelines through u-t for one package is that if the stable package has something that needs to go through updates-testing, the new, possibly unstable, version shadows the new stable build. Side repos (preferably themed per sé; KDE updates separate from GNOME packages that the same maintainer happens to maintain as well so that users don't have to update something they use on the side and can't test as well) is the only way to fit a double pipeline for a single package through the update system as it stands. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJKzrxtAAoJEKaxavVX4C1XPZwQAKQjQDq6d6ozoTM9s1cOzd7L nuM4TWe5qkbqORsSW+5o9wimMLlkpfT0LRzZgIdQoc2RJEAj7Tc5/zWeuvmuK8s9 oTje+oZegXnRjnoCmXlnrY0rp1Tsg4RRb6Y2Vk8cI5LIpWgQMn30Bjdigp4NM6TU qzqnwvE3n1LMaNZuY9ZKRUk8GZOarGcr+vaD46GYV660p2meiPX+jhh1OxLI7Kmt iSc9lSverigry31im1isEXeXLYT7k3RFBiegzNsNixE25DkCGRu8tPkWZlO6hv// 4t+/iMVkJU+JfUQTnXxdidlPObU3u9aFBgzJfjYentFMYjVH4s0/xnQDQ6UTJN49 AXxYMQExkKDodTYUYBIeSeEAQhFF4cyD0ZzWr9nPeqfB/pZqfv7jAvPJmts2pzKI u2uRq+L53hOlIjF5fa//514n+n1VuT0ju3gdtBEeAxaVOZfDcXCFEhBAP9KzdNU5 hJ38nwfDulCVbtWRQrs5ks67UXHcDNCb5YSR0vtSjkaJJujUsoiHd7GT+0qsz2NT 6IKRfc86u5+Pn39qhkk0fpQMzlL08GrVIFLK//4EMUOlWiOlZAfRq8Ujx9F4B/+0 H7cZHkix55GMtV6WVQUgBzE0O+rvBDUPfpr/Y2jEdZj2bGbusoowyDms6CF/4DxY cIK16m8HKZQ0mYZOhgPe =AIHy -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[Bug 528000] New: Tainted variables in sprintf format
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Tainted variables in sprintf format https://bugzilla.redhat.com/show_bug.cgi?id=528000 Summary: Tainted variables in sprintf format Product: Fedora Version: 10 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: perl-Image-ExifTool AssignedTo: tcall...@redhat.com ReportedBy: p...@datasphere.ch QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, fedora-perl-devel-list@redhat.com Classification: Fedora Description of problem: Some tainted variable(s) are used in sprintf statement(s) causing warnings when calling program is executed with the -T option. In example: Insecure dependency in sprintf while running with -T switch at /usr/lib/perl5/vendor_perl/5.10.0/Image/ExifTool/Exif.pm line 2958 Version-Release number of selected component (if applicable): perl-5.10.0-73.fc10.i386 perl-Image-Exiftool-7.67-1.fc10.noarch How reproducible: Always in 5.10.0, providing the sprintf statement is reached. Steps to Reproduce: I don't know how to force it: I discovered it while testing a spamassassin OCR plugin. Actual results: See above Expected results: No warning -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/vim-perl-tt2/devel import.log, NONE, 1.1 vim-perl-tt2.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/vim-perl-tt2/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv23115/devel
Modified Files:
.cvsignore sources
Added Files:
import.log vim-perl-tt2.spec
Log Message:
initial import
--- NEW FILE import.log ---
vim-perl-tt2-0_1_3-2_fc11:HEAD:vim-perl-tt2-0.1.3-2.fc11.src.rpm:1255016155
--- NEW FILE vim-perl-tt2.spec ---
Name: vim-perl-tt2
Version:0.1.3
Release:2%{?dist}
Summary:Syntax highlighting for the Template-Toolkit
Group: Applications/Editors
License:Vim
URL:http://www.vim.org/scripts/script.php?script_id=830
# source0 lives at http://www.vim.org/scripts/download_script.php?src_id=6881
Source0:tt2.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
Requires: vim-common
%global vimfiles %{_datadir}/vim/vimfiles
%description
%{name} enables syntax highlighting for the Perl Template-Toolkit, v2.
* Contain Perl code in PERL/RAWPERL directive. (runtime sytax/perl.vim)
* No folding
* HTML syntax for including TT2 syntax. ( tt2html.vim / unfinished )
* Configurable START_TAG/END_TAG for your style.
%prep
%setup -q -c
cat tt2.vim.ft 'EOF'
au BufNewFile,BufRead *.tt2 setf tt2
or
au BufNewFile,BufRead *.tt2
\ if ( getline(1) . getline(2) . getline(3) =~ '\chtml'
\getline(1) . getline(2) . getline(3) !~ '[%?]')
\ || getline(1) =~ '!DOCTYPE HTML' |
\ setf tt2html |
\ else |
\ setf tt2 |
\ endif
ASP
:let b:tt2_syn_tags = '% %'
PHP
:let b:tt2_syn_tags = '? ?'
TT2 and HTML
let b:tt2_syn_tags = '\[% %] !-- --'
EOF
%build
# no-op
%install
rm -rf %{buildroot}
mkdir -p %{buildroot}%{vimfiles}/syntax
install -p -m 0644 *.vim %{buildroot}%{vimfiles}/syntax
mkdir -p %{buildroot}%{vimfiles}/ftdetect
cp tt2.vim.ft %{buildroot}%{vimfiles}/ftdetect/tt2.vim
%{_fixperms} %{buildroot}
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%{vimfiles}/ftdetect/*
%{vimfiles}/syntax/*
%changelog
* Mon Sep 28 2009 Chris Weyl cw...@alumni.drew.edu 0.1.3-2
- require vim-common, not vim-perl-support
* Fri Sep 25 2009 Chris Weyl cw...@alumni.drew.edu 0.1.3-1
- initial packaging
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/vim-perl-tt2/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 8 Oct 2009 06:00:30 - 1.1
+++ .cvsignore 8 Oct 2009 15:35:59 - 1.2
@@ -0,0 +1 @@
+tt2.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/vim-perl-tt2/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 8 Oct 2009 06:00:30 - 1.1
+++ sources 8 Oct 2009 15:35:59 - 1.2
@@ -0,0 +1 @@
+3e70d82171456550855a8b9612226c11 tt2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/vim-perl-tt2/F-12 import.log, NONE, 1.1 vim-perl-tt2.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/vim-perl-tt2/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv23266/F-12
Modified Files:
.cvsignore sources
Added Files:
import.log vim-perl-tt2.spec
Log Message:
initial import
--- NEW FILE import.log ---
vim-perl-tt2-0_1_3-2_fc11:F-12:vim-perl-tt2-0.1.3-2.fc11.src.rpm:1255016165
--- NEW FILE vim-perl-tt2.spec ---
Name: vim-perl-tt2
Version:0.1.3
Release:2%{?dist}
Summary:Syntax highlighting for the Template-Toolkit
Group: Applications/Editors
License:Vim
URL:http://www.vim.org/scripts/script.php?script_id=830
# source0 lives at http://www.vim.org/scripts/download_script.php?src_id=6881
Source0:tt2.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
Requires: vim-common
%global vimfiles %{_datadir}/vim/vimfiles
%description
%{name} enables syntax highlighting for the Perl Template-Toolkit, v2.
* Contain Perl code in PERL/RAWPERL directive. (runtime sytax/perl.vim)
* No folding
* HTML syntax for including TT2 syntax. ( tt2html.vim / unfinished )
* Configurable START_TAG/END_TAG for your style.
%prep
%setup -q -c
cat tt2.vim.ft 'EOF'
au BufNewFile,BufRead *.tt2 setf tt2
or
au BufNewFile,BufRead *.tt2
\ if ( getline(1) . getline(2) . getline(3) =~ '\chtml'
\getline(1) . getline(2) . getline(3) !~ '[%?]')
\ || getline(1) =~ '!DOCTYPE HTML' |
\ setf tt2html |
\ else |
\ setf tt2 |
\ endif
ASP
:let b:tt2_syn_tags = '% %'
PHP
:let b:tt2_syn_tags = '? ?'
TT2 and HTML
let b:tt2_syn_tags = '\[% %] !-- --'
EOF
%build
# no-op
%install
rm -rf %{buildroot}
mkdir -p %{buildroot}%{vimfiles}/syntax
install -p -m 0644 *.vim %{buildroot}%{vimfiles}/syntax
mkdir -p %{buildroot}%{vimfiles}/ftdetect
cp tt2.vim.ft %{buildroot}%{vimfiles}/ftdetect/tt2.vim
%{_fixperms} %{buildroot}
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%{vimfiles}/ftdetect/*
%{vimfiles}/syntax/*
%changelog
* Mon Sep 28 2009 Chris Weyl cw...@alumni.drew.edu 0.1.3-2
- require vim-common, not vim-perl-support
* Fri Sep 25 2009 Chris Weyl cw...@alumni.drew.edu 0.1.3-1
- initial packaging
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/vim-perl-tt2/F-12/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 8 Oct 2009 06:00:30 - 1.1
+++ .cvsignore 8 Oct 2009 15:36:09 - 1.2
@@ -0,0 +1 @@
+tt2.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/vim-perl-tt2/F-12/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 8 Oct 2009 06:00:30 - 1.1
+++ sources 8 Oct 2009 15:36:09 - 1.2
@@ -0,0 +1 @@
+3e70d82171456550855a8b9612226c11 tt2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/vim-perl-tt2/F-11 import.log, NONE, 1.1 vim-perl-tt2.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/vim-perl-tt2/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv23420/F-11
Modified Files:
.cvsignore sources
Added Files:
import.log vim-perl-tt2.spec
Log Message:
initial import
--- NEW FILE import.log ---
vim-perl-tt2-0_1_3-2_fc11:F-11:vim-perl-tt2-0.1.3-2.fc11.src.rpm:1255016176
--- NEW FILE vim-perl-tt2.spec ---
Name: vim-perl-tt2
Version:0.1.3
Release:2%{?dist}
Summary:Syntax highlighting for the Template-Toolkit
Group: Applications/Editors
License:Vim
URL:http://www.vim.org/scripts/script.php?script_id=830
# source0 lives at http://www.vim.org/scripts/download_script.php?src_id=6881
Source0:tt2.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
Requires: vim-common
%global vimfiles %{_datadir}/vim/vimfiles
%description
%{name} enables syntax highlighting for the Perl Template-Toolkit, v2.
* Contain Perl code in PERL/RAWPERL directive. (runtime sytax/perl.vim)
* No folding
* HTML syntax for including TT2 syntax. ( tt2html.vim / unfinished )
* Configurable START_TAG/END_TAG for your style.
%prep
%setup -q -c
cat tt2.vim.ft 'EOF'
au BufNewFile,BufRead *.tt2 setf tt2
or
au BufNewFile,BufRead *.tt2
\ if ( getline(1) . getline(2) . getline(3) =~ '\chtml'
\getline(1) . getline(2) . getline(3) !~ '[%?]')
\ || getline(1) =~ '!DOCTYPE HTML' |
\ setf tt2html |
\ else |
\ setf tt2 |
\ endif
ASP
:let b:tt2_syn_tags = '% %'
PHP
:let b:tt2_syn_tags = '? ?'
TT2 and HTML
let b:tt2_syn_tags = '\[% %] !-- --'
EOF
%build
# no-op
%install
rm -rf %{buildroot}
mkdir -p %{buildroot}%{vimfiles}/syntax
install -p -m 0644 *.vim %{buildroot}%{vimfiles}/syntax
mkdir -p %{buildroot}%{vimfiles}/ftdetect
cp tt2.vim.ft %{buildroot}%{vimfiles}/ftdetect/tt2.vim
%{_fixperms} %{buildroot}
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%{vimfiles}/ftdetect/*
%{vimfiles}/syntax/*
%changelog
* Mon Sep 28 2009 Chris Weyl cw...@alumni.drew.edu 0.1.3-2
- require vim-common, not vim-perl-support
* Fri Sep 25 2009 Chris Weyl cw...@alumni.drew.edu 0.1.3-1
- initial packaging
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/vim-perl-tt2/F-11/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 8 Oct 2009 06:00:30 - 1.1
+++ .cvsignore 8 Oct 2009 15:36:21 - 1.2
@@ -0,0 +1 @@
+tt2.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/vim-perl-tt2/F-11/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 8 Oct 2009 06:00:30 - 1.1
+++ sources 8 Oct 2009 15:36:21 - 1.2
@@ -0,0 +1 @@
+3e70d82171456550855a8b9612226c11 tt2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
rpms/vim-perl-tt2/F-10 import.log, NONE, 1.1 vim-perl-tt2.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: cweyl
Update of /cvs/extras/rpms/vim-perl-tt2/F-10
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv23595/F-10
Modified Files:
.cvsignore sources
Added Files:
import.log vim-perl-tt2.spec
Log Message:
initial import
--- NEW FILE import.log ---
vim-perl-tt2-0_1_3-2_fc11:F-10:vim-perl-tt2-0.1.3-2.fc11.src.rpm:1255016187
--- NEW FILE vim-perl-tt2.spec ---
Name: vim-perl-tt2
Version:0.1.3
Release:2%{?dist}
Summary:Syntax highlighting for the Template-Toolkit
Group: Applications/Editors
License:Vim
URL:http://www.vim.org/scripts/script.php?script_id=830
# source0 lives at http://www.vim.org/scripts/download_script.php?src_id=6881
Source0:tt2.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
Requires: vim-common
%global vimfiles %{_datadir}/vim/vimfiles
%description
%{name} enables syntax highlighting for the Perl Template-Toolkit, v2.
* Contain Perl code in PERL/RAWPERL directive. (runtime sytax/perl.vim)
* No folding
* HTML syntax for including TT2 syntax. ( tt2html.vim / unfinished )
* Configurable START_TAG/END_TAG for your style.
%prep
%setup -q -c
cat tt2.vim.ft 'EOF'
au BufNewFile,BufRead *.tt2 setf tt2
or
au BufNewFile,BufRead *.tt2
\ if ( getline(1) . getline(2) . getline(3) =~ '\chtml'
\getline(1) . getline(2) . getline(3) !~ '[%?]')
\ || getline(1) =~ '!DOCTYPE HTML' |
\ setf tt2html |
\ else |
\ setf tt2 |
\ endif
ASP
:let b:tt2_syn_tags = '% %'
PHP
:let b:tt2_syn_tags = '? ?'
TT2 and HTML
let b:tt2_syn_tags = '\[% %] !-- --'
EOF
%build
# no-op
%install
rm -rf %{buildroot}
mkdir -p %{buildroot}%{vimfiles}/syntax
install -p -m 0644 *.vim %{buildroot}%{vimfiles}/syntax
mkdir -p %{buildroot}%{vimfiles}/ftdetect
cp tt2.vim.ft %{buildroot}%{vimfiles}/ftdetect/tt2.vim
%{_fixperms} %{buildroot}
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%{vimfiles}/ftdetect/*
%{vimfiles}/syntax/*
%changelog
* Mon Sep 28 2009 Chris Weyl cw...@alumni.drew.edu 0.1.3-2
- require vim-common, not vim-perl-support
* Fri Sep 25 2009 Chris Weyl cw...@alumni.drew.edu 0.1.3-1
- initial packaging
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/vim-perl-tt2/F-10/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 8 Oct 2009 06:00:30 - 1.1
+++ .cvsignore 8 Oct 2009 15:36:31 - 1.2
@@ -0,0 +1 @@
+tt2.tar.gz
Index: sources
===
RCS file: /cvs/extras/rpms/vim-perl-tt2/F-10/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 8 Oct 2009 06:00:30 - 1.1
+++ sources 8 Oct 2009 15:36:31 - 1.2
@@ -0,0 +1 @@
+3e70d82171456550855a8b9612226c11 tt2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 528000] Tainted variables in sprintf format
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=528000 --- Comment #1 from Tom spot Callaway tcall...@redhat.com 2009-10-08 11:54:30 EDT --- Hrm. This will be tough to fix/report upstream without a way to reproduce it. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 528000] Tainted variables in sprintf format
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=528000 --- Comment #2 from Marcela Maslanova mmasl...@redhat.com 2009-10-08 12:04:05 EDT --- There was problem with spamassasin which was workaround with rebuild of perl. But I made the change only in F-12 build. Could be the same issue? #510127 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 528000] Tainted variables in sprintf format
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=528000 --- Comment #3 from Patrick Monnerat p...@datasphere.ch 2009-10-08 13:38:42 EDT --- Here are some details. The lines causing the trouble are: $format and $exifTool-Warn( sprintf(Unknown format ($format) for $dirName tag 0x%x,$tagID)); So $format and/or $dirName are tainted. I'm not a Perl guy, so I can hardly backtrack these variable's sources (it even comes from out of the module), but I think the faulty statement can be rewritten as: $format and $exifTool-Warn( sprintf(Unknown format (%d) for %s tag 0x%x,$format,$dirName,$tagID)); in a more secure way that does not cause the taint problem, but at the expense of poorer readability, I agree. From what I can see by examining Exif.pm, some other sprintf statements might be subject to similar problems (i.e.: lines 2918, 2941, 2972, ...). I apologize for not being able to reproduce, but the line is reached when there is an unknown format in an Exif directory of a picture that I do not have anymore (rejected by SpamAssassin!) Whether the current bug is related to bug 510127 or not is out of my Perl understanding... and since I do not know how to reproduce, I cannot even test it on rawhide :-( Sorry and thanks for the proposal. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 526872] Update to rt 3.6.9
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=526872 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ASSIGNED|ON_QA --- Comment #2 from Fedora Update System upda...@fedoraproject.org 2009-10-08 14:05:08 EDT --- rt3-3.6.9-1.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update rt3'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/EL-5/FEDORA-EPEL-2009-0602 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 509419] perl-Glib Requires a development package: perl(ExtUtils::MakeMaker)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=509419 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||1.201-3.fc11 Resolution||ERRATA -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
[Bug 509419] perl-Glib Requires a development package: perl(ExtUtils::MakeMaker)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=509419 --- Comment #6 from Fedora Update System upda...@fedoraproject.org 2009-10-08 23:31:33 EDT --- perl-Glib-1.201-3.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
distribute vs setuptools
So I just read this piece of news on the distutils-sig list. Here's a summary/background. setuptools has become increasingly popular as a method of making python modules easier to package (by upstream), managing plugins, and getting version requirements right. However, the setuptools author has been somewhat lackadaisical about maintaining the code, integrating bugfixes, etc. Since the setuptools author hasn't wanted to pass the torch on to someone else, the project has forked. Distribute-0.6 is the compatible fork with multiple maintainers who are interested in preserving setuptools compatibility in the 0.6 branch and making real (but API changing) improvements in the 0.7 branch. Due to the non-maintenance of setuptools, some other Linux distros have started shipping distribute-0.6 as their setuptools module. Their plan is to ship distribute-0.6 as setuptools and distribute-0.7 as distribute. By doing this, the consumers of setuptools don't have to change their package (all the import statements) to use distribute instead of setuptools. If they didn't do this, the packages would need to be patched to use distribute instead of setuptools. The benefit of this is that they get a maintained piece of code with an upstream that is responsive to bug reports, patches, and takes distribution problems into consideration (even if they can't always do something about them in the 0.6 codebase). The downsides are that the setuptools upstream is alive even if it isn't thriving and the setuptools maintainer could throw a monkey into the works by releasing API breaking changes when he does a new setuptools release. Since I'm the current setuptools maintainer and have had issues trying to get bugs fixed in upstream setuptools before, I'm inclined to do this as well but the drawbacks are nothing to ignore. So what do other people think of our doing this as well? If we don't do this, an alternative might be to plan on packaging distribute0.6 and distribute0.7 parallel installable. Then we can port packages to use distribute instead of setuptools when its available and submit those patches to upstream projects. -Toshio - Forwarded message from Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com - Date: Thu, 8 Oct 2009 23:07:13 +0200 From: Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com To: distutils-...@python.org Subject: Re: [Distutils] Packaging Distribute X-BeenThere: distutils-...@python.org 2009-10-04 23:52:25 Sridhar Ratnakumar napisał(a): On Sun, 04 Oct 2009 13:41:06 -0700, Tarek Ziadé ziade.ta...@gmail.com wrote: The other way would be to use Distribute instead of Setuptools for what the packaging system is calling setuptools. That's pretty much what is happening in Gentoo (arch) and UHU-Linux (dev), right now Interesting. Gentoo uses distribute but retains the name 'setuptools'? It's because Distribute 0.6.* installs setuptools.* modules. Distribute 0.7.* will be under name dev-python/distribute. Ah. But what if PJE releases setuptools with the *same* version number 0.6.3? What would the gentoo folks do in order to get the new setuptools release in their packaging system? Or did they make a decision of totally dropping setuptools from their repository? We could switch to back to Setuptools only if Setuptools became more maintained than Distribute. -- Arfrever Frehtes Taifersar Arahesis ___ Distutils-SIG maillist - distutils-...@python.org http://mail.python.org/mailman/listinfo/distutils-sig - End forwarded message - pgpmeH5bPnBJ8.pgp Description: PGP signature ___ Fedora-python-devel-list mailing list Fedora-python-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-python-devel-list
