Re: Disabling drm/ttm/radeon module loading for debugging
On Mon, Jan 25, 2010 at 05:42:49PM -0800, Adam Williamson wrote: On Sun, 2010-01-24 at 18:13 +0200, Pasi Kärkkäinen wrote: Ok, I just also blacklisted the radeon/drm/ttm modules in /etc/modprobe.d/ and now they aren't loaded automatically anymore. For the record, for graphics modules, you need to double-blacklist them: blacklist in /etc/modprobe.d and either remove them from initrd (as you did) or use the rdblacklist kernel parameter to stop them being loaded from the initrd. Thanks for the tip. I didn't know rdblacklist exists.. -- Pasi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multilib help?
On Mon, 25 Jan 2010, Richard W.M. Jones wrote: On Mon, Jan 25, 2010 at 02:08:10PM -0500, Bill Nottingham wrote: - If the file in both packages is identical, installation is allowed and the file is written - If the file in both packages is an ELF binary, the file used is the file in the package for the primary architecture - If the file in both packages is not an ELF binary a RPM conflict is raised Are you sure about the third rule? Yes. I think the problem arises because /usr/bin/libguestfs-supermin-helper is different in libguestfs.i686 and libguestfs.x86_64, but this file is a shell script, not an ELF binary. These are the files in libguestfs.i686 and libguestfs.x86_64 that have the same names but different content: /usr/bin/hivexget (ELF binary) /usr/bin/hivexml (ELF binary) /usr/bin/libguestfs-test-tool (ELF binary) /usr/libexec/libguestfs-test-tool-helper (ELF binary) /usr/bin/libguestfs-supermin-helper (shell script) Anyway, I will move the shell script and see if that helps. Wont help, the multilib file shadowing logic is NOT based on paths. Looking at libguestfs.spec, here's the problem: %global _use_internal_dependency_generator 0 The external dependency generator doesn't create the file coloring that the multilib magic needs to operate. So you'll get conflicts on all paths where content differs. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Remove write permissions from executables
On Mon, 2010-01-25 at 14:48 -0600, Garrett Holmstrom wrote:
On Mon, Jan 25, 2010 at 11:54 AM, Till Maas opensou...@till.name wrote:
On Mon, Jan 25, 2010 at 12:45:26PM -0500, Mike McLean wrote:
Furthermore, when the user is root, the 0555 mode will not prevent
writing as it would for normal users.
It does not matter, whether the user is root, but whether he has the
dac_override capability. If you read the original mail (1st paragraph)
again with this in mind, you will understand the reason for the change.
Does a lack of the dac_override capability prevent root from chmod'ing
its own files?
I had the same question too ;-) and did a quick test. The result was, if
you drop all capabilities, you are still allowed to chmod your files.
So the benefit of removing write permissions is questionable to me.
Maybe someone else can bring in some light?
PS: Testing was done via the attached application.
#include stdio.h
#include unistd.h
#include sys/stat.h
#include cap-ng.h
int main (void) {
capng_clear(CAPNG_SELECT_BOTH);
if (capng_apply(CAPNG_SELECT_BOTH)) {
fprintf (stderr, capng_apply\n);
return 1;
}
if (capng_have_capabilities(CAPNG_SELECT_CAPS) CAPNG_NONE) {
fprintf (stderr, something went wrong, we still have caps\n);
return 1;
}
if (chmod(./blub, S_IRUSR | S_IWUSR)) {
perror (chmod);
return 1;
}
return 0;
}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multilib help?
On Tue, 26 Jan 2010, Panu Matilainen wrote: On Mon, 25 Jan 2010, Richard W.M. Jones wrote: On Mon, Jan 25, 2010 at 02:08:10PM -0500, Bill Nottingham wrote: - If the file in both packages is identical, installation is allowed and the file is written - If the file in both packages is an ELF binary, the file used is the file in the package for the primary architecture - If the file in both packages is not an ELF binary a RPM conflict is raised Are you sure about the third rule? Yes. I think the problem arises because /usr/bin/libguestfs-supermin-helper is different in libguestfs.i686 and libguestfs.x86_64, but this file is a shell script, not an ELF binary. These are the files in libguestfs.i686 and libguestfs.x86_64 that have the same names but different content: /usr/bin/hivexget (ELF binary) /usr/bin/hivexml (ELF binary) /usr/bin/libguestfs-test-tool (ELF binary) /usr/libexec/libguestfs-test-tool-helper (ELF binary) /usr/bin/libguestfs-supermin-helper (shell script) Anyway, I will move the shell script and see if that helps. Wont help, the multilib file shadowing logic is NOT based on paths. Looking at libguestfs.spec, here's the problem: %global _use_internal_dependency_generator 0 The external dependency generator doesn't create the file coloring that the multilib magic needs to operate. So you'll get conflicts on all paths where content differs. ...except looking at libguestfs-1.0.75-1.fc12, it *has* been built with internal dependency generator, and it gives: Preparing...### [100%] file /usr/bin/libguestfs-supermin-helper conflicts between attempted installs of libguestfs-1:1.0.75-1.fc12.i686 and libguestfs-1:1.0.75-1.fc12.x86_64 ...which is the expected behavior for a non-elf file (script in this case but doesn't matter). If both arch's of libguestfs have been installed, --replacefiles or --force has been used to force the install despite of a conflicting file. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multilib help?
On Tue, Jan 26, 2010 at 12:35:19PM +0200, Panu Matilainen wrote: ...except looking at libguestfs-1.0.75-1.fc12, it *has* been built with internal dependency generator, and it gives: Preparing...### [100%] file /usr/bin/libguestfs-supermin-helper conflicts between attempted installs of libguestfs-1:1.0.75-1.fc12.i686 and libguestfs-1:1.0.75-1.fc12.x86_64 The problem seems to be when you install them in separate RPM transactions, then remove one (or possibly upgrade one). I haven't worked out a reliable reproducer, but I do know it can happen on machines where nothing has been forced. Anyway, I rewrote the script so that it's the same on all architectures now. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
bash 4.1.2 and broken regular expression matching conditional operator (=~)
Hi all,
please take a look at bash faq section E - E14. Quoting:
E14) Why does quoting the pattern argument to the regular expression matching
conditional operator (=~) cause regexp matching to stop working?
In versions of bash prior to bash-3.2, the effect of quoting the regular
expression argument to the [[ command's =~ operator was not specified.
The practical effect was that double-quoting the pattern argument required
backslashes to quote special pattern characters, which interfered with the
backslash processing performed by double-quoted word expansion and was
inconsistent with how the == shell pattern matching operator treated
quoted characters.
In bash-3.2, the shell was changed to internally quote characters in single-
and double-quoted string arguments to the =~ operator, which suppresses the
special meaning of the characters special to regular expression processing
(`.', `[', `\', `(', `), `*', `+', `?', `{', `|', `^', and `$') and forces
them to be matched literally. This is consistent with how the `==' pattern
matching operator treats quoted portions of its pattern argument.
Since the treatment of quoted string arguments was changed, several issues
have arisen, chief among them the problem of white space in pattern arguments
and the differing treatment of quoted strings between bash-3.1 and bash-3.2.
Both problems may be solved by using a shell variable to hold the pattern.
Since word splitting is not performed when expanding shell variables in all
operands of the [[ command, this allows users to quote patterns as they wish
when assigning the variable, then expand the values to a single string that
may contain whitespace. The first problem may be solved by using backslashes
or any other quoting mechanism to escape the white space in the patterns.
Please, take a look in your bash scripts and fix them.
RR
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning xerces-c
pgpWRCHkmgZlJ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multilib help?
On Tue, Jan 26, 2010 at 06:43:35PM +0200, Panu Matilainen wrote: Note that rpm 4.6.0 did behave differently here: packages with conflicting files were allowed to be installed in the same transaction but not if installed separately, leading to strange situations. So if there's a chance you've tested on RHEL/Centos at some point, that could explain it as it'd then be just a matter of which order the packages got installed in. That could well explain why we've only seen this reported on EPEL 5. I thought it was a coincidence, but looks like it could be the older RPM version there. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning xerces-c
Sorry for the empty message I was going to say: I've changed the pkg owner to jonathanrobie as per the message earlier in this thread. I was going to look into the bug that's at the root of this yesterday but too many other projects came up so I didn't get around to it. Looking at that today. -Toshio pgpOxIcC7xXXh.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multilib help?
On Tue, 26 Jan 2010, Richard W.M. Jones wrote: On Tue, Jan 26, 2010 at 06:43:35PM +0200, Panu Matilainen wrote: Note that rpm 4.6.0 did behave differently here: packages with conflicting files were allowed to be installed in the same transaction but not if installed separately, leading to strange situations. So if there's a chance you've tested on RHEL/Centos at some point, that could explain it as it'd then be just a matter of which order the packages got installed in. That could well explain why we've only seen this reported on EPEL 5. I thought it was a coincidence, but looks like it could be the older RPM version there. Okay, if it has only been seen on EPEL then no need to look further. IIRC it got fixed in RHEL 5 too, 5.3 or thereabouts. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: [Bug 557224] subtree rename breaks the referential integrity plug-in
https://bugzilla.redhat.com/show_bug.cgi?id=557224 Description of problem: Analysis by andrey.iva...@polytechnique.fr I'm pretty sure the referential integrity plug-in will not work for modrdn operations with a new superior. Looking more thoroughly through the code ( ldap / servers / plugins / referint / referint.c) confirms my suspicion that new rdn superior is not taken into account. The function referint_postop_modrdn extracts from the parameter block only SLAPI_MODRDN_TARGET and SLAPI_MODRDN_NEWRDN, it does not extract SLAPI_MODRDN_NEWSUPERIOR neither passes it further down the utility functions - update_integrity(argv, dn, newrdn, logChanges) and writeintegritylog(argv[1],dn, newrdn). The same applies to the delayed referint operations (the plug-in writes to the special integrity log file only the old DN and the new RDN, but never the new superior : writeintegritylog(argv[1],dn, newrdn);) Another thought on the subject of referential integrity plug-in - in the previous mail i have only mentioned one-entry renames with a new superior. The things get even worse when we rename a whole non-empty sub-tree. It means that the referential integrity plug-in should change to the new DNs all the references to all the entries of the whole sub-tree, not only for one entry. And what if we rename a sub-tree containing both the referenced entry and the entry referencing the first one's DN in one of its integrity attributes? It actually means that we need at first make the rename and then all the searches and replacements. Though it seems it's already the case as it's a post-op(?) plug-in... Fix Description: The referential integrity plugin has not supported the subtree rename (modrdn with newsuperior). This patch is adding the support. Created an attachment (id=386896) https://bugzilla.redhat.com/attachment.cgi?id=386896action=diff git patch for ldap/servers/plugins/referint/referint.c -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: OpenModelica users wanting to have rpms?
Christoph Höger wrote: I have started converting MetaModelica to autootols to boot-bootstrap the omc build process. May I suggest using CMake instead? It's easier to use, its new versions are more backwards-compatible with older ones, it's more portable to other (inferior ;-) ) operating systems, it doesn't require or expect you to ship generated files in source tarballs, it supports nice features like progress percentages, it's faster and it's successfully used in more and more upstream projects, including all of KDE. On the other hand, CMake would probably be less than helpful for the SML parts, which comprise a significant portion of the codebase as far as I can see, you'd have to work with add_custom_command which isn't that wonderful. (For common languages like C/C++ and a few others, CMake does a lot of stuff for you, but less common ones aren't really supported and you end up having to write CMake commands equivalent to makefile rules.) So each tool has its advantages and drawbacks. Building the rml compiler and the related libraries was easy, but now I could need some help and advice on how to build the testcases. In the original buildsystem from https://openmodelica.ida.liu.se/svn/MetaModelica there are some examples with own makefiles, but those refer to the buildsystem itself. I am not sure how to handle this with automake (obviously it would require to build the compiler before the tests). So currently I am wondering if the examples should have a build system that requires the compiler to be installed, any thoughts? Normally testsuites can use the just-built compiler directly from the source tree. Look at existing projects and how they handle this. As you're using autotools, I guess GCC would be a good place to look. On the other hand, there are some style questions, I'd like to be answered: This package builds three slightly different libraries in three differen flavors: called (librml_plain|librml_mask|librml_diff)(_g|_p|).so Those flavors only differ by the CFLAGS set upon compilation (_p means -p, _g -g). Upstream told me, they require them all, but would this be acceptable? Sure, I don't see why not. You just need to be careful when building (you need to build the object files to different places so they don't conflict). Is the name rml ok for a library in /usr/lib or shall I use /usr/lib/rml/ by default? (Same for headers) Hmmm, that's a bit at the limit, 3 letters are a bit short for a unique name. :-( But there's no librml.so in Fedora yet as far as repoquery tells me, so at least there's no current conflict. Let's see what others think. What with the name? Is MetaModelica even a good name, if the main binary is rmlc? If that's the upstream project name (used in things like tarballs), it's fine. (But is the MixedCase really necessary? :-( Usually things like tarball and package names are all lowercase, but sometimes MixedCase is used by upstream and the Fedora packages usually match that. Probably something to discuss with upstream.) The package builds a compiler driver, essentially a shell script, by copying some configuration variables into a shell template (mainly how to invoke cc). Would this be fine as a /usr/bin script? Yes, but beware of multilib conflicts: if that script is in the same package as some libraries, that package will end up multilibbed due to the libraries and if the script is not identical for 32-bit and 64-bit, there will be a conflict between the 2 multilibbed packages. (Splitting out the libraries into a -libs package is a way to work around that.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
abrtd not running: applet complains
Hi, When I disable abrtd, I get a tray applet complaining about this. Is there any precedent for this? I have bluetooth disabled, but I don't get a complaint for that.. Filed bug: https://bugzilla.redhat.com/show_bug.cgi?id=557866 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multilib help?
On Tue, Jan 26, 2010 at 12:13:33PM +0200, Panu Matilainen wrote: %global _use_internal_dependency_generator 0 The external dependency generator doesn't create the file coloring that the multilib magic needs to operate. So you'll get conflicts on all paths where content differs. How can one both get the file coloring and add own dependencies with a script to an rpm? Iirc the internal dependency generator needs to be disabled to be able to specify a special script to add dependencies. Regards Till pgpSk4vwo99ET.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Suggestions
On Tue, Jan 26, 2010 at 04:09:35PM +0200, wrote: 4) yum should select the mirror to download from in a smarter way, considering the current load on the mirror and the distance of the mirror from the user. This will help reduce the load on the mirrors and make the download faster for the user. The mirrorlist server should know what is the load on each mirror, and give yum the mirrorlist sorted by the load and the distance from the user. yum should prefer the less busy and closest mirror it can find. MirrorManager (used by yum through Fedora and rpmfusion's repository files) partially implements this. It uses BGP routing data and GeoIP to guess at the distance from the user, in decending order, * specific network blocks (IPv4 and v6) * same Autonomous System * both client and server on Internet2 or related high-speed research network * same country * same continent * any other mirror Further, it weighs the choice in each of the above lists by the nominal bandwidth available by a particular mirror (e.g. if mirror A is capable of serving 100Mbps, while mirror B is capable of serving 1Gbps, mirror A will be chosen 1/10 as often as mirror B). Fedora has 244 public mirrors listed at the moment, and hundreds more private mirrors. We have no way, nor really any desire, to know in real time the load and network capacity of any connection between each mirror and each specific user. Perhaps Akamai does, but that's not a service we pay for. Thanks, Matt Fedora Mirror Wrangler, and MirrorManager author -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: packaging an application that phones home
On Tue, Jan 26, 2010 at 18:46:32 -0800, Eric Smith e...@brouhaha.com wrote: The Licenses page of the MeshLab wiki gives a privacy disclaimer stating that it phones home periodically to check for availability of updated versions, and that it uploads some aggregated statistical data about the Updates should come through Fedora so there shouldn't be a need to check their site for updates. average number and size of the opened/saved meshes. Nothing personally identifiable, though they obviously could capture the source IP address: This should be opt in or dropped. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnome-desktop bump
On Sun, 2010-01-17 at 13:55 -0500, Matthias Clasen wrote: I'm going to build gnome-desktop 2.29.5 in rawhide, which bumps the soname of libgnome-desktop-2.so. Affected packages are: eel2 I asked on IRC for someone to rebuild this. Warren told me it's been blocked, apparently by Tbzatek. However, it has live dependencies. nautilus-python requires eel2, and tortoisehg-nautilus , postr and nautilus-phatch all depend on nautilus-python. Please, either make nautilus-python not require eel2 somehow, make all nautilus-python's dependencies not require nautilus-python any more and block that too, or restore eel2. Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bugzilla update in EPEL?
On Fri, Jan 22, 2010 at 12:53 PM, Emmanuel Seyman emmanuel.sey...@club-internet.fr wrote: [ I'm expanding the cc: list to people whom I believe will be interested in the topic. Max and Frédéric, EPEL is a community-maintained repository for Red Hat Entreprise Linux. Its guidelines allow maintainers to add software to RHEL but not replace packages that already existe in RHEL. ] * Leo Pleiman [21/01/2010 16:30] : Would it be possible to get EPEL bugzilla updated to the current stable? Please. At this point, it seems to demand a little effort. Current Bugzilla requires Template-Toolkit 2.22 and that doesn't seem availible in EPEL. spot, Can you upgrade Template-Toolkit to 2.22 in EL-4 and EL-5 ? -- Itamar Reis Peixoto e-mail/msn/google talk/sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 -- 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
rpms/perl-Template-Toolkit/EL-5 .cvsignore, 1.3, 1.4 perl-Template-Toolkit.spec, 1.9, 1.10 sources, 1.4, 1.5
Author: kasal
Update of /cvs/extras/rpms/perl-Template-Toolkit/EL-5
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv9379
Modified Files:
.cvsignore perl-Template-Toolkit.spec sources
Log Message:
update to 2.22
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-Template-Toolkit/EL-5/.cvsignore,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- .cvsignore 29 May 2006 16:10:19 - 1.3
+++ .cvsignore 26 Jan 2010 08:43:20 - 1.4
@@ -1,2 +1,2 @@
-Template-Toolkit-2.14.tar.gz
-Template-Toolkit-2.15.tar.gz
+Template-Toolkit-2.22.tar.gz
+TT_v222_html_docs.tar.gz
Index: perl-Template-Toolkit.spec
===
RCS file:
/cvs/extras/rpms/perl-Template-Toolkit/EL-5/perl-Template-Toolkit.spec,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- perl-Template-Toolkit.spec 26 Aug 2007 22:18:14 - 1.9
+++ perl-Template-Toolkit.spec 26 Jan 2010 08:43:20 - 1.10
@@ -1,18 +1,21 @@
Name: perl-Template-Toolkit
-Version:2.18
-Release:1%{?dist}
+Version:2.22
+Release:3%{?dist}
Summary:Template processing system
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://www.template-toolkit.org/
Source0:
http://search.cpan.org/CPAN/authors/id/A/AB/ABW/Template-Toolkit-%{version}.tar.gz
+Source1:http://tt2.org/download/TT_v222_html_docs.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-BuildRequires: perl = 1:5.6.1, tetex-dvips, tetex-latex
+BuildRequires: perl(Test::More)
BuildRequires: perl(AppConfig), perl(Text::Autoformat), perl(GD::Graph3d),
perl(GD::Graph)
BuildRequires: perl(GD::Text), perl(Image::Info), perl(Image::Size),
perl(Pod::POM)
BuildRequires: perl(XML::DOM), perl(XML::RSS), perl(XML::XPath)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+Provides: perl-Template-Toolkit-examples = %{version}-%{release}
+Obsoletes: perl-Template-Toolkit-examples 2.22-1
%description
The Template Toolkit is a collection of modules which implement a
@@ -22,17 +25,10 @@ dynamic web content, but it can be used
any other kind of text based documents: HTML, XML, POD, PostScript,
LaTeX, and so on.
-%package examples
-Summary:Examples of how to use Template Toolkit
-Group: Documentation
-Requires: %{name} = %{version}-%{release}
-
-%description examples
-%{summary}.
-
%prep
-%setup -q -n Template-Toolkit-%{version}
+%setup -q -n Template-Toolkit-%{version} -a 1
find lib -type f | xargs chmod -c -x
+find TT_v*_html_docs -depth -name .svn -type d -exec rm -rf {} \;
# Filter false positive provides.
cat EOF %{name}-prov
@@ -46,13 +42,16 @@ EOF
%define __perl_provides %{_builddir}/Template-Toolkit-%{version}/%{name}-prov
chmod +x %{__perl_provides}
+# Convert file to UTF-8
+iconv -f iso-8859-1 -t utf-8 -o Changes{.utf8,}
+mv Changes{.utf8,}
+
%build
CFLAGS=$RPM_OPT_FLAGS %{__perl} Makefile.PL INSTALLDIRS=vendor \
- TT_PREFIX=$RPM_BUILD_ROOT%{_datadir}/tt2 TT_DBI=n TT_ACCEPT=y
+ TT_DBI=n TT_ACCEPT=y
make %{?_smp_mflags} OPTIMIZE=$RPM_OPT_FLAGS
%install
-rm -rf $RPM_BUILD_ROOT _docs
# install (+ INSTALLARCHLIB) instead of pure_install to get docs
# and the template library installed too
make install \
@@ -64,9 +63,7 @@ find $RPM_BUILD_ROOT -type f -name .pack
find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';'
chmod -R u+w $RPM_BUILD_ROOT/*
-mkdir _docs ; mv $RPM_BUILD_ROOT%{_datadir}/tt2/docs _docs
# Nuke buildroot where it hides
-sed -i s|$RPM_BUILD_ROOT||g $RPM_BUILD_ROOT%{_datadir}/tt2/examples/ttree.cfg
sed -i s|$RPM_BUILD_ROOT||g
$RPM_BUILD_ROOT%{perl_vendorarch}/Template/Config.pm
%check
@@ -77,23 +74,47 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
-%doc Changes HACKING README TODO _docs/*
+%doc Changes HACKING README TODO TT_v*_html_docs/*
%{_bindir}/tpage
%{_bindir}/ttree
%{perl_vendorarch}/Template.pm
%{perl_vendorarch}/auto/Template
%{perl_vendorarch}/Template
-%{_datadir}/tt2
-# The examples get their own package due to size.
-%exclude %{_datadir}/tt2/examples
%{_mandir}/man1/*.1*
%{_mandir}/man3/*.3*
-%files examples
-%defattr(-,root,root,-)
-%{_datadir}/tt2/examples
-
%changelog
+* Fri Jan 15 2010 Stepan Kasal ska...@redhat.com - 2.22-3
+- drop build requirements for TeX; LaTeX support has been removed in 2.14a
+- fix the Obsoletes tag
+
+* Fri Dec 4 2009 Stepan Kasal ska...@redhat.com - 2.22-2
+- rebuild against perl 5.10.1
+
+* Sat Jul 25 2009 Tom spot Callaway tcall...@redhat.com - 2.22-1
+- update to 2.22
+- obsolete examples package, upstream got rid of them
+
+* Fri Mar 13 2009 Tom spot Callaway tcall...@redhat.com - 2.20-1
+- update
rpms/perl-Template-Toolkit/EL-4 perl-Template-Toolkit.spec, 1.6, 1.7 sources, 1.2, 1.3
Author: spot
Update of /cvs/pkgs/rpms/perl-Template-Toolkit/EL-4
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv26147/EL-4
Modified Files:
perl-Template-Toolkit.spec sources
Log Message:
2.22 for EPEL
Index: perl-Template-Toolkit.spec
===
RCS file: /cvs/pkgs/rpms/perl-Template-Toolkit/EL-4/perl-Template-Toolkit.spec,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -p -r1.6 -r1.7
--- perl-Template-Toolkit.spec 26 Aug 2007 22:18:11 - 1.6
+++ perl-Template-Toolkit.spec 26 Jan 2010 14:53:05 - 1.7
@@ -1,20 +1,21 @@
Name: perl-Template-Toolkit
-Version:2.14
-Release:8%{?dist}
+Version:2.22
+Release:3%{?dist}
Summary:Template processing system
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://www.template-toolkit.org/
Source0:
http://search.cpan.org/CPAN/authors/id/A/AB/ABW/Template-Toolkit-%{version}.tar.gz
-#Patch0:https://rt.cpan.org/NoAuth/Bug.html?id=7864
-Patch0: %{name}-gdpngtest.patch
+Source1:http://tt2.org/download/TT_v222_html_docs.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-BuildRequires: perl = 1:5.6.1, tetex-dvips, tetex-latex
+BuildRequires: perl(Test::More)
BuildRequires: perl(AppConfig), perl(Text::Autoformat), perl(GD::Graph3d),
perl(GD::Graph)
BuildRequires: perl(GD::Text), perl(Image::Info), perl(Image::Size),
perl(Pod::POM)
BuildRequires: perl(XML::DOM), perl(XML::RSS), perl(XML::XPath)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+Provides: perl-Template-Toolkit-examples = %{version}-%{release}
+Obsoletes: perl-Template-Toolkit-examples 2.22-1
%description
The Template Toolkit is a collection of modules which implement a
@@ -24,18 +25,10 @@ dynamic web content, but it can be used
any other kind of text based documents: HTML, XML, POD, PostScript,
LaTeX, and so on.
-%package examples
-Summary:Examples of how to use Template Toolkit
-Group: Documentation
-Requires: %{name} = %{version}-%{release}
-
-%description examples
-%{summary}.
-
%prep
-%setup -q -n Template-Toolkit-%{version}
-%patch0 -p0
+%setup -q -n Template-Toolkit-%{version} -a 1
find lib -type f | xargs chmod -c -x
+find TT_v*_html_docs -depth -name .svn -type d -exec rm -rf {} \;
# Filter false positive provides.
cat EOF %{name}-prov
@@ -49,13 +42,16 @@ EOF
%define __perl_provides %{_builddir}/Template-Toolkit-%{version}/%{name}-prov
chmod +x %{__perl_provides}
+# Convert file to UTF-8
+iconv -f iso-8859-1 -t utf-8 -o Changes{.utf8,}
+mv Changes{.utf8,}
+
%build
CFLAGS=$RPM_OPT_FLAGS %{__perl} Makefile.PL INSTALLDIRS=vendor \
- TT_PREFIX=$RPM_BUILD_ROOT%{_datadir}/tt2 TT_DBI=n TT_ACCEPT=y
+ TT_DBI=n TT_ACCEPT=y
make %{?_smp_mflags} OPTIMIZE=$RPM_OPT_FLAGS
%install
-rm -rf $RPM_BUILD_ROOT _docs
# install (+ INSTALLARCHLIB) instead of pure_install to get docs
# and the template library installed too
make install \
@@ -67,12 +63,9 @@ find $RPM_BUILD_ROOT -type f -name .pack
find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';'
chmod -R u+w $RPM_BUILD_ROOT/*
-mkdir _docs ; mv $RPM_BUILD_ROOT%{_datadir}/tt2/docs _docs
# Nuke buildroot where it hides
-sed -i s|$RPM_BUILD_ROOT||g $RPM_BUILD_ROOT%{_datadir}/tt2/examples/ttree.cfg
sed -i s|$RPM_BUILD_ROOT||g
$RPM_BUILD_ROOT%{perl_vendorarch}/Template/Config.pm
-
%check
make test
@@ -81,23 +74,57 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
-%doc Changes HACKING README TODO _docs/*
+%doc Changes HACKING README TODO TT_v*_html_docs/*
%{_bindir}/tpage
%{_bindir}/ttree
%{perl_vendorarch}/Template.pm
%{perl_vendorarch}/auto/Template
%{perl_vendorarch}/Template
-%{_datadir}/tt2
-# The examples get their own package due to size.
-%exclude %{_datadir}/tt2/examples
%{_mandir}/man1/*.1*
%{_mandir}/man3/*.3*
-%files examples
-%defattr(-,root,root,-)
-%{_datadir}/tt2/examples
-
%changelog
+* Fri Jan 15 2010 Stepan Kasal ska...@redhat.com - 2.22-3
+- drop build requirements for TeX; LaTeX support has been removed in 2.14a
+- fix the Obsoletes tag
+
+* Fri Dec 4 2009 Stepan Kasal ska...@redhat.com - 2.22-2
+- rebuild against perl 5.10.1
+
+* Sat Jul 25 2009 Tom spot Callaway tcall...@redhat.com - 2.22-1
+- update to 2.22
+- obsolete examples package, upstream got rid of them
+
+* Fri Mar 13 2009 Tom spot Callaway tcall...@redhat.com - 2.20-1
+- update to 2.20
+
+* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.19-5
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
+
+* Wed Feb 27 2008 Tom spot Callaway tcall...@redhat.com - 2.19-4
+- Rebuild for perl 5.10 (again)
+
+* Tue Feb 19 2008 Fedora Release Engineering rel-...@fedoraproject.org -
