Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 it NOT polite >> >> WAS I THE PERSON WHO RESTARTED THIS THREAD? >> NO I WAS NOT! >> >> so please pissoff people who did! > > You're the one who introduced the completely and utterly > irrelevant-to-this-thread topic of RPM Fusion's version of x264 eys BUT i am not the one started this thread in the wrong mailing-list and i was not the one restarting it again go back and look at my first reply to the op which was intentet as "do not whine here because rpmfusion is sleeping" signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 RESTARTED THIS THREAD? > NO I WAS NOT! > > so please pissoff people who did! You're the one who introduced the completely and utterly irrelevant-to-this-thread topic of RPM Fusion's version of x264. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 did! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 rebuilds do not take really time Please... I'm begging you. Can you please stop asking rhetorical questions concerning the management of a 3rd party repository here. We legitimately can not give you an authoritative an answer to that question... and you know this. You KNOW this is not the correct mailinglist and yet you persist. Enough. This is not the appropriate place to air your grievances about rpmfusion packaging decisions and as a group here we can neither adequately defend current 3rd party repository management nor is it possible for us as a group to do anything to make your personally feel better by making any changes. rpmfusion has their own communication and governance model that is not beholden to the governance model the the Fedora project employees to arbitrate over technical grievances. All we can do is encourage you to _engage_ with the management of that 3rd party repository to resolve your grievances. Which we have done repeatedly now. I'm saying this as politely as I can. Move this into the appropriate rpmfusion development communication channel and out of here. Continuing to get yourself emotionally worked up about your grievances here is not going to lead to satisfactory progress for anyone. Not for you, not for other rpmfusion users, not for the rpmfusion developers, and not for any else here either. If you continue to persist in second guessing our collective good faith attempts at explaining the situation to you, I will not be as polite in further communication. Good day to you sir, -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 very bad idea, upstream probably bumped them for a >> reason. > > i know and that is why this are private builds > > doe snot change the fact that rpmfusion did a so-bump on x264 > with all the needed rebuilds and bumped only from 114 to 115 > instead 119 while all this apps are working even with 120 > perfectly I don't understand why this has anything to do with VirtualBOX and even Fedora. Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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/.115 for F15
and currently the .120 to 115
>>>
>>> Changing soversions is a very bad idea, upstream probably bumped
>>> them for a reason.
>>
>> i know and that is why this are private builds
>>
>> doe snot change the fact that rpmfusion did a so-bump on x264
>> with all the needed rebuilds and bumped only from 114 to 115
>> instead 119 while all this apps are working even with 120
>> perfectly
>>
>> they stayed for nearly 2 years at x264.so.102 what makes
>> compile of newer ffmpeg impossible and so i see not that
>> big glory in the rpmfusion packages since they also never
>> do the fedora-massrebuilds after GLIBC/GCC changes at
>> their side
>>
>> be happy with it - for me the packages are only a nice
>> "to start with"-SPEC
>
> I think you'll find out that either
>
> - bumping to .120 makes some other programs not work anymore
> - they don't have enough manpower to do the proper rebuilds
>
> Both of which are solvable problems given more manpower and/or
> expertise, which you seem to have but chose to invest only privately.
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 rebuilds do not take really time
[builduser@buildserver64:/rpmbuild/rebuild]$ cat rebuild-all.sh
#!/bin/bash
find /rpmbuild/rebuild/ -type f -name \*.src.rpm -exec rpmbuild --rebuild {} \;
[builduser@buildserver64:/rpmbuild/rebuild]$ ls | grep -v spec | grep -v sh
insgesamt 80M
-rw-r--r-- 1 builduser builduser 758K 2011-05-21 05:22 apr-1.4.5-1.fc15.src.rpm
-rw-rw-r-- 1 builduser builduser 16M 2011-10-09 10:51
avidemux-2.5.5-6.fc15.1.src.rpm
-rw-rw-r-- 1 builduser builduser 135K 2011-07-21 15:47
crypto-utils-2.4.1-31.src.rpm
-rw-rw-r-- 1 builduser builduser 32K 2009-05-06 20:12
flvtool2-1.0.6-4.fc11.src.rpm
-rw-rw-r-- 1 builduser builduser 240K 2011-02-09 00:27
fuseiso-20070708-10.fc15.src.rpm
-rw-rw-r-- 1 builduser builduser 783K 2011-02-09 05:44
gmime22-2.2.25-2.fc15.src.rpm
-rw-rw-r-- 1 builduser builduser 75K 2009-07-29 17:24
gsm-1.0.13-2.fc12.src.rpm
-rw-rw-r-- 1 builduser builduser 1,1M 2011-10-09 10:51
gstreamer-plugins-ugly-0.10.18-1.fc15.1.src.rpm
-rw-rw-r-- 1 builduser builduser 640K 2011-09-11 02:35
jigdo-0.7.3-11.fc15.src.rpm
-rw-rw-r-- 1 builduser builduser 352K 2011-02-08 07:51
libavc1394-0.5.3-10.fc15.src.rpm
-rw-rw-r-- 1 builduser builduser 500K 2010-10-26 20:09
libmad-0.15.1b-13.fc12.src.rpm
-rw-rw-r-- 1 builduser builduser 1,1M 2011-02-08 11:10
libmng-1.0.10-5.fc15.src.rpm
-rw-rw-r-- 1 builduser builduser 250K 2011-02-08 11:12
libmpcdec-1.2.6-7.fc15.src.rpm
-rw-rw-r-- 1 builduser builduser 518K 2010-10-26 20:11
libmpeg2-0.5.1-8.fc12.src.rpm
-rw-rw-r-- 1 builduser builduser 2,4M 2009-11-16 08:52
libmpeg3-1.8-3.fc12.src.rpm
-rw-rw-r-- 1 builduser builduser 331K 2011-03-23 19:31
libnss-mysql-1.5-15.fc15.src.rpm
-rw-rw-r-- 1 builduser builduser 1008K 2011-10-09 10:51
libquicktime-1.2.3-3.fc15.1.src.rpm
-rw-rw-r-- 1 builduser builduser 4,2M 2011-02-08 12:43
libsamplerate-0.1.7-3.fc15.src.rpm
-rw-rw-r-- 1 builduser builduser 1,4M 2011-02-17 16:25
libtheora-1.1.1-1.fc15.src.rpm
-rw-rw-r-- 1 builduser builduser 860K 2011-08-29 18:19
libtool-2.4-6.fc15.src.rpm
-rw-r--r-- 1 builduser builduser 1,1M 2011-09-08 17:30
lvm2-2.02.84-4.fc15.src.rpm
-rw-r--r-- 1 builduser builduser 574K 2011-09-14 09:32 lzo-2.06-1.fc15.src.rpm
-rw-rw-r-- 1 builduser builduser 401K 2011-10-22 17:08
mdadm-3.2.2-12.fc16.src.rpm
-rw-rw-r-- 1 builduser builduser 5,4M 2011-10-07 14:54
mplayer-1.0-0.125.20110816svn.fc15.src.rpm
-rw-rw-r-- 1 builduser builduser 852K 2010-10-16 19:22
opencore-amr-0.1.2-1.fc12.src.rpm
-rw-r--r-- 1 builduser builduser 3,3M 2011-09-07 20:48
openssl-1.0.0e-1.fc15.src.rpm
-rw-rw-r-- 1 builduser builduser 6,7M 2011-06-21 05:58
perl-Tk-804.029-2.fc16.src.rpm
-rw-rw-r-- 1 builduser builduser 257K 2011-11-25 15:17
procmail-3.22-27.fc16.src.rpm
-rw-r--r-- 1 builduser builduser 23K 2011-10-25 20:00
svn2cl-0.13-2.fc16.src.rpm
-rw-rw-r-- 1 builduser builduser 283K 2011-09-13 19:27
sysstat-10.0.2-2.fc16.src.rpm
-rw-rw-r-- 1 builduser builduser 269K 2011-08-23 15:35
system-config-samba-1.2.93-1.fc16.src.rpm
-rw-rw-r-- 1 builduser builduser 492K 2011-02-09 20:30
tidy-0.99.0-21.20091203.fc15.src.rpm
-rw-r--r-- 1 builduser builduser 2,1M 2011-07-23 11:52
transcode-1.1.5-7.fc15.src.rpm
-rw-rw-r-- 1 builduser builduser 479K 2010-10-16 19:23
twolame-0.3.12-4.fc11.src.rpm
-rw-rw-r-- 1 builduser builduser 26M 2011-10-09 10:51
vlc-1.1.12-1.fc15.src.rpm
-rw-rw-r-- 1 builduser builduser 755K 2011-06-19
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 > > > > Changing soversions is a very bad idea, upstream probably bumped > > them for a reason. > > i know and that is why this are private builds > > doe snot change the fact that rpmfusion did a so-bump on x264 > with all the needed rebuilds and bumped only from 114 to 115 > instead 119 while all this apps are working even with 120 > perfectly > > they stayed for nearly 2 years at x264.so.102 what makes > compile of newer ffmpeg impossible and so i see not that > big glory in the rpmfusion packages since they also never > do the fedora-massrebuilds after GLIBC/GCC changes at > their side > > be happy with it - for me the packages are only a nice > "to start with"-SPEC I think you'll find out that either - bumping to .120 makes some other programs not work anymore - they don't have enough manpower to do the proper rebuilds Both of which are solvable problems given more manpower and/or expertise, which you seem to have but chose to invest only privately. Which is fine by me, but then please do not complain about the people who DO share their time, on this list. Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 for a > reason. i know and that is why this are private builds doe snot change the fact that rpmfusion did a so-bump on x264 with all the needed rebuilds and bumped only from 114 to 115 instead 119 while all this apps are working even with 120 perfectly they stayed for nearly 2 years at x264.so.102 what makes compile of newer ffmpeg impossible and so i see not that big glory in the rpmfusion packages since they also never do the fedora-massrebuilds after GLIBC/GCC changes at their side be happy with it - for me the packages are only a nice "to start with"-SPEC signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 joke >> while .119 exists since months >> >> and yes i had the .119 since months running, even with VLC from >> rpmfusion > > Maybe you could have submitted your months old changes upstream? 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 this are changes which upstream are not accepted and they are only there to satisfy dependencies of other rpmfusion-packages signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 i had the .119 since months running, even with VLC from > rpmfusion Maybe you could have submitted your months old changes upstream? --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 changed >> * services MUST NOT restart while update package > > Not true. There's no such policy, in fact rather the opposite. That has also > been discussed in another thread. did i say the opposite? well and that is why i am forced to rebuild half of distribution >> * more F15 services with systemd-units > And that again isn't a policy violation at all and this is a major-fail of F15 vene in F16 not really fixed and packages like rsyslog are missing the reload-action ExecReload=/usr/bin/killall -s SIGHUP rsyslogd > FWIW, I'm very happy with the packages RPM Fusion (at least the Free > section, the only one I use) is shipping. nice for you 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 i had the .119 since months running, even with VLC from rpmfusion signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 package Not true. There's no such policy, in fact rather the opposite. That has also been discussed in another thread. > * more F15 services with systemd-units And that again isn't a policy violation at all, unless they grew that systemd unit in an update (the policy is that packages shipped with SysV initscripts only should stick with those for the life time of the release, but shipping with systemd units at Fedora 15 release time was very much encouraged, and not a policy violation at all). FWIW, I'm very happy with the packages RPM Fusion (at least the Free section, the only one I use) is shipping. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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. > > Don't understand exactly what you are talking, but I'll wait to see. > On (future) VirtualBox-OSE-kmod for F15 , we had remove vboxpci.ko from > build , because fails to compile with latest F15 kernel. All of them can compile now, including vboxpci. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 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. Don't understand exactly what you are talking, but I'll wait to see. On (future) VirtualBox-OSE-kmod for F15 , we had remove vboxpci.ko from build , because fails to compile with latest F15 kernel. > It looks like your fesco ticket is being considered, so give it time... yeah I just read fesco meeting, we have to wait one week :) Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 new version information is doing the right thing, representing itself as a normal 3.1 kernel internally. > in meantime I will read the begging of the thread, I also have some > doubts about the kernels 41. > But the main problem is, can't submit it on F15 because kBuild is not > updated (on F15) and I'm waiting for a decision on fesco about this > matter (update kBuild). It looks like your fesco ticket is being considered, so give it time... Josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 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 too late? > > > > I've done this in the 2.6.41.3 update. Please try it. > > Sorry I didn't try sooner, as I don't actually have any pressing need > for the change myself. But I happened to have the e1000e-1.6.3 source > handy, which failed in kcompat.h on 2.6.41.1-1, but does compile > successfully with 2.6.41.4-1. So, looks good to me! 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 , in meantime I will read the begging of the thread, I also have some doubts about the kernels 41. But the main problem is, can't submit it on F15 because kBuild is not updated (on F15) and I'm waiting for a decision on fesco about this matter (update kBuild). Regards, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 LINUX_VERSION_CODE. AFAIK, faking the number is for the benefit of >> userspace, not any kernel module. Perhaps it's not too late? > > I've done this in the 2.6.41.3 update. Please try it. Sorry I didn't try sooner, as I don't actually have any pressing need for the change myself. But I happened to have the e1000e-1.6.3 source handy, which failed in kcompat.h on 2.6.41.1-1, but does compile successfully with 2.6.41.4-1. So, looks good to me! Thanks, Josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 this list. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 the benefit of > userspace, not any kernel module. Perhaps it's not too late? I've done this in the 2.6.41.3 update. Please try it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 before >>> they are push at fedora-stable repo, so the rpmfusion-maintainers should >>> consider to use UPDATES-TESTING to see minor issues before the endusers >> >> They need more package maintainers, infrastructure maintainers and other >> forms of help. No amount of complaining will fix that. > > I can attest to this. I have taken on a handful of packages that I > don't think I'm entirely qualified to maintain, but the fact is that > NO ONE ELSE stepped forward to take them so I'm doing it out of > necessity on a best effort basis. If you don't like the service you're > getting ask for a refund :) that is not the point i have patched vmware_wrokstation module-sources to compile on 2.6.41 within 5 minutes because it is ONE LINE to change, so do not tell me this are all so complicated there are packages, they are existing, someone introduced them if i start to be responsible for anything i maintain it if i can not do this over the long i am not taking things over so easy is the life! 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 package * more F15 services with systemd-units * much newrer versions of x264/ffmpeg * much faster updates, packages you find not in fedora * dbmail2 instead a dbmail3 RC a52dec-0.7.4-15.fc15.20111029.rh.x86_64.rpm a52dec-devel-0.7.4-15.fc15.20111029.rh.x86_64.rpm aespipe-2.4c-2.fc15.20111029.rh.x86_64.rpm apr-1.4.5-1.fc15.20111029.rh.x86_64.rpm apr-devel-1.4.5-1.fc15.20111029.rh.x86_64.rpm avidemux-2.5.5-6.fc15.20111029.rh.1.x86_64.rpm avidemux-cli-2.5.5-6.fc15.20111029.rh.1.x86_64.rpm avidemux-gtk-2.5.5-6.fc15.20111029.rh.1.x86_64.rpm avidemux-libs-2.5.5-6.fc15.20111029.rh.1.x86_64.rpm avidemux-qt-2.5.5-6.fc15.20111029.rh.1.x86_64.rpm camstream-0.26.3-19.fc14.rh.20110422.x86_64.rpm cmirror-2.02.84-4.fc15.20111029.rh.x86_64.rpm cups-1.5.0-11.fc15.2009.rh.x86_64.rpm cups-devel-1.5.0-11.fc15.2009.rh.x86_64.rpm cups-ipptool-1.5.0-11.fc15.2009.rh.x86_64.rpm cups-libs-1.5.0-11.fc15.2009.rh.x86_64.rpm cups-lpd-1.5.0-11.fc15.2009.rh.x86_64.rpm cups-php-1.5.0-11.fc15.2009.rh.x86_64.rpm dbmail-2.2.17-15.fc15.2009.rh.x86_64.rpm dbmail-auth-ldap-2.2.17-15.fc15.2009.rh.x86_64.rpm dbmail-mysql-2.2.17-15.fc15.2009.rh.x86_64.rpm dbmail-pgsql-2.2.17-15.fc15.2009.rh.x86_64.rpm dbmail-postfix-policyd-2011.05.25-7.fc15.20111029.rh.noarch.rpm device-mapper-1.02.63-4.fc15.20111029.rh.x86_64.rpm device-mapper-devel-1.02.63-4.fc15.20111029.rh.x86_64.rpm device-mapper-event-1.02.63-4.fc15.20111029.rh.x86_64.rpm device-mapper-event-devel-1.02.63-4.fc15.20111029.rh.x86_64.rpm device-mapper-event-libs-1.02.63-4.fc15.20111029.rh.x86_64.rpm device-mapper-libs-1.02.63-4.fc15.20111029.rh.x86_64.rpm dimp-1.1.7-3.fc15.20111029.rh.noarch.rpm dovecot-2.0.15-3.fc15.20111029.rh.x86_64.rpm dovecot-2.0.16-3.fc15.2017.rh.x86_64.rpm dovecot-devel-2.0.15-3.fc15.20111029.rh.x86_64.rpm dovecot-devel-2.0.16-3.fc15.2017.rh.x86_64.rpm dovecot-mysql-2.0.15-3.fc15.20111029.rh.x86_64.rpm dovecot-mysql-2.0.16-3.fc15.2017.rh.x86_64.rpm dovecot-pgsql-2.0.15-3.fc15.20111029.rh.x86_64.rpm dovecot-pgsql-2.0.16-3.fc15.2017.rh.x86_64.rpm dovecot-pigeonhole-2.0.15-3.fc15.20111029.rh.x86_64.rpm dovecot-pigeonhole-2.0.16-3.fc15.2017.rh.x86_64.rpm faac-1.28-6.fc15.20111029.rh.x86_64.rpm faac-devel-1.28-6.fc15.20111029.rh.x86_64.rpm faad2-2.7-3.fc15.20111029.rh.x86_64.rpm faad2-devel-2.7-3.fc15.20111029.rh.x86_64.rpm faad2-libs-2.7-3.fc15.20111029.rh.x86_64.rpm ffmpeg-0.7.7-4.2013git32000.fc15.2013.rh.x86_64.rpm ffmpeg-0.7.8-4.2022git32000.fc15.2022.rh.x86_64.rpm ffmpeg-devel-0.7.7-4.2013git32000.fc15.2013.rh.x86_64.rpm ffmpeg-devel-0.7.8-4.2022git32000.fc15.2022.rh.x86_64.rpm ffmpeg-libs-0.7.7-4.2013git32000.fc15.2013.rh.x86_64.rpm ffmpeg-libs-0.7.8-4.2022git32000.fc15.2022.rh.x86_64.rpm flac-1.2.1-6.fc14.rh.20110422.x86_64.rpm flac-devel-1.2.1-6.fc14.rh.20110422.x86_64.rpm freenx-server-0.7.3-24.fc15.20111029.rh.x86_64.rpm fuseiso-20070708-10.fc15.20111029.rh.x86_64.rpm GeoIP-1.4.8-2.fc15.20111029.rh.x86_64.rpm GeoIP-devel-1.4.8-2.fc15.20111029.rh.x86_64.rpm gmime22-2.2.25-2.fc15.20111029.rh.x86_64.rpm gmime22-devel-2.2.25-2.fc15.20111029.rh.x86_64.rpm gstreamer-plugins-ugly-0.10.18-1.fc15.20111029.rh.1.x86_64.rpm gstreamer-plugins-ugly-devel-docs-0.10.18-1.fc15.20111029.rh.1.noarch.rpm horde-3.3.12-3.fc15.20111029.rh.noarch.rpm horde-enhanced-3.3.12-3.fc15.20111029.rh.noarch.rpm httpd-2.2.21-4.fc15.20111029.rh.x86_64.rpm httpd-devel-2.2.21-4.fc15.20111029.rh.x86_64.rpm httpd-manual-2.2.19-3.fc15.rh.20110614.x86_64.rpm http
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 the rpmfusion-maintainers should >> consider to use UPDATES-TESTING to see minor issues before the endusers > > They need more package maintainers, infrastructure maintainers and other > forms of help. No amount of complaining will fix that. I can attest to this. I have taken on a handful of packages that I don't think I'm entirely qualified to maintain, but the fact is that NO ONE ELSE stepped forward to take them so I'm doing it out of necessity on a best effort basis. If you don't like the service you're getting ask for a refund :) Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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-November/159715.html A question is asked. The answer is "yes". > http://lists.fedoraproject.org/pipermail/devel/2011-November/159781.html It's asked whether kernel updates may violate the update policy by virtue of supported hardware having stopped working. And the answer to that one is pretty obviously yes - supported behaviour that previously worked no longer works. This one is supported by the assumption that overall the bug and security fixes in the new kernel are an overall improvement to the project, but it would certainly be worth having a discussion about what we can do to attempt to avoid hardware-specific regressions like this. It's unrelated to what we've been talking about. > http://lists.fedoraproject.org/pipermail/devel/2011-November/159826.html And that's simply based on the assumption that the user experience includes expecting to be able to use third party modules, which it doesn't. We could certainly clarify that. -- Matthew Garrett | m...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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't hold up updates for because of >> the aforementioned heavier considerations of fixing bugs. So, with >> that phrasing in mind, everything is compliant with what you're saying >> about the updates policy. > > Nevertheless it would have been nice to mention that the kernel update > will actually break the VirtualBox kernel module in it's update notes as > it seems to me that a lot of people knew it and even the problematic > change was mentioned in the update's feedback. Well, the kernel team isn't going to know whether an update breaks vbox (or vmware or whatever) or not, because we don't even attempt to see if it will. As I said above, we do not care about out of tree modules. So we could put 'this will break vbox' or 'this will break all out-of-tree modules' in every update but that may or may not be true. I believe having users note it in the feedback is sufficient. >> Maybe now this thread can end, because it's really not accomplishing >> anything at all. If we wanted to sit around and practice >> wordsmithing, there are much better places and topics to do it with. > > What about this suggestion by Josh Stone? This seems to be a good result > from the discussion: > http://lists.fedoraproject.org/pipermail/devel/2011-November/159818.html > | 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 too late? I'm not sure why we would go out of our way to make it easier to build out-of-tree modules. Bug reports with them loaded get closed immediately as NOTABUG or CANTFIX, but we still have to look at them before we can do that. Making it easier to build and use them just means more work for us. The bottom line on kernel modules in Fedora is very simple. If your module is not in the upstream kernel tree, and included in the set of modules we have enabled, we do not care at all about it. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 obvious conclusion is that > > "The ABI" means "The supported ABI". Attempting to codify this more > > precisely would just encourage language lawyering, which is exactly what > > we were trying to avoid when we generated this policy. Use common sense. > > If you replace "conveivably" by "commonly" or "reasonably" than I'd > say more people than "nobody" would expect the updates policy to > prevent such changes. Well, yes, if you change what I said then you get a different conclusion :) > Of course I buy the argument that we as the Fedora community don't > have enough resources to backport each and every kernel bugfix. That > is a completely valid point, and if the outcome is that under these > constraints things are how they are and the ABI changes, than this is > ok. Even if we did backport each and every kernel bugfix, the module ABI would change. Nobody promises a stable module ABI - even RHEL only provides it for a small subset of the entire ABI. It exposes too much of the kernel internals to make it possible. > That said, you are still obliged by the updates policy to think about > the effects of an update (of each update) and weigh pros and cons like > every other packager. Saying yes we did that long time ago occurs a > bit rude to me. Misuses of the package just aren't on the set of things that should be considered. If a user is doing something unsupportable then we don't need to consider that user's inconvenience when deciding whether to push the update or not. So an inability to compile virtualbox is entirely irrelevant. Like I said, we could actively enforce this by not shipping the headers and changing the module loader to reject out of tree module builds - but there doesn't seem to be any real advantage to doing that. There are completely valid reasons to complain about the kernel's adherence to the updates policy, and things like driver breakage are definitely on that list. I'm certainly not happy that updates occasionally break people's wifi, for instance. Anger at that is entirely justifiable. But anger at an inability to build virtualbox isn't. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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". Attempting to codify this more > precisely would just encourage language lawyering, which is exactly what > we were trying to avoid when we generated this policy. Use common sense. If you replace "conveivably" by "commonly" or "reasonably" than I'd say more people than "nobody" would expect the updates policy to prevent such changes. Of course I buy the argument that we as the Fedora community don't have enough resources to backport each and every kernel bugfix. That is a completely valid point, and if the outcome is that under these constraints things are how they are and the ABI changes, than this is ok. That said, you are still obliged by the updates policy to think about the effects of an update (of each update) and weigh pros and cons like every other packager. Saying yes we did that long time ago occurs a bit rude to me. - Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 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". Attempting to codify this more > > > precisely would just encourage language lawyering, which is exactly what > > > we were trying to avoid when we generated this policy. Use common sense. > > > > > http://lists.fedoraproject.org/pipermail/devel/2011-November/159819.html > > 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-November/159715.html http://lists.fedoraproject.org/pipermail/devel/2011-November/159781.html http://lists.fedoraproject.org/pipermail/devel/2011-November/159826.html As we're just covering ground that's already been covered at this point, I'm going to stop replying -- the offer is still open in the fesco ticket if you/they would like me to work on the wording of the policy. -Toshio pgpOhzTCkAEXS.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 interpret it that way, the obvious conclusion is that > > "The ABI" means "The supported ABI". Attempting to codify this more > > precisely would just encourage language lawyering, which is exactly what > > we were trying to avoid when we generated this policy. Use common sense. > > > http://lists.fedoraproject.org/pipermail/devel/2011-November/159819.html Really. Use common sense. You appear to be the only person who's strongly confused on this issue. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 perfectly willing to be interpreting it > > incorrectly. The problem is that the wording allows me to interpret in > > incorrectly. I have gone through the policy and quoted you the sections > > that I'm reading to support my interpretation. > > 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". Attempting to codify this more > precisely would just encourage language lawyering, which is exactly what > we were trying to avoid when we generated this policy. Use common sense. > http://lists.fedoraproject.org/pipermail/devel/2011-November/159819.html -Toshio pgpwwDZAJXGlO.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 the wording allows me to interpret in > incorrectly. I have gone through the policy and quoted you the sections > that I'm reading to support my interpretation. 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". Attempting to codify this more precisely would just encourage language lawyering, which is exactly what we were trying to avoid when we generated this policy. Use common sense. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 Most likely because of its shit-grade quality. https://lkml.org/lkml/2011/10/6/317 H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 in a single "version" and make whatever API/ABI changes they wish to between releases. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 this despite the fact > > that we agree on the desired outcome would suggest otherwise. > > 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 the wording allows me to interpret in incorrectly. I have gone through the policy and quoted you the sections that I'm reading to support my interpretation. That does not mean that the intention of the policy needs to be changed. It *does* mean that the wording of the policy should be changed so that it's less likely for people to interpret it in the manner that I've interpreted it here. -Toshio pgpG28jm7rIMV.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 UPDATES-TESTING to see minor issues before the endusers They need more package maintainers, infrastructure maintainers and other forms of help. No amount of complaining will fix that. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 considered under the update policy? > > > Yes. Consideration ie: thinking. Making an informed judgement is what the > policy requires. Do you have to spend long, sleepless nights tossing and > turning and pulling out your hair over that one user out of our supposed > million? No. You can quickly evaluate and say that this is one user using, > as we're agreed on, an unsupported feature of our package and therefore > we're going to push a bugfix update anyway. As I wrote in my reply to > davej, this can even be a decision that is applied in an ongoing manner > (What is the exception section of the policy, anyway but such decisions made > and applied at a more global level). Ok. I don't believe that this is the intended interpretation of the update policy. It was never our intention to discourage changes that are outside the scope of the supported interface of the package. > Here's a counter example of equally hypothetical proportions -- let's say > that you believe every user of Fedora 16 to rely on byte 0x9e0 of /bin/ls to > be 0xdf and that if that is changed Fedora 16 will need to be rebooted from > a rescue cd in order to be restored. Would you say that that is something > that would not have to be considered under the update policy? That would require packages within Fedora to be dependent upon that behaviour, and so the update should be prevented because it would break other packages that we ship. If we've inappropriately relied upon unspecified behaviour of a package then that's something that we have to deal with. If a user has inappropriately relied upon unspecified behaviour of a package then that's something the user has to deal with. > > This case requires no clarification. > > > The fact that you and I are continuing to argue about this despite the fact > that we agree on the desired outcome would suggest otherwise. No. You're simply interpreting things incorrectly. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 a supported way to use the kernel. > > > > > That's not the criteria I see when reading the updates vision and updates > > policy. I don't see supported there; I see whether we're breaking things > > the way end users are using them. > > 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 considered under the update policy? > Yes. Consideration ie: thinking. Making an informed judgement is what the policy requires. Do you have to spend long, sleepless nights tossing and turning and pulling out your hair over that one user out of our supposed million? No. You can quickly evaluate and say that this is one user using, as we're agreed on, an unsupported feature of our package and therefore we're going to push a bugfix update anyway. As I wrote in my reply to davej, this can even be a decision that is applied in an ongoing manner (What is the exception section of the policy, anyway but such decisions made and applied at a more global level). Here's a counter example of equally hypothetical proportions -- let's say that you believe every user of Fedora 16 to rely on byte 0x9e0 of /bin/ls to be 0xdf and that if that is changed Fedora 16 will need to be rebooted from a rescue cd in order to be restored. Would you say that that is something that would not have to be considered under the update policy? [snip] > > Clarifying wording may not be as fun as coding but it is necessary if we > > want to stop discussing the same points over and over with slightly > > different cases each time. > > This case requires no clarification. > The fact that you and I are continuing to argue about this despite the fact that we agree on the desired outcome would suggest otherwise. I'm willing to do the work. Opened up a ticket so I know what the desired outcome is to look like: https://fedorahosted.org/fesco/ticket/706 -Toshio pgpuaeRyp6LbE.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 heavier considerations of fixing bugs. So, with > that phrasing in mind, everything is compliant with what you're saying > about the updates policy. Nevertheless it would have been nice to mention that the kernel update will actually break the VirtualBox kernel module in it's update notes as it seems to me that a lot of people knew it and even the problematic change was mentioned in the update's feedback. > Maybe now this thread can end, because it's really not accomplishing > anything at all. If we wanted to sit around and practice > wordsmithing, there are much better places and topics to do it with. What about this suggestion by Josh Stone? This seems to be a good result from the discussion: http://lists.fedoraproject.org/pipermail/devel/2011-November/159818.html | 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 too late? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 when reading the updates vision and updates > policy. I don't see supported there; I see whether we're breaking things > the way end users are using them. 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 considered under the update policy? > > It's clear that if we disabled the ability to build third party modules > > at all that the ability to use third party modules would be entirely > > irrelevant and clearly not a consideration. So just pretend that we've > > done that. > > So that we can have this discussion again when a different package also > breaks end user expectations without breaking ABI? If we want to avoid long > discussions that in the end boil down to different interpretations of the > policies we need to take care to make our policies clearly reflect the > meaning we intend. If the relevant metric is "end user expectations", why didn't you just say that in the beginning? We should be clearer that any expectation that third-party modules will be usable over the course of a stable release is wrong. I've no problem with that. It's still not an issue with the updates policy. > Clarifying wording may not be as fun as coding but it is necessary if we > want to stop discussing the same points over and over with slightly > different cases each time. This case requires no clarification. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 of the package. For instance, if I have an > > > application that depends on byte 0x9e0 of /bin/ls being 0xdf and an > > > update breaks that, that's not a relevant consideration for the update > > > policy. The kernel module interface is not a supported ABI in Fedora. > > > It's simply not a relevant consideration for the update policy. > > > > > I don't know how much clearer I can make this -- The updates policy applies > > to more than the "supported ABI of a package". For instance, if you have an > > application that dependds on /bin/ls printing "?" when it encounters > > a filename with a byte that cannot be decoded in the current locale and it > > starts printing \001 instead, that is a relevant consideration according to > > the updates policy. > > 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 when reading the updates vision and updates policy. I don't see supported there; I see whether we're breaking things the way end users are using them. > > > The policy is fine as is. The problem is your overreaching definition of > > > ABI. We could make it explicit that the module interface isn't an > > > exported ABI by modifying the loader so that third-party modules simply > > > can't be loaded at all and then this clearly wouldn't be an issue, but I > > > don't think anyone benefits from us doing that. > > > > The definition of ABI is not at issue. The reach of the updates policy > > itself is. If I'm understanding you correctly you think the updates policy > > applies to a much more limited scope of changes than I do. I would suggest > > that that is an indication that the updates policy needs to be reworded in > > at least certain places so as to more clearly illustrate whether it has > > a broad scope (in which things like ABI are examples of criteria for > > deciding not to issue an update) or limited scope (in which ABI is one of > > the specific criteria for decding to withhold an update.) > > It's clear that if we disabled the ability to build third party modules > at all that the ability to use third party modules would be entirely > irrelevant and clearly not a consideration. So just pretend that we've > done that. So that we can have this discussion again when a different package also breaks end user expectations without breaking ABI? If we want to avoid long discussions that in the end boil down to different interpretations of the policies we need to take care to make our policies clearly reflect the meaning we intend. Clarifying wording may not be as fun as coding but it is necessary if we want to stop discussing the same points over and over with slightly different cases each time. -Toshio pgp6jellzJwIG.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 shouldn't push it." > > > > That isn't going to happen. > > To me, this sounds like knowingly violating the Updates Policy, which > states: "Updates should aim to fix bugs, and not introduce features, > particularly when those features would materially affect the user or > developer experience." (Ignoring the fact that changing a documented unstable API isn't anything to do with a "developer experience") The kernel gets more bugs filed against it than any other component in the distro. Obviously this needs to be dealt with somehow. Asides from rebasing, we have two alternatives. 1. We backport just the fixes from upstream. Not feasible with the limited manpower we have. (See F14 for a great example of this failing) 2. We close every bug with ->NEXTRELEASE If someone wants to do the relevant beurocracy to document this in the policies, go wild, but the kernel has always been this way since Fedora's inception. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 least we can do is helping third-party packagers to fix this > issue, not slamming the door on their face. well and why is RPMFUSION not updateing their packages as they did also with open-vm-tools and in the case of open-vm-tools they decided to drop the whole package as example for vmware: VMware-Workstation 8 requires ONE single line changed and the modules get compiled with 2.6.41 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 UPDATES-TESTING to see minor issues before the endusers signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 depends on byte 0x9e0 of /bin/ls being 0xdf and an > > update breaks that, that's not a relevant consideration for the update > > policy. The kernel module interface is not a supported ABI in Fedora. > > It's simply not a relevant consideration for the update policy. > > > I don't know how much clearer I can make this -- The updates policy applies > to more than the "supported ABI of a package". For instance, if you have an > application that dependds on /bin/ls printing "?" when it encounters > a filename with a byte that cannot be decoded in the current locale and it > starts printing \001 instead, that is a relevant consideration according to > the updates policy. 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. > > The policy is fine as is. The problem is your overreaching definition of > > ABI. We could make it explicit that the module interface isn't an > > exported ABI by modifying the loader so that third-party modules simply > > can't be loaded at all and then this clearly wouldn't be an issue, but I > > don't think anyone benefits from us doing that. > > The definition of ABI is not at issue. The reach of the updates policy > itself is. If I'm understanding you correctly you think the updates policy > applies to a much more limited scope of changes than I do. I would suggest > that that is an indication that the updates policy needs to be reworded in > at least certain places so as to more clearly illustrate whether it has > a broad scope (in which things like ABI are examples of criteria for > deciding not to issue an update) or limited scope (in which ABI is one of > the specific criteria for decding to withhold an update.) It's clear that if we disabled the ability to build third party modules at all that the ability to use third party modules would be entirely irrelevant and clearly not a consideration. So just pretend that we've done that. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 knowingly violating the Updates Policy, which states: "Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience." - Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 problems for >> third >> > party kernel module packagers and end users that are compiling their own >> > kernel modules. >> >> We *know* we're going to break out of tree modules. It's entirely expected. >> There's nothing to consider here at all. >> > I don't disagree with your first two sentences. In fact I'd go further -- > It's not only expected, it's also accepted by you. > > The third sentence is the only thing that I think needs to be looked at in > terms of the Update Policy. The updates policy and the updates vision on > which it is based strive to make maintainers realize that pushing updates > has both positive and negative effects on end users. Some of those effects > are also "expected and accepted". For instance, the updates vision says > "Similarly, dealing with a large number of updates on a regular basis is > distracting from the user's desired productivity tasks." Simply issuing an > update is in and of itself one negative in the updates vision. > > 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*. 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 heavier considerations of fixing bugs. So, with that phrasing in mind, everything is compliant with what you're saying about the updates policy. Maybe now this thread can end, because it's really not accomplishing anything at all. If we wanted to sit around and practice wordsmithing, there are much better places and topics to do it with. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 update will break out of tree modules, perhaps we shouldn't push it." That isn't going to happen. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 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 stable update policy that > > > prevented us from ever providing kernel security updates would be > > > absurd, that's clearly not the correct interpretation. And if the module > > > ABI isn't supported, nor is the API. > > > > > That's not a logical conclusion. As I said in both my previous emails, the > > updates policy allows the maintainer to decide that the benefits of a new > > version outwiegh the problems. 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. The policy does not require that the kernel maintainers > > weigh this more heavily than the need to provide security updates (or new > > hardware or major bugfixes). > > 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 depends on byte 0x9e0 of /bin/ls being 0xdf and an > update breaks that, that's not a relevant consideration for the update > policy. The kernel module interface is not a supported ABI in Fedora. > It's simply not a relevant consideration for the update policy. > I don't know how much clearer I can make this -- The updates policy applies to more than the "supported ABI of a package". For instance, if you have an application that dependds on /bin/ls printing "?" when it encounters a filename with a byte that cannot be decoded in the current locale and it starts printing \001 instead, that is a relevant consideration according to the updates policy. > > If you're steamed up that the policy requires maintainers to consider their > > impact on end users at all, the onus is on you to make a change to the > > policy. As long as the policy gives the maintainer the ability to explain > > how the pros and cons of updates stack up in their view, however, it doesn't > > seem nearly as bad as you make it out to be. > > The policy is fine as is. The problem is your overreaching definition of > ABI. We could make it explicit that the module interface isn't an > exported ABI by modifying the loader so that third-party modules simply > can't be loaded at all and then this clearly wouldn't be an issue, but I > don't think anyone benefits from us doing that. The definition of ABI is not at issue. The reach of the updates policy itself is. If I'm understanding you correctly you think the updates policy applies to a much more limited scope of changes than I do. I would suggest that that is an indication that the updates policy needs to be reworded in at least certain places so as to more clearly illustrate whether it has a broad scope (in which things like ABI are examples of criteria for deciding not to issue an update) or limited scope (in which ABI is one of the specific criteria for decding to withhold an update.) -Toshio pgpaDnerlkJ8F.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 too late? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 are compiling their own > > kernel modules. > > We *know* we're going to break out of tree modules. It's entirely expected. > There's nothing to consider here at all. > I don't disagree with your first two sentences. In fact I'd go further -- It's not only expected, it's also accepted by you. The third sentence is the only thing that I think needs to be looked at in terms of the Update Policy. The updates policy and the updates vision on which it is based strive to make maintainers realize that pushing updates has both positive and negative effects on end users. Some of those effects are also "expected and accepted". For instance, the updates vision says "Similarly, dealing with a large number of updates on a regular basis is distracting from the user's desired productivity tasks." Simply issuing an update is in and of itself one negative in the updates vision. 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*. Just remember that I am *not* arguing that just because you should be considering it you have to decide that it's more important than you already do. You think of it as a cost of doing business just like the cost to the user of "dealing with a large number of updates" at all. This is a cost that you have implicitly weighed against the benefits of being able to bring new kernels to the end user that fix real bugs, support new hardware, and are otherwise beneficial. I have no problem with you deciding that the benefit amply justifies the cost. -Toshio pgptp5M7FAcDX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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.657346362 -0600 @@ -35,12 +35,8 @@ #ifdef VBOX_WITH_IOMMU #include #include -#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 1, 0) -# include -#else # include #endif -#endif /*** -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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/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:46:55.231412945 -0600 @@ -35,11 +35,7 @@ #ifdef VBOX_WITH_IOMMU #include #include -#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 1, 0) # include -#else -# include -#endif #endif -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 with the >> kernel non-stable ABI policy (which is notorious). >> The least we can do is helping third-party packagers to fix this >> issue, not slamming the door on their face. > > The supported way to provide a module for Fedora is to have it in the > upstream kernel source. Anything else is explicitly not supported. > 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. Of course - caution drove the renaming of this kernel to 2.6.41 so it could break ... that said it does work fine for me ... gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 notorious). > The least we can do is helping third-party packagers to fix this > issue, not slamming the door on their face. The supported way to provide a module for Fedora is to have it in the upstream kernel source. Anything else is explicitly not supported. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 versioning may change in such a way that the module ABI will > > change. Given that any interpretation of the stable update policy that > > prevented us from ever providing kernel security updates would be > > absurd, that's clearly not the correct interpretation. And if the module > > ABI isn't supported, nor is the API. > > > That's not a logical conclusion. As I said in both my previous emails, the > updates policy allows the maintainer to decide that the benefits of a new > version outwiegh the problems. 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. The policy does not require that the kernel maintainers > weigh this more heavily than the need to provide security updates (or new > hardware or major bugfixes). 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 depends on byte 0x9e0 of /bin/ls being 0xdf and an update breaks that, that's not a relevant consideration for the update policy. The kernel module interface is not a supported ABI in Fedora. It's simply not a relevant consideration for the update policy. > If you're steamed up that the policy requires maintainers to consider their > impact on end users at all, the onus is on you to make a change to the > policy. As long as the policy gives the maintainer the ability to explain > how the pros and cons of updates stack up in their view, however, it doesn't > seem nearly as bad as you make it out to be. The policy is fine as is. The problem is your overreaching definition of ABI. We could make it explicit that the module interface isn't an exported ABI by modifying the loader so that third-party modules simply can't be loaded at all and then this clearly wouldn't be an issue, but I don't think anyone benefits from us doing that. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 to break out of tree modules. It's entirely expected. There's nothing to consider here at all. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 stable update policy that > prevented us from ever providing kernel security updates would be > absurd, that's clearly not the correct interpretation. And if the module > ABI isn't supported, nor is the API. > > -- > Matthew Garrett | mj...@srcf.ucam.org > -- 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 least we can do is helping third-party packagers to fix this issue, not slamming the door on their face. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 determination about whether an update is > > > appropriate for a stable update. > > > > > Nonsense. We don't support them but the updates policy as written covers > > them. I quoted the places in the policy in my other mail. If you don't > > like what the updates policy says then change the updates policy to remove, > > amend, or clarify those sections. > > 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 stable update policy that > prevented us from ever providing kernel security updates would be > absurd, that's clearly not the correct interpretation. And if the module > ABI isn't supported, nor is the API. > That's not a logical conclusion. As I said in both my previous emails, the updates policy allows the maintainer to decide that the benefits of a new version outwiegh the problems. 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. The policy does not require that the kernel maintainers weigh this more heavily than the need to provide security updates (or new hardware or major bugfixes). If you're steamed up that the policy requires maintainers to consider their impact on end users at all, the onus is on you to make a change to the policy. As long as the policy gives the maintainer the ability to explain how the pros and cons of updates stack up in their view, however, it doesn't seem nearly as bad as you make it out to be. -Toshio pgp9reAft7PbD.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 update. > > > Nonsense. We don't support them but the updates policy as written covers > them. I quoted the places in the policy in my other mail. If you don't > like what the updates policy says then change the updates policy to remove, > amend, or clarify those sections. 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 stable update policy that prevented us from ever providing kernel security updates would be absurd, that's clearly not the correct interpretation. And if the module ABI isn't supported, nor is the API. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 whether or not that software exists within Fedora. This update > > may be acceptable because the bugs fixed were deemed more worthwhile than > > the changes that were introduced but that decision should not hinge upon the > > availability of affected software within Fedora but upon the popularity of > > such software among users of Fedora, the ease with which that software can > > be made to work with Fedora once the change goes in, and how those questions > > weigh against the issues that are resolved by the new version. > > 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 update. > Nonsense. We don't support them but the updates policy as written covers them. I quoted the places in the policy in my other mail. If you don't like what the updates policy says then change the updates policy to remove, amend, or clarify those sections. However, I also said that the updates policy leaves the decision as a weighted judgement on the maintainer's behalf; the maintainer is free to consider that the bugfixes that the update brings in are more important than the not-in-Fedora-packages that could be broken. I think that is sufficient to cover this case. -Toshio pgpIYwvzTKcfe.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 the bugs fixed were deemed more worthwhile than > the changes that were introduced but that decision should not hinge upon the > availability of affected software within Fedora but upon the popularity of > such software among users of Fedora, the ease with which that software can > be made to work with Fedora once the change goes in, and how those questions > weigh against the issues that are resolved by the new version. > > If those aren't the criteria that we want to use then the updats policy (and > possibly the updates vision) should be amended. please complain on the rpmfusion list why th e hell they are not maintain their packages as they stopped support open-vm-tools for F15 and do not blame fedora that it will not happen again like with F14 that a brand new operating system does not support current hardware and yes a 6 month old release is brand new signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 acceptable because the bugs fixed were deemed more worthwhile than > the changes that were introduced but that decision should not hinge upon the > availability of affected software within Fedora but upon the popularity of > such software among users of Fedora, the ease with which that software can > be made to work with Fedora once the change goes in, and how those questions > weigh against the issues that are resolved by the new version. 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 update. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 break whenever the kernel is updated for the smallest bugfix. http://lxr.linux.no/#linux+v3.1.2/Documentation/stable_api_nonsense.txt Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 noticed that this affects > > VirtualBox. Is this kind of change sanctioned by the > > current update criteria? > > virtualbox is not part of fedora > and vmware is running great after some changes of version.checks > but vmware is also not part of fedora > > better breaking some non-distribution-stuff than as happened with > F14 that current intel machiens with sandy-bridge was not supportted > and forced eople with new hardware way too early to F15/systemd This is a non-argument: kernels 2.6.40.x/3.x broke dual head/xrandr[1] and WLAN[1] for me (on Intel hardware, FWIW). Nils [1]: https://bugzilla.redhat.com/show_bug.cgi?id=731296 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=732592 -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 affects > > VirtualBox. Is this kind of change sanctioned by the > > current update criteria? > > Till, > > The amd_iommu.h header was moved from asm/ to linux/ in kernel 3.1. The > VirtualBox source has a define for version < 3.1 use asm/, else use > linux/. This problem won't be seen by F16 users. It's a small > side-effect in F15 as it is still using 2.6.x kernel versioning. > > As to the update criteria, it would be allowed. VirtualBox is not a > Fedora package. AFAIK the only thing stopping VBox from being a Fedora > package is its required kernel module and Fedora's policy against > out-of-kernel modules. Actually, this isn't correct. Or rather, the update may or may not be allowed by the crieria but it certainly is not allowed for the reason cited. Here's some sippets from the Policy: Introduction: "In general, releases should go from less conservative (rawhide) to more so (the oldest supported stable release)." Beta To Pre Release: [By the Beta stage of a release cycle maintainers MUST::] "# Avoid Major version updates, ABI breakage or API changes if at all possible. " Stable release: Philosophy: "Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience" "ABI changes in general are very strongly discouraged, they force larger update sets on users and they make life difficult for third-party packagers." Stable Release: All other updates: "Package maintainers MUST: * Avoid Major version updates, ABI breakage or API changes if at all possible. " 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 the bugs fixed were deemed more worthwhile than the changes that were introduced but that decision should not hinge upon the availability of affected software within Fedora but upon the popularity of such software among users of Fedora, the ease with which that software can be made to work with Fedora once the change goes in, and how those questions weigh against the issues that are resolved by the new version. If those aren't the criteria that we want to use then the updats policy (and possibly the updates vision) should be amended. -Toshio pgpYHhIpRhIBM.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 criteria? Till, The amd_iommu.h header was moved from asm/ to linux/ in kernel 3.1. The VirtualBox source has a define for version < 3.1 use asm/, else use linux/. This problem won't be seen by F16 users. It's a small side-effect in F15 as it is still using 2.6.x kernel versioning. As to the update criteria, it would be allowed. VirtualBox is not a Fedora package. AFAIK the only thing stopping VBox from being a Fedora package is its required kernel module and Fedora's policy against out-of-kernel modules. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 sanctioned by the > current update criteria? virtualbox is not part of fedora and vmware is running great after some changes of version.checks but vmware is also not part of fedora better breaking some non-distribution-stuff than as happened with F14 that current intel machiens with sandy-bridge was not supportted and forced eople with new hardware way too early to F15/systemd signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
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 sanctioned by the > current update criteria? > > Kind regards > Till > > [0] > https://admin.fedoraproject.org/updates/FEDORA-2011-15856/kernel-2.6.41.1-1.fc15 This has been fixed upstream but F15 kernel is a specific case since it doesn't follow upstream versionning. If we were shipping VirtualBox, this would be quite trivial to fix but we don't (maybe upstream or third party packagers may fix their F15 packages accordingly) http://repo.or.cz/w/virtualbox.git/commit/7456c49fab948cdf02fec626fe87c4e764d75901 best regards, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Changing kernel API / Breaking VirtualBox - update criteria violation?
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 regards Till [0] https://admin.fedoraproject.org/updates/FEDORA-2011-15856/kernel-2.6.41.1-1.fc15 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
