On Sat, Jul 02, 2011 at 20:05:53 +0200,
Eric Tanguy eric.tan...@gmail.com wrote:
Thanks for the suggestion. I have already tried the new version with the
same errors.
I eventually noticed that in the bug report as well. I think not using tr1
to provide complex functions is the way to go in
On Sun, Jul 03, 2011 at 08:10:25 -0500,
Bruno Wolff III br...@wolff.to wrote:
the normal complex definitions. But I think I have a simple hack to do
it now. The test build is still running, but if it works I'll post the
patches to the bug.
The test build completed. I didn't actually try
Hello,
I need help with a package[0] that needs autoconf to be called before
the build can begin. I've read this draft which addresses the issue[1].
I used the second solution which says:
When manual modification of configure or Makefile.in for the purpose of
generating a patch is impractical,
On Wed, 2011-06-29 at 13:48 +0200, Björn Persson wrote:
Miloslav Trmač wrote:
First, the TPM (nor the CPU) really can't tell the difference between
the owner of the computer and an author of a virus.
A jumper on the motherboard, or some other kind of physical circuit breaker,
can do
Ankur Sinha sanjay.an...@gmail.com writes:
I need help with a package[0] that needs autoconf to be called before
the build can begin. I've read this draft which addresses the issue[1].
I used the second solution which says:
When manual modification of configure or Makefile.in for the purpose
On 07/03/2011 10:34 PM, Kevin Kofler wrote:
FWIW, I think we should actually run autoreconf -i -f in ALL specfiles as a
matter of policy, even if we aren't changing anything, the same way we
require Java JARs to be rebuilt from source.
please no!
curently most of the fedora packages can be
Hi,
I'm going to deprecate podsleuth and ipod-sharp in rawhide.
Banshee has switched to libgpod(-sharp) and no other package depends on
these two packages.
Are there any objections?
Best regards,
Christian
--
devel mailing list
devel@lists.fedoraproject.org
Thanks. But the GNU build system don't require or need this by definition,
Regards
Messaggio originale
Da: Kevin Kofler
Inviato: 03/07/2011, 22:34
A: devel@lists.fedoraproject.org
Oggetto: Re: R: Re: Calling autoconf in a spec.
pinto.e...@gmail.com wrote:
First of all Sorry for not
Kevin Kofler writes:
Sam Varshavchik wrote:
Ok, then when you patch configure.in, configure.ac, and/or Makefile.am, be
sure to also specify:
BuildRequires: autoconf=[version]
and
BuildRequires: automake=[version]
in order to have a reproducible build.
Nonsense. Even many upstreams do
Kevin Kofler writes:
drago01 wrote:
Exactly patching generated code is just wrong period.
+1. It's also a violation of the GPL (for GPLed projects), because you
aren't changing the preferred form for modification.
Indeed. How dare do those upstreams publish files containing non-preferred
Hi folks,
Thanks all for the input. I didn't realize the subject was *this*
controversial. I did find the other discussion thread[1] which was aimed
at completing the draft I had linked to, and as you'll notice it was
inconclusive. I was hoping something had changed (the thread dates back
to
Sam Varshavchik wrote:
Kevin Kofler writes:
Sam Varshavchik wrote:
Ok, then when you patch configure.in, configure.ac, and/or Makefile.am,
be sure to also specify:
BuildRequires: autoconf=[version]
and
BuildRequires: automake=[version]
in order to have a reproducible
Sam Varshavchik wrote:
Indeed. How dare do those upstreams publish files containing non-preferred
form for modifications, in their tarballs?
The GPL doesn't ban shipping generated files as long as they're accompanied
by their source code. It does ban editing only the generated files without a
On Mon, Jul 04, 2011 at 06:31:18AM +0530, Ankur Sinha wrote:
Hi folks,
Thanks all for the input. I didn't realize the subject was *this*
controversial. I did find the other discussion thread[1] which was aimed
at completing the draft I had linked to, and as you'll notice it was
On 07/03/2011 10:31 PM, Kevin Kofler wrote:
Sam Varshavchik wrote:
Ok, then when you patch configure.in, configure.ac, and/or Makefile.am, be
sure to also specify:
BuildRequires: autoconf=[version]
and
BuildRequires: automake=[version]
in order to have a reproducible build.
Correct. The
Kevin Kofler kevin.kof...@chello.at writes:
And in addition, I consider the concept of including generated files in
what's supposed to be a source tarball to be broken by design. A source
tarball is supposed to contain SOURCE code, not generated code. Anything
needing to be generated should
Tom Lane wrote:
That sounds more like dogmatism than practical thinking. It's common to
pre-generate some of the files in a distribution tarball, just so that
users aren't required to have specific tools in order to build the code
(unless they want to modify the input files for those tools,
Kevin Kofler kevin.kof...@chello.at writes:
Tom Lane wrote:
That sounds more like dogmatism than practical thinking. It's common to
pre-generate some of the files in a distribution tarball, just so that
users aren't required to have specific tools in order to build the code
(unless they want
Kevin Kofler writes:
Sam Varshavchik wrote:
Can you translate that. It's nonsense because many upstreams do that?
Oops, I forgot the most important word. :-(
Nonsense. Even many upstreams DON'T do that.
Only very few upstreams use a specific version of autoconf and/or automake,
most
Kevin Kofler writes:
And in addition, I consider the concept of including generated files in
what's supposed to be a source tarball to be broken by design. A source
tarball is supposed to contain SOURCE code, not generated code. Anything
needing to be generated should be generated during the
On Sun, Jul 03, 2011 at 22:30:01 +0200,
Eric Tanguy eric.tan...@gmail.com wrote:
Could you help me for this problem also ?
I can take a look at it, but probably not for a few days.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 07/04/2011 04:37 AM, Toshio Kuratomi wrote:
On Mon, Jul 04, 2011 at 06:31:18AM +0530, Ankur Sinha wrote:
Hi folks,
Thanks all for the input. I didn't realize the subject was *this*
controversial. I did find the other discussion thread[1] which was aimed
at completing the draft I had
On 07/04/2011 06:18 AM, Peter Hutterer wrote:
Please give some karma to
https://admin.fedoraproject.org/updates/xorg-x11-drv-wacom-0.11.1-1.fc15
This update has been in testing since May 30, the daily reminder emails are
starting to get annoying.
Thanks.
Done
Rahul
--
devel mailing list
A file has been added to the lookaside cache for perl-DateTime:
5866f392d011f2579168c427231cc569 DateTime-TimeZone-1.35.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
commit 7c7919cf2d9797ea93fb14e0c08b68c57b16ede1
Author: Iain Arnell iarn...@gmail.com
Date: Mon Jul 4 06:26:59 2011 +0200
update DateTime::TimeZone to 1.35 (Olson 2011h)
.gitignore |1 +
perl-DateTime.spec |7 +--
sources|2 +-
3 files changed, 7
Summary of changes:
7c7919c... update DateTime::TimeZone to 1.35 (Olson 2011h) (*)
2815e75... add rpm 4.9 filtering macros (*)
(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel
Summary of changes:
7c7919c... update DateTime::TimeZone to 1.35 (Olson 2011h) (*)
2815e75... add rpm 4.9 filtering macros (*)
(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel
commit 2815e75fc30244e4d6c9f864b1069c3bd3d5aa5a
Author: Iain Arnell iarn...@gmail.com
Date: Mon Jul 4 06:28:14 2011 +0200
add rpm 4.9 filtering macros
perl-DateTime.spec |4
1 files changed, 4 insertions(+), 0 deletions(-)
---
diff --git a/perl-DateTime.spec b/perl-DateTime.spec
28 matches
Mail list logo
