Compose started at Sun Jul 3 08:15:32 UTC 2011
Broken deps for x86_64
--
acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell)
audacious-plugin-xmp-3.3.0-7.fc16.x86_64 requires audacious(plugin-api)
= 0:19
bibletime
On Sat, Jul 02, 2011 at 20:05:53 +0200,
Eric Tanguy 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 the short run. Trying
On Sun, Jul 03, 2011 at 08:10:25 -0500,
Bruno Wolff III 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 running the prog
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, p
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
Ankur Sinha 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 of
> generating a
Tom Lane writes:
Ankur Sinha 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 purpos
Sam Varshavchik writes:
> To add to that: I never recall a single instance where I couldn't fix any
> breakage in someone else's canned configure/makefile scripts without having
> to rerun autoconf and automake.
> If there was a problem in the configure script, rather than patching
> config
On Sun, Jul 3, 2011 at 7:31 PM, Tom Lane wrote:
> Sam Varshavchik writes:
>> To add to that: I never recall a single instance where I couldn't fix any
>> breakage in someone else's canned configure/makefile scripts without having
>> to rerun autoconf and automake.
>
>> If there was a problem in t
drago01 writes:
On Sun, Jul 3, 2011 at 7:31 PM, Tom Lane wrote:
> Sam Varshavchik writes:
>> To add to that: I never recall a single instance where I couldn't fix any
>> breakage in someone else's canned configure/makefile scripts without
having
>> to rerun autoconf and automake.
>
>> If th
First of all Sorry for not quoting. It is just for telling an opinion from
someone that know the autofu well, almost. For me this idea of patching
generated autofu is wrong. if i have to patching the GNU build system there is
a reason of course. Which reason is right for a packager ? Imho in ma
Ankur Sinha wrote:
> 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:
> [1] http://fedoraproject.org/wiki/PackagingDrafts/AutoConf
That draft is a draft for a re
Le 03/07/2011 15:33, Bruno Wolff III a écrit :
> On Sun, Jul 03, 2011 at 08:10:25 -0500,
>Bruno Wolff III 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
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.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraprojec
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 that. (I k
pinto.e...@gmail.com wrote:
> First of all Sorry for not quoting. It is just for telling an opinion from
> someone that know the autofu well, almost. For me this idea of patching
> generated autofu is wrong. if i have to patching the GNU build system
> there is a reason of course. Which reason is
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
https://admin.fedoraproject.org/mai
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 ups
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
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.
Cheers,
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedo
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 2008)
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 o
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
> inconcl
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
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 durin
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 writes:
> 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,
To what end? If you need to change configure.ac, that's one thing ...
but if you don't, you're just uselessly exposing yourself to risks.
Kevin Kofler 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 to modify the
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 upst
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 bui
On Sun, Jul 03, 2011 at 22:30:01 +0200,
Eric Tanguy 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
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
Sam Varshavchik wrote:
> Well, to me it makes much more sense to simply eliminate the uncertainty
> from the process. If I take the tarball that I'm going to build today, if
> I have to rebuild it next year, of a few years from -- the tarball will
> remain the same. It's not going to change. Simila
On 09:34:10 AM Saturday, July 02, 2011 Michał Piotrowski wrote:
> Hi,
>
> Are there any plans to provide PostgreSQL 9.1 in Fedora 16? PostgreSQL
> 9.1 is in beta2 now and it's scheduled for Q3 2011.
>
> It would be nice to see Lucene Core in F16. There is an old Lucene
> 2.9.x for F16 - the lates
Tom Lane wrote:
> I grow weary of debating this with somebody who can't recognize that his
> particular situation is not universal. Many people build code for
> themselves, for instance because their preferred platform isn't shipping
> the particular version of a package they want (or not shipping
39 matches
Mail list logo
