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.
>>
>> a
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 W
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 d
On Thu, Dec 8, 2011 at 11:23 AM, Reindl Harald 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 strange - the reb
2011/12/8 Reindl Harald :
>
>
> 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 ver
Am 08.12.2011 21:10, schrieb Stijn Hoop:
> On Thu, 08 Dec 2011 19:02:26 +0100
> Reindl Harald 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/.11
On Thu, 08 Dec 2011 19:02:26 +0100
Reindl Harald 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 to 115
> >
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 bumpe
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 12:27, schrieb Stijn Hoop:
> On Thu, 08 Dec 2011 11:07:10 +0100
> Reindl Harald 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
On Thu, 08 Dec 2011 11:07:10 +0100
Reindl Harald 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 months
>
> and yes
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
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 upda
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 internal
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 extra
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 th
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 wrote:
> >
> >> On 11/22/2011 09:51 AM, Michael Cronenworth wrote:
> >>> -#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 1, 0)
> >>
> >> It may hav
On 11/28/2011 12:47 PM, Chuck Ebbert wrote:
> On Tue, 22 Nov 2011 10:06:32 -0800
> Josh Stone 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 L
On Tue, Nov 22, 2011 at 11:07 PM, Reindl Harald 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 much off
topic here on th
On Tue, 22 Nov 2011 10:06:32 -0800
Josh Stone 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 number is for t
Am 23.11.2011 02:23, schrieb Richard Shaw:
> On Tue, Nov 22, 2011 at 2:07 PM, Rahul Sundaram 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
On Tue, Nov 22, 2011 at 2:07 PM, Rahul Sundaram 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 fedora-stable repo, so
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.
>
> http://lists.fedoraproject.org/pipermail/devel/2011-Nov
On Tue, Nov 22, 2011 at 2:19 PM, Till Maas 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 about, and won'
On Tue, Nov 22, 2011 at 10:46:17PM +0100, Thomas Moschny wrote:
> 2011/11/22 Matthew Garrett :
> > 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 ob
2011/11/22 Matthew Garrett :
> 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". Attempti
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
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 nob
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
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 t
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.
On Tue, Nov 22, 2011 at 2:56 PM, Richard W.M. Jones 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 and driver code
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 ar
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 UPDATE
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.
ht
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
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
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 hea
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
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 suppor
On Tue, Nov 22, 2011 at 07:24:20PM +0100, Thomas Moschny wrote:
> 2011/11/22 Dave Jones :
> > 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
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 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
2011/11/22 Dave Jones :
> 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 sounds like k
On Tue, Nov 22, 2011 at 12:55 PM, Toshio Kuratomi 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 cause probl
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 05:12:12PM +, Matthew Garrett wrote:
> On Tue, Nov 22, 2011 at 08:53:13AM -0800, Toshio Kuratomi wrote:
> > On Tue, Nov 22, 2011 at 04:23:28PM +, Matthew Garrett wrote:
> > > The kernel ABI is the syscall interface, /sys and /proc. There is no
> > > stable module AB
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 number is for the benefit of
userspace, not any kernel module. Perhaps it's not
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 use
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 11:50:24.
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.)
--- /usr/share/virtual
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
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 Tue, Nov 22, 2011 at 08:53:13AM -0800, Toshio Kuratomi wrote:
> On Tue, Nov 22, 2011 at 04:23:28PM +, Matthew Garrett wrote:
> > 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 ve
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 goi
2011/11/22 Matthew Garrett :
> 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 interpretation of the stabl
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 ma
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
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 Fed
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 becau
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 b
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
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 see
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 thi
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 up
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 cha
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 chang
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 sanctioned by the
current update criteria?
Kind r
68 matches
Mail list logo