ltsp-5.2.4-5.rpm's ready for testing (i686 & x86_64)

2010-09-11 Thread Gavin Spurgeon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi LTSP/Fedora Community. I now have a fully working copy of LTSP for both i686 & x86_64 The New .rpm's are still located on my www server, and to make things a little easier I have also made a Yum Repo for both archs as well. The .repo file is @

rawhide report: 20100911 changes

2010-09-11 Thread Rawhide Report
Compose started at Sat Sep 11 08:15:17 UTC 2010 Broken deps for x86_64 -- antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 avogadro-libs-1.0.1-6.fc15.i686 requires sip-api(7) >= 0:7.1 avogadro-libs-1.0.1-

Re: ltsp-5.2.4-5.rpm's ready for testing (i686 & x86_64)

2010-09-11 Thread Chuck Anderson
Would you care to create a repo on repos.fedorapeople.org? http://repos.fedorapeople.org/ On Sat, Sep 11, 2010 at 10:58:16AM +0100, Gavin Spurgeon wrote: > The New .rpm's are still located on my www server, and to make things a > little easier I have also made a Yum Repo for both archs as well. >

Simultaneous Fedora and upstream git usage

2010-09-11 Thread Andy Shevchenko
Every one who is use a git everyday knows that it has support of joining several repositories in one local repository (especially if it has a common base). I would use such feature for packages hosted in git repositories. So, the idea is to keep 2-in-1: - Fedora's git as a holder and main reposito

non-responsive maintainer: thomasvs (2nd attempt)

2010-09-11 Thread Julian Sikorski
Dear all, I unfortunately have to start the non-responsive process for thomasvs again [1]. The bug to update twisted to the latest upstream version has been opened for several months now [2], and I have also prepared the updates myself on a fedorapeople repo [3]. In the bug report, all responses w

non-responsive maintainer: thomasvs (2nd attempt)

2010-09-11 Thread Julian Sikorski
Dear all, I unfortunately have to start the non-responsive process for thomasvs again [1]. The bug to update twisted to the latest upstream version has been opened for several months now [2], and I have also prepared the updates myself on a fedorapeople repo [3].In the bug report, all responses we

are nightly-composes/desktop/ built from F14 branch?

2010-09-11 Thread Marius Andreiana
Hello, We're wondering if http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ are built from F14 branch or rawhide. Could somebody clarify this? Reason: A fix for https://bugzilla.redhat.com/show_bug.cgi?id=528232 was committed, but it doesn't appear fixed. Thanks, M -- devel mailing

Re: Simultaneous Fedora and upstream git usage

2010-09-11 Thread Adam Williamson
On Sat, 2010-09-11 at 18:30 +0300, Andy Shevchenko wrote: > Every one who is use a git everyday knows that it has support of > joining several repositories in one local repository (especially if it > has a common base). I would use such feature for packages hosted in > git repositories. > So, the i

Re: are nightly-composes/desktop/ built from F14 branch?

2010-09-11 Thread Adam Williamson
On Sun, 2010-09-12 at 00:43 +0300, Marius Andreiana wrote: > Hello, > > We're wondering if > http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ > are built from F14 branch or rawhide. Could somebody clarify this? dist-f14. > Reason: A fix for https://bugzilla.redhat.com/show_bug.cgi?

Re: Simultaneous Fedora and upstream git usage

2010-09-11 Thread Ben Boeckel
Adam Williamson wrote: > I think it's already been proposed on -devel as a logical extension of > the current system. I can't recall exactly when or by who, though, > sorry. What I remember from FUDCon Toronto was that fedpkg could download the tarball, explode it into /tmp or something, do a `gi

Re: Simultaneous Fedora and upstream git usage

2010-09-11 Thread Andy Shevchenko
On Sun, Sep 12, 2010 at 2:35 AM, Ben Boeckel wrote: > What I remember from FUDCon Toronto was that fedpkg could download the > tarball, explode it into /tmp or something, do a `git init; git commit > -a -m "Tarball"` and then there'd be some way to export patches on top > of this commit back into