Am 08.12.2011 05:09, schrieb Kevin Kofler:
I know the post I'm replying to is off-topic, but just to clarify the part
which may be relevant for Fedora packages:
Reindl Harald wrote:
below a list of packages which i maintain locally
mots of them only cpu-optimized rebuilds
many of them
On Thu, 08 Dec 2011 11:07:10 +0100
Reindl Harald h.rei...@thelounge.net wrote:
but they are often way behind current versions (ffmpeg, x264,
open-vm-tools) and then throw out a new x264, rebuild all packages
depending on it and rais only from .114 to .115 is a bad joke
while .119 exists since
Am 08.12.2011 12:27, schrieb Stijn Hoop:
On Thu, 08 Dec 2011 11:07:10 +0100
Reindl Harald h.rei...@thelounge.net wrote:
but they are often way behind current versions (ffmpeg, x264,
open-vm-tools) and then throw out a new x264, rebuild all packages
depending on it and rais only from .114 to
Reindl Harald wrote:
my only changes was compile the x264.119 and fake the so-number
in the sources to .102 for F13/F14 and to .114/.115 for F15
and currently the .120 to 115
Changing soversions is a very bad idea, upstream probably bumped them for a
reason.
Kevin Kofler
--
devel
Am 08.12.2011 17:04, schrieb Kevin Kofler:
Reindl Harald wrote:
my only changes was compile the x264.119 and fake the so-number
in the sources to .102 for F13/F14 and to .114/.115 for F15
and currently the .120 to 115
Changing soversions is a very bad idea, upstream probably bumped them
On Thu, 08 Dec 2011 19:02:26 +0100
Reindl Harald h.rei...@thelounge.net wrote:
Am 08.12.2011 17:04, schrieb Kevin Kofler:
Reindl Harald wrote:
my only changes was compile the x264.119 and fake the so-number
in the sources to .102 for F13/F14 and to .114/.115 for F15
and currently the .120
2011/12/8 Reindl Harald h.rei...@thelounge.net:
Am 08.12.2011 17:04, schrieb Kevin Kofler:
Reindl Harald wrote:
my only changes was compile the x264.119 and fake the so-number
in the sources to .102 for F13/F14 and to .114/.115 for F15
and currently the .120 to 115
Changing soversions is
On Thu, Dec 8, 2011 at 11:23 AM, Reindl Harald h.rei...@thelounge.net wrote:
nonsense
they HAD the manpower to do this rebuilds for so.114 to so.115
so WTF why they jumping to a outdated version instead so.119?
doing such nonsense and after that whine about to few manpower
is a little bit
Am 08.12.2011 21:42, schrieb Jef Spaleta:
I'm saying this as politely as I can. Move this into the appropriate
rpmfusion development communication channel and out of here.
and i am saying it NOT polite
WAS I THE PERSON WHO RESTARTED THIS THREAD?
NO I WAS NOT!
so please pissoff people who
On Thu, 2011-12-08 at 21:55 +0100, Reindl Harald wrote:
Am 08.12.2011 21:42, schrieb Jef Spaleta:
I'm saying this as politely as I can. Move this into the appropriate
rpmfusion development communication channel and out of here.
and i am saying it NOT polite
WAS I THE PERSON WHO
Am 08.12.2011 22:03, schrieb Adam Williamson:
On Thu, 2011-12-08 at 21:55 +0100, Reindl Harald wrote:
Am 08.12.2011 21:42, schrieb Jef Spaleta:
I'm saying this as politely as I can. Move this into the appropriate
rpmfusion development communication channel and out of here.
and i am saying
I know the post I'm replying to is off-topic, but just to clarify the part
which may be relevant for Fedora packages:
Reindl Harald wrote:
below a list of packages which i maintain locally
mots of them only cpu-optimized rebuilds
many of them changed
* services MUST NOT restart while update
On 11/28/2011 12:47 PM, Chuck Ebbert wrote:
On Tue, 22 Nov 2011 10:06:32 -0800
Josh Stone jist...@redhat.com wrote:
On 11/22/2011 09:51 AM, Michael Cronenworth wrote:
-#if LINUX_VERSION_CODE KERNEL_VERSION(3, 1, 0)
It may have be helpful for the faked 2.6.4x kernels to still present a
On Mon, 2011-12-05 at 11:32 -0800, Josh Stone wrote:
On 11/28/2011 12:47 PM, Chuck Ebbert wrote:
On Tue, 22 Nov 2011 10:06:32 -0800
Josh Stone jist...@redhat.com wrote:
On 11/22/2011 09:51 AM, Michael Cronenworth wrote:
-#if LINUX_VERSION_CODE KERNEL_VERSION(3, 1, 0)
It may have
On 12/05/2011 01:05 PM, Sérgio Basto wrote:
Hi, Now I'm co-maintaining VirtualBox on rpmfusion
you got on my external link VB 4.1.4 for F15
http://www.serjux.com/virtualbox/
if you try it let me know ,
I grabbed and extracted just the kmodsrc, all the modules within now
build fine. So the
On Mon, 2011-12-05 at 15:41 -0800, Josh Stone wrote:
On 12/05/2011 01:05 PM, Sérgio Basto wrote:
Hi, Now I'm co-maintaining VirtualBox on rpmfusion
you got on my external link VB 4.1.4 for F15
http://www.serjux.com/virtualbox/
if you try it let me know ,
I grabbed and extracted just
On 12/05/2011 05:09 PM, Sérgio Basto wrote:
On Mon, 2011-12-05 at 15:41 -0800, Josh Stone wrote:
I grabbed and extracted just the kmodsrc, all the modules within now
build fine. So the new version information is doing the right thing,
representing itself as a normal 3.1 kernel internally.
On Tue, 22 Nov 2011 10:06:32 -0800
Josh Stone jist...@redhat.com wrote:
On 11/22/2011 09:51 AM, Michael Cronenworth wrote:
-#if LINUX_VERSION_CODE KERNEL_VERSION(3, 1, 0)
It may have be helpful for the faked 2.6.4x kernels to still present a
3ish LINUX_VERSION_CODE. AFAIK, faking the
On Tue, Nov 22, 2011 at 11:07 PM, Reindl Harald h.rei...@thelounge.net wrote:
that is not the point
You are missing the point as well. Regardless of whether or not you
have a valid gripe about rpmfusion's volunteer effort... this is
absolutely not the place to voice your concerns. It is very
Am 23.11.2011 02:23, schrieb Richard Shaw:
On Tue, Nov 22, 2011 at 2:07 PM, Rahul Sundaram methe...@gmail.com wrote:
On 11/22/2011 10:34 PM, Reindl Harald wrote:
so complain rpmfusion why they are ALWAYS behind the fedora-kernel-packages
and all their kmod and so on are making troubles days
On Mon, 2011-11-21 at 21:46 +0100, Reindl Harald wrote:
Am 21.11.2011 21:32, schrieb Till Maas:
Hi,
a recent kernel update[0] broke Fedora's ability to be a VirtualBox
host, because asm/amd_iommu.h was removed. The removal of the file was
noticed during testing, but it seems nobody
On 11/21/2011 09:32 PM, Till Maas wrote:
a recent kernel update[0] broke Fedora's ability to be a VirtualBox
host, because asm/amd_iommu.h was removed.
This is a part of the in-kernel API, not the kernel-userspace
interface. The internal API can change at any time.
External kernel modules can
On Mon, Nov 21, 2011 at 04:59:54PM -0800, Toshio Kuratomi wrote:
The updates policy is meant to protect users of Fedora within reason.
Compiling, writing, and using third party software on Fedora is a valid use
of Fedora whether or not that software exists within Fedora. This update
may be
Am 22.11.2011 01:59, schrieb Toshio Kuratomi:
The updates policy is meant to protect users of Fedora within reason.
Compiling, writing, and using third party software on Fedora is a valid use
of Fedora whether or not that software exists within Fedora. This update
may be acceptable because
On Tue, Nov 22, 2011 at 03:08:07PM +, Matthew Garrett wrote:
On Mon, Nov 21, 2011 at 04:59:54PM -0800, Toshio Kuratomi wrote:
The updates policy is meant to protect users of Fedora within reason.
Compiling, writing, and using third party software on Fedora is a valid use
of Fedora
On Tue, Nov 22, 2011 at 08:12:42AM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 03:08:07PM +, Matthew Garrett wrote:
We don't support out of tree kernel modules at all, so they're not
considered when making the determination about whether an update is
appropriate for a stable
On Tue, Nov 22, 2011 at 04:23:28PM +, Matthew Garrett wrote:
On Tue, Nov 22, 2011 at 08:12:42AM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 03:08:07PM +, Matthew Garrett wrote:
We don't support out of tree kernel modules at all, so they're not
considered when making the
2011/11/22 Matthew Garrett mj...@srcf.ucam.org:
The kernel ABI is the syscall interface, /sys and /proc. There is no
stable module ABI between kernels - even with a small security update,
the symbol versioning may change in such a way that the module ABI will
change. Given that any
On Tue, Nov 22, 2011 at 08:53:13AM -0800, Toshio Kuratomi wrote:
According to the updates policy the
maintainer needs to consider that their change will cause problems for third
party kernel module packagers and end users that are compiling their own
kernel modules.
We *know* we're going
On Tue, Nov 22, 2011 at 06:00:43PM +0100, 80 wrote:
The failure is due to Fedora *non-upstream* versionning scheme,
VirtualBox has *already* fixes the API/ABI issue upstream relying on
the kernel version (since 3.2 RC). It has nothing to do with the
kernel non-stable ABI policy (which is
On 11/22/2011 12:13 PM, Matthew Garrett wrote:
On Tue, Nov 22, 2011 at 06:00:43PM +0100, 80 wrote:
The failure is due to Fedora *non-upstream* versionning scheme,
VirtualBox has *already* fixes the API/ABI issue upstream relying on
the kernel version (since 3.2 RC). It has nothing to do
Genes MailLists wrote:
For those having trouble - one pragmatic way is just to download the
f16 3.1.x source rpm and rebuild it on F15 - VB will now work fine.
You don't need to do that. Just use my attached patch.
(Only use the patch on F15 systems with F15 kernels.)
---
Michael Cronenworth wrote:
Just use my attached patch.
It helps if I attach the correct patch.
--- /usr/share/virtualbox/src/vboxhost/vboxpci/linux/VBoxPci-linux.c.orig 2011-08-09 01:30:24.0 -0500
+++ /usr/share/virtualbox/src/vboxhost/vboxpci/linux/VBoxPci-linux.c 2011-11-22
On Tue, Nov 22, 2011 at 12:08:14PM -0500, Dave Jones wrote:
On Tue, Nov 22, 2011 at 08:53:13AM -0800, Toshio Kuratomi wrote:
According to the updates policy the
maintainer needs to consider that their change will cause problems for
third
party kernel module packagers and end users that
On Tue, Nov 22, 2011 at 09:55:59AM -0800, Toshio Kuratomi wrote:
So, yes, it may be fully expected that issuing an update will break out of
tree modules but that doesn't stop it from being one factor to *consider*.
Consideration implies that the following thought process will occur
This
On Tue, Nov 22, 2011 at 12:55 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
On Tue, Nov 22, 2011 at 12:08:14PM -0500, Dave Jones wrote:
On Tue, Nov 22, 2011 at 08:53:13AM -0800, Toshio Kuratomi wrote:
According to the updates policy the
maintainer needs to consider that their change will
2011/11/22 Dave Jones da...@redhat.com:
On Tue, Nov 22, 2011 at 09:55:59AM -0800, Toshio Kuratomi wrote:
Consideration implies that the following thought process will occur
This update will break out of tree modules, perhaps we shouldn't push it.
That isn't going to happen.
To me, this
On Tue, Nov 22, 2011 at 10:08:18AM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 05:12:12PM +, Matthew Garrett wrote:
I don't know how much clearer I can make this. The update policy applies
to the supported ABI of the package. For instance, if I have an
application that
Am 22.11.2011 18:00, schrieb 80:
The failure is due to Fedora *non-upstream* versionning scheme,
VirtualBox has *already* fixes the API/ABI issue upstream relying on
the kernel version (since 3.2 RC). It has nothing to do with the
kernel non-stable ABI policy (which is notorious).
The
On Tue, Nov 22, 2011 at 07:24:20PM +0100, Thomas Moschny wrote:
2011/11/22 Dave Jones da...@redhat.com:
On Tue, Nov 22, 2011 at 09:55:59AM -0800, Toshio Kuratomi wrote:
Consideration implies that the following thought process will occur
This update will break out of tree modules,
On Tue, Nov 22, 2011 at 06:28:06PM +, Matthew Garrett wrote:
On Tue, Nov 22, 2011 at 10:08:18AM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 05:12:12PM +, Matthew Garrett wrote:
I don't know how much clearer I can make this. The update policy applies
to the supported ABI
On Tue, Nov 22, 2011 at 10:49:28AM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 06:28:06PM +, Matthew Garrett wrote:
Consuming the output of ls is a supported way to use ls. Building third
party modules is not a supported way to use the kernel.
That's not the criteria I see
On Tue, Nov 22, 2011 at 01:21:40PM -0500, Josh Boyer wrote:
We have considered it. A really long time ago. At that time, it was
decided that we consider out-of-tree modules to be something we don't
support, don't care about, and won't hold up updates for because of
the aforementioned
On Tue, Nov 22, 2011 at 06:57:30PM +, Matthew Garrett wrote:
On Tue, Nov 22, 2011 at 10:49:28AM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 06:28:06PM +, Matthew Garrett wrote:
Consuming the output of ls is a supported way to use ls. Building third
party modules is not
On Tue, Nov 22, 2011 at 11:44:59AM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 06:57:30PM +, Matthew Garrett wrote:
So just to be clear on this, you believe that if a user is relying on
byte 0x9e0 of /bin/ls to be 0xdf on x86_64, then that is something that
would have to be
What's the story with this VirtualBox driver ... why can't it go upstream?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
On 11/22/2011 10:34 PM, Reindl Harald wrote:
so complain rpmfusion why they are ALWAYS behind the fedora-kernel-packages
and all their kmod and so on are making troubles days and weeks before
they are push at fedora-stable repo, so the rpmfusion-maintainers should
consider to use
On Tue, Nov 22, 2011 at 07:53:12PM +, Matthew Garrett wrote:
On Tue, Nov 22, 2011 at 11:44:59AM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 06:57:30PM +, Matthew Garrett wrote:
This case requires no clarification.
The fact that you and I are continuing to argue about
On Tue, Nov 22, 2011 at 2:56 PM, Richard W.M. Jones rjo...@redhat.com wrote:
What's the story with this VirtualBox driver ... why can't it go upstream?
Because Oracle hasn't submitted it. Guesses as to their reasoning for
that mostly boil down to them no longer being able to ship the
userspace
Le 22/11/2011 21:10, Josh Boyer a écrit :
Because Oracle hasn't submitted it. Guesses as to their reasoning for
that mostly boil down to them no longer being able to ship the
userspace and driver code in a single version and make whatever
API/ABI changes they wish to between releases.
josh
On Tue, Nov 22, 2011 at 12:09:26PM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 07:53:12PM +, Matthew Garrett wrote:
No. You're simply interpreting things incorrectly.
*sigh* You miss the point. I'm perfectly willing to be interpreting it
incorrectly. The problem is that
On Tue, Nov 22, 2011 at 08:28:30PM +, Matthew Garrett wrote:
On Tue, Nov 22, 2011 at 12:09:26PM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 07:53:12PM +, Matthew Garrett wrote:
No. You're simply interpreting things incorrectly.
*sigh* You miss the point. I'm
On Tue, Nov 22, 2011 at 12:50:40PM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 08:28:30PM +, Matthew Garrett wrote:
If you interpret The ABI as Any property of the binary that another
package could conceivably depend on then your position makes sense. But
since nobody would
On Tue, Nov 22, 2011 at 08:53:33PM +, Matthew Garrett wrote:
On Tue, Nov 22, 2011 at 12:50:40PM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 08:28:30PM +, Matthew Garrett wrote:
If you interpret The ABI as Any property of the binary that another
package could conceivably
2011/11/22 Matthew Garrett m...@redhat.com:
If you interpret The ABI as Any property of the binary that another
package could conceivably depend on then your position makes sense. But
since nobody would interpret it that way, the obvious conclusion is that
The ABI means The supported ABI.
On Tue, Nov 22, 2011 at 2:19 PM, Till Maas opensou...@till.name wrote:
On Tue, Nov 22, 2011 at 01:21:40PM -0500, Josh Boyer wrote:
We have considered it. A really long time ago. At that time, it was
decided that we consider out-of-tree modules to be something we don't
support, don't care
On Tue, Nov 22, 2011 at 01:44:26PM -0800, Toshio Kuratomi wrote:
On Tue, Nov 22, 2011 at 08:53:33PM +, Matthew Garrett wrote:
Really. Use common sense. You appear to be the only person who's
strongly confused on this issue.
On Tue, Nov 22, 2011 at 2:07 PM, Rahul Sundaram methe...@gmail.com wrote:
On 11/22/2011 10:34 PM, Reindl Harald wrote:
so complain rpmfusion why they are ALWAYS behind the fedora-kernel-packages
and all their kmod and so on are making troubles days and weeks before
they are push at
Le 21/11/2011 21:32, Till Maas a écrit :
Hi,
a recent kernel update[0] broke Fedora's ability to be a VirtualBox
host, because asm/amd_iommu.h was removed. The removal of the file was
noticed during testing, but it seems nobody noticed that this affects
VirtualBox. Is this kind of change
Am 21.11.2011 21:32, schrieb Till Maas:
Hi,
a recent kernel update[0] broke Fedora's ability to be a VirtualBox
host, because asm/amd_iommu.h was removed. The removal of the file was
noticed during testing, but it seems nobody noticed that this affects
VirtualBox. Is this kind of change
Till Maas wrote:
a recent kernel update[0] broke Fedora's ability to be a VirtualBox
host, because asm/amd_iommu.h was removed. The removal of the file was
noticed during testing, but it seems nobody noticed that this affects
VirtualBox. Is this kind of change sanctioned by the
current update
On Mon, Nov 21, 2011 at 02:58:32PM -0600, Michael Cronenworth wrote:
Till Maas wrote:
a recent kernel update[0] broke Fedora's ability to be a VirtualBox
host, because asm/amd_iommu.h was removed. The removal of the file was
noticed during testing, but it seems nobody noticed that this
62 matches
Mail list logo
