Hello,
I'm just updating evolution-data-server to 3.11.5 in rawhide, which
includes a soname version bump for libcamel. I'm sorry for a late
notice, this was meant to be sent the last week.
I'll rebuild all affected packages I have commit rights for.
Bye,
Milan
--
devel m
On Thu, 2014-01-30 at 11:19 +0100, Mikolaj Izdebski wrote:
> In order to have proper versioning release tag should also be
> increased
> in consecutive builds.
Hi Radek,
Can you please check if the repodata is being generated properly? I can
see dnf-0.4.12-1.git8c69fa2.fc20.noarch.rpm in my web b
On Sun, 2014-02-02 at 21:01 -0500, Paul Wouters wrote:
>
> The target install: yum install kvm actually installs only
> qemu-system-x*86
> but not qemu-kvm or libvirtd-daemon-kvm.
That seems correct. qemu-system-x86 is the only package that provides
'kvm' according to yum whatprovides 'kvm'
>
>
On Sat, 1 Feb 2014, Adam Williamson wrote:
You can't do a text install from a live image, but you can from DVD or net
inst. We'd need the x logs to know what was going on with x startup.
ftp://ftp.nohats.ca/Xorg.0.log
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fed
The EL6 build of llvm 3.4 is currently in testing and it was just pointed
out that there's a potential issue with the build (
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0264/llvm-3.4-5.el6).
If you examine the build.log (
http://kojipkgs.fedoraproject.org//work/tasks/593/6470593/buil
I don't believe mere mortals posses the capability to remove a
Bugzilla account once established.
The administrator might be able.
I guess you could change the email associated with your username in BZ
to some bogus address, effectively disabling the account.
good luck,
-Jon Disnard
On Sun, Feb
The target install: yum install kvm actually installs only qemu-system-x*86
but not qemu-kvm or libvirtd-daemon-kvm.
Should not those be added to the kvm target?
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduc
Thanks.
poma
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Feb 2, 2014, at 5:34 PM, Ralf Corsepius wrote:
> On 02/02/2014 11:57 PM, Robert Mayr wrote:
>> 2014-02-02 Kevin Kofler :
>>> Adam Williamson wrote:
We can have a KDE Product, and an Xfce Product, and an LXDE Product,
but...at that point haven't we just re-invented spins? It doesn't
On 02/02/2014 11:57 PM, Robert Mayr wrote:
2014-02-02 Kevin Kofler :
Adam Williamson wrote:
We can have a KDE Product, and an Xfce Product, and an LXDE Product,
but...at that point haven't we just re-invented spins? It doesn't seem
to quite work with the Product conception.
Why not?
I see on
On Feb 2, 2014, at 2:54 PM, Ralf Corsepius wrote:
> On 02/02/2014 07:26 PM, Chris Murphy wrote:
>>
>> On Feb 2, 2014, at 6:33 AM, Solomon Peachy wrote:
>>
>>> On Sat, Feb 01, 2014 at 11:06:18PM +0100, Kevin Kofler wrote:
I don't understand why we are doing that "Fedora.NEXT" thing in the
2014-02-02 Kevin Kofler :
> Adam Williamson wrote:
>> We can have a KDE Product, and an Xfce Product, and an LXDE Product,
>> but...at that point haven't we just re-invented spins? It doesn't seem
>> to quite work with the Product conception.
>
> Why not?
>
> I see only 2 acceptable outcomes, eithe
PS:
I wrote:
> Adam Williamson wrote:
> The KDE spin has always been a release-blocking deliverable, why should we
> get degraded to a second-class citizen?
Sorry, poor choice of words there: The KDE spin has been a release-blocking
deliverable for years. This hasn't ALWAYS been the case, in fa
Adam Williamson wrote:
> We can have a KDE Product, and an Xfce Product, and an LXDE Product,
> but...at that point haven't we just re-invented spins? It doesn't seem
> to quite work with the Product conception.
Why not?
I see only 2 acceptable outcomes, either KDE becomes a Product or the whole
Chris Murphy wrote:
> I think this is a good summary of what it's all about and what it isn't.
>
> https://www.happyassassin.net/2014/01/31/good-morning-bugfixing-and-thinking-about-fedora-next/
Yikes, one more step away from flexibility and towards a proprietary "one
size fits it all" experience
On 02/02/2014 07:26 PM, Chris Murphy wrote:
On Feb 2, 2014, at 6:33 AM, Solomon Peachy wrote:
On Sat, Feb 01, 2014 at 11:06:18PM +0100, Kevin Kofler wrote:
I don't understand why we are doing that "Fedora.NEXT" thing in the
first place. It's a lot of change for the sake of change, without an
Solomon Peachy wrote:
> So far the only tangible result is that the release date for F21 is
> delayed (which is probably a good thing)
It's not. As you say yourself:
> A longer release cadence means we lose the 'First' goal (both in the
> First-to-market and Upstream-First sense), and the main ben
On Sun, Feb 02, 2014 at 11:26:06AM -0700, Chris Murphy wrote:
> > For what my opinion is worth (as someone who's been around since the
> > RHL4.1 days) I have to agree.
>
> I think this is a good summary of what it's all about and what it isn't.
>
> https://www.happyassassin.net/2014/01/31/good
Hi, folks! Sorry for forgetting to send this out earlier.
We have a meeting slot on Monday, but I'm not aware of any major topics
that need discussion - is there anything I'm missing?
For now I'm proposing we cancel the meeting. If someone has an agenda
topic, please do reply to this mail, or eve
On Feb 2, 2014, at 6:33 AM, Solomon Peachy wrote:
> On Sat, Feb 01, 2014 at 11:06:18PM +0100, Kevin Kofler wrote:
>> I don't understand why we are doing that "Fedora.NEXT" thing in the
>> first place. It's a lot of change for the sake of change, without any
>> idea whether the output will be b
On Sat, Feb 01, 2014 at 11:06:18PM +0100, Kevin Kofler wrote:
> I don't understand why we are doing that "Fedora.NEXT" thing in the
> first place. It's a lot of change for the sake of change, without any
> idea whether the output will be better than the status quo, or even
> whether there will b
Compose started at Sun Feb 2 05:15:08 UTC 2014
Broken deps for i386
--
[OpenEXR_CTL]
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libImath.so.6
OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmThread.so.6
OpenEXR_CTL-1.0.1-16
22 matches
Mail list logo
