let you specify a suffix, the most
expedient thing to do may be just to hack it on. But an upstream-worthy
patch would add a means to specify an arbitrary suffix. Also, -mt is a
saner default than no suffix at all.
--
Braden McDaniel
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
installed by default. If you want
it, you know how to get it. And let's be frank: emacs is not something
that a user who is unaware of it might stumble into and suddenly find
himself blindingly productive. (Nor, for that matter, is vi.)
--
Braden McDaniel
--
fedora-devel-list mailing
tinue Require -unstable which will
> make it a heck of a lot easier to figure out what to rebuild...
+1
Putting the unstable API in a separate package also makes it a bit
harder for developers using Fedora as their development platform to
naively rely on the unstable API.
--
Braden McDa
On Sun, 2009-11-15 at 10:35 +0100, Thomas Janssen wrote:
> 2009/11/15 Braden McDaniel :
[snip]
> > Did my previous "make tag" actually succeed?
>
> But not for your spec file. You could increase the Release version in
> your spec file, commit the changes, and r
vel:braden:1258273475
cvs tag: Pre-tag check failed
cvs [tag aborted]: correct the above errors first!
Uh oh.
Did my previous "make tag" actually succeed?
--
Braden McDaniel
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/l
On Sat, 2009-09-12 at 19:05 -0400, Tom "spot" Callaway wrote:
> On 09/12/2009 05:45 PM, Braden McDaniel wrote:
> > ... it *does* work like I think it works. xulrunner and openjdk are
> > broken.
>
> So, here's the deal.
>
> The only Provides which aut
ey make
the specfile less correct and openvrml is susceptible to the problem
documented in the aforementioned fedora-devel thread. It would be
better if xulrunner and openjdk were fixed instead (bugs 517665 and
517666, respectively).
--
Braden McDaniel
--
fedora-devel-list mailing list
fedora-d
p ^gtk
> gtk2 = 2.16.5-1.fc11
> gtk2(x86-32) = 2.16.5-1.fc11
>
> but not for virtual ones. gecko-libs and gecko-devel are *still* only
> virtual packages defined manually within the xulrunner.spec
So is there a reason why that must be the case?
It's been suggested (by Chr
#x27;s hard to be sure what's
> > authoritative.
>
> Just -lpthread does the trick for me. The -pthread option is needed on other
> platform, not Linux.
>From "man 7 pthreads":
On Linux, programs that use the Pthreads API should be compiled using
cc
seems that the provider of gecko-libs needs
to make it arch-specific as well.
I've filed bug 517665 against xulrunner and bug 517666 against
java-1.6.0-openjdk.
--
Braden McDaniel e-mail:
<http://endoframe.com> Jabber:
--
fedora-devel-list mai
On Thu, 2009-07-23 at 23:26 -0700, Toshio Kuratomi wrote:
> On 07/23/2009 06:43 PM, Braden McDaniel wrote:
> > On Tue, 2009-07-21 at 13:35 -0400, Tom "spot" Callaway wrote:
> >> On 07/21/2009 12:06 PM, Braden McDaniel wrote:
> >>> On Mon, 2009-0
e *server* is
> running F12 alpha and clients are running something older. This
> definitely doesn't fit into the alpha criteria :)
The bug also impacts clients that have been upgraded (with or without
upgrading the server). At least that's the case with F11.
--
Braden McDaniel
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Tue, 2009-07-21 at 13:35 -0400, Tom "spot" Callaway wrote:
> On 07/21/2009 12:06 PM, Braden McDaniel wrote:
> > On Mon, 2009-07-20 at 20:11 -0700, Jesse Keating wrote:
> >
> > [snip]
> >
> >> Orphan: pcmanx-gtk2
> >> gnash-plugin req
On 7/23/09 2:50 PM, Seth Vidal wrote:
On Thu, 23 Jul 2009, Matthew Woehlke wrote:
Seth Vidal wrote:
On Thu, 23 Jul 2009, Braden McDaniel wrote:
But why does yum assume that a dependency of an x86_64 package can be
satisfied by an i586 one?
Why not?
If something requires FOO and
On Thu, 2009-07-23 at 11:59 -0400, Seth Vidal wrote:
>
> On Thu, 23 Jul 2009, Braden McDaniel wrote:
>
> >
> > Is the problem that the gecko-libs dependency is not arch-specific?
>
> Not necessarily.
Well, there are a few more candidate dependencies; but that see
On Thu, 2009-07-23 at 11:41 -0400, Seth Vidal wrote:
>
> On Thu, 23 Jul 2009, Braden McDaniel wrote:
>
> > On Thu, 2009-07-23 at 23:26 +0900, Mamoru Tasaka wrote:
> >
> > [snip]
> >
> >> rel-eng team is now working on this:
> >> https://fedora
On Thu, 2009-07-23 at 23:26 +0900, Mamoru Tasaka wrote:
[snip]
> rel-eng team is now working on this:
> https://fedorahosted.org/rel-eng/ticket/2008
Er... So why did a missing update result in pulling down i586 packages
rather than a dependency check failure?
--
Braden McDaniel
--
)
Remove 0 Package(s)
--
Braden McDaniel
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
On 7/21/09 1:35 PM, Tom "spot" Callaway wrote:
On 07/21/2009 12:06 PM, Braden McDaniel wrote:
On Mon, 2009-07-20 at 20:11 -0700, Jesse Keating wrote:
[snip]
Orphan: pcmanx-gtk2
gnash-plugin requires /usr/lib/mozilla/plugins
gnome-chemistry-utils-mozplugin requires /usr/l
t.
The package already "Requires: xulrunner"; which requires
mozilla-filesystem, which is what owns %{_libdir}/mozilla/plugins.
(Not that owning this directory is reasonably even if it didn't already
have this dependency.)
--
Braden McDaniel
--
fedora-devel-list mailing l
On Tue, 2009-07-07 at 01:17 -0700, Toshio Kuratomi wrote:
> On 07/06/2009 08:09 PM, Braden McDaniel wrote:
> > On Mon, 2009-07-06 at 16:36 -0700, Toshio Kuratomi wrote:
> >> On 07/06/2009 03:57 PM, Braden McDaniel wrote:
> >>> On 7/6/09 6:10 PM, Toshio Kur
On Tue, 2009-07-07 at 14:01 +0200, Kevin Kofler wrote:
> Braden McDaniel wrote:
> > Breaking compatibility with previous versions of automake, autoconf, or
> > libtool has no impact on released tarballs made using those tools; they
> > continue to work as intended because they
On Tue, 2009-07-07 at 02:02 +0200, Kevin Kofler wrote:
> Braden McDaniel wrote:
> > The number of people chiming in on this thread to the effect, "I've
> > regenerated configure/Makefile.in for years and I've never had a
> > problem," is testament t
On Mon, 2009-07-06 at 16:36 -0700, Toshio Kuratomi wrote:
> On 07/06/2009 03:57 PM, Braden McDaniel wrote:
> > On 7/6/09 6:10 PM, Toshio Kuratomi wrote:
> >
> > [snip]
> >
> >> Introducing side-effects is something to watch out for but
> >> patch
asures.
Regenerating the build system is the antithesis of providing surgical
patches to solve a problem. More often than not in package maintenance,
"nuke 'em from orbit" is *not* the *only* way to be sure.
--
Braden McDaniel e-mail:
<http://endoframe.co
indefinitely suggests broken maintainership somewhere along the
line--either upstream, of the Fedora package in question, or elsewhere
in Fedora's infrastructure.
--
Braden McDaniel e-mail:
<http://endoframe.com> Jabber:
--
fedora-devel-list mailing list
f
* for released versions of Fedora. Special
circumstances that might prompt such a move can always be discussed, of
course. But this sort of thing incurs way too much risk.
--
Braden McDaniel e-mail:
<http://endoframe.com> Jabber:
--
fedora-devel-list m
that's true and I'm not asserting that it is.
But surely this argument should be framed in terms of the benefit and
cost to Fedora users (and potential Fedora users).
--
Braden McDaniel e-mail:
<http://endoframe.com> Jabber:
--
fedo
On Mon, 1 Jun 2009, Kevin Kofler wrote:
Muayyad AlSadi wrote:
I filed a bug report about it, and devels added an option to make it
works with libraries only
And how do you define "library"? There's no reliable way to distinguish them
from applications.
This is part of the problem. It woul
29 matches
Mail list logo
