Hi, we have two kernels build on F18 that fix security problems and in F17 kernel-3.8.8-100.fc17 still in updates-testing and kernel-3.8.8-102.fc17 is not even in updates testing, shouldn't this kernels be push to stable , due a security fixes ?
Thanks,
On Sat, Apr 27, 2013 at 3:45 AM, Sérgio Basto sergio@serjux.com wrote:
Hi, we have two kernels build on F18 that fix security problems and in F17 kernel-3.8.8-100.fc17 still in updates-testing and kernel-3.8.8-102.fc17 is not even in updates testing, shouldn't this kernels be push to stable , due a security fixes ?
They get pushed to stable once they've had enough positive testing karma so why don't you install a test kernel and apply karma to ensure it does go through to stable quicker.
Peter
On Sáb, 2013-04-27 at 10:43 +0100, Peter Robinson wrote:
On Sat, Apr 27, 2013 at 3:45 AM, Sérgio Basto sergio@serjux.com wrote:
Hi, we have two kernels build on F18 that fix security problems and in F17 kernel-3.8.8-100.fc17 still in updates-testing and kernel-3.8.8-102.fc17 is not even in updates testing, shouldn't this kernels be push to stable , due a security fixes ?
They get pushed to stable once they've had enough positive testing karma so why don't you install a test kernel and apply karma to ensure it does go through to stable quicker.
The last one is not in testings and other already had my positive karma, before wrote to list . So please someone give positive karma on this link https://admin.fedoraproject.org/updates/FEDORA-2013-6034/kernel-3.8.8-100.fc...
Thanks,
Am 27.04.2013 15:54, schrieb Sérgio Basto:
On Sáb, 2013-04-27 at 10:43 +0100, Peter Robinson wrote:
They get pushed to stable once they've had enough positive testing karma so why don't you install a test kernel and apply karma to ensure it does go through to stable quicker.
The last one is not in testings and other already had my positive karma, before wrote to list . So please someone give positive karma on this link https://admin.fedoraproject.org/updates/FEDORA-2013-6034/kernel-3.8.8-100.fc...
this one is no longer relevant and if there would be a karma-option in koji i would have given as i rolled out 3.8.8-102.fc17.x86_64 in production _______________________________________________
why kernel-3.8.8-100.fc17 is no longer relevant?
http://koji.fedoraproject.org/koji/buildinfo?buildID=414142 CVE-2013-3228 irda: missing msg_namelen update in irda_recvmsg_dgram (rhbz 956069 956071) CVE-2013-3230 l2tp: info leak in l2tp_ip6_recvmsg (rhbz 956088 956089) CVE-2013-3231 llc: Fix missing msg_namelen update in llc_ui_recvmsg (rhbz 956094 956104) CVE-2013-3232 netrom: information leak via msg_name in nr_recvmsg (rhbz 956110 956113) CVE-2013-3233 NFC: llcp: info leaks via msg_name in llcp_sock_recvmsg (rhbz 956125 956129) CVE-2013-3234 rose: info leak via msg_name in rose_recvmsg (rhbz 956135 956139) CVE-2013-3076 crypto: algif suppress sending src addr info in recvmsg (rhbz 956162 956168) CVE-2013-3223 ax25: information leak via msg_name in ax25_recvmsg (rhbz 955662 955666) CVE-2013-3225 Bluetooth: RFCOMM missing msg_namelen update in rfcomm_sock_recvmsg (rhbz 955649 955658) CVE-2013-1979 net: incorrect SCM_CREDENTIALS passing (rhbz 955629 955647) CVE-2013-3224 Bluetooth: possible info leak in bt_sock_recvmsg (rhbz 955599 955607) CVE-2013-3222 atm: update msg_namelen in vcc_recvmsg (rhbz 955216 955228)
On Sáb, 2013-04-27 at 15:59 +0200, Reindl Harald wrote:
this one is no longer relevant and if there would be a karma-option in koji i would have given as i rolled out 3.8.8-102.fc17.x86_64 in production
But 3.8.8-102.fc17.x86_64 is not pushed to updates-testing . Meanwhile kernel-3.8.8-100.fc17 has reached the stable karma threshold and will be pushed to the stable updates repository .
Thanks,
On Mon, 2013-04-29 at 15:01 +0100, Sérgio Basto wrote:
On Sáb, 2013-04-27 at 15:59 +0200, Reindl Harald wrote:
this one is no longer relevant and if there would be a karma-option in koji i would have given as i rolled out 3.8.8-102.fc17.x86_64 in production
But 3.8.8-102.fc17.x86_64 is not pushed to updates-testing . Meanwhile kernel-3.8.8-100.fc17 has reached the stable karma threshold and will be pushed to the stable updates repository .
I think the kernel team has intentionally stopped pushing things to -testing so quickly for F(N-1) because the karma doesn't come in fast enough; if they keep pushing builds to updates-testing as they get done, then they *never* get enough karma to go stable before they get obsoleted by the next one. So they're letting kernels sit in updates-testing for longer in the hopes they'll at least get something pushed stable.
I try to do f-e-k for F(N-1) regularly but I'm not doing a great job of it lately :( We definitely need more people to do it. Thinking about it, the problem may be that people running F(N-1) are typically more 'conservative' users who don't want to enable updates-testing. That's certainly the case for me; my real F(N-1) systems are my servers, and I don't want to run updates-testing on those, obviously. I have to use a VM to do karma runs.
On Qui, 2013-05-02 at 15:22 -0700, Adam Williamson wrote:
On Mon, 2013-04-29 at 15:01 +0100, Sérgio Basto wrote:
On Sáb, 2013-04-27 at 15:59 +0200, Reindl Harald wrote:
this one is no longer relevant and if there would be a karma-option in koji i would have given as i rolled out 3.8.8-102.fc17.x86_64 in production
But 3.8.8-102.fc17.x86_64 is not pushed to updates-testing . Meanwhile kernel-3.8.8-100.fc17 has reached the stable karma threshold and will be pushed to the stable updates repository .
I think the kernel team has intentionally stopped pushing things to -testing so quickly for F(N-1) because the karma doesn't come in fast enough; if they keep pushing builds to updates-testing as they get done, then they *never* get enough karma to go stable before they get obsoleted by the next one. So they're letting kernels sit in updates-testing for longer in the hopes they'll at least get something pushed stable.
I try to do f-e-k for F(N-1) regularly but I'm not doing a great job of it lately :( We definitely need more people to do it. Thinking about it, the problem may be that people running F(N-1) are typically more 'conservative' users who don't want to enable updates-testing. That's certainly the case for me; my real F(N-1) systems are my servers, and I don't want to run updates-testing on those, obviously. I have to use a VM to do karma runs.
OK, also is not normal the number of updates in upstream . Anyway could someone give karma for a bunch of security updates ? https://admin.fedoraproject.org/updates/FEDORA-2013-6999/kernel-3.8.11-100.f...
Please
On Thu, May 2, 2013 at 6:58 PM, Sérgio Basto sergio@serjux.com wrote:
On Qui, 2013-05-02 at 15:22 -0700, Adam Williamson wrote:
On Mon, 2013-04-29 at 15:01 +0100, Sérgio Basto wrote:
On Sáb, 2013-04-27 at 15:59 +0200, Reindl Harald wrote:
this one is no longer relevant and if there would be a karma-option in koji i would have given as i rolled out 3.8.8-102.fc17.x86_64 in production
But 3.8.8-102.fc17.x86_64 is not pushed to updates-testing . Meanwhile kernel-3.8.8-100.fc17 has reached the stable karma threshold and will be pushed to the stable updates repository .
I think the kernel team has intentionally stopped pushing things to -testing so quickly for F(N-1) because the karma doesn't come in fast enough; if they keep pushing builds to updates-testing as they get done, then they *never* get enough karma to go stable before they get obsoleted by the next one. So they're letting kernels sit in updates-testing for longer in the hopes they'll at least get something pushed stable.
I try to do f-e-k for F(N-1) regularly but I'm not doing a great job of it lately :( We definitely need more people to do it. Thinking about it, the problem may be that people running F(N-1) are typically more 'conservative' users who don't want to enable updates-testing. That's certainly the case for me; my real F(N-1) systems are my servers, and I don't want to run updates-testing on those, obviously. I have to use a VM to do karma runs.
OK, also is not normal the number of updates in upstream . Anyway could someone give karma for a bunch of security updates ? https://admin.fedoraproject.org/updates/FEDORA-2013-6999/kernel-3.8.11-100.f...
It's become enough of a problem that if we don't start getting more testers on the oldest release, the kernel team is probably going to break it's rule of not allowing the kernel maintainers give karma to kernel updates. So yes, more help on the oldest release is much needed.
josh
On Sex, 2013-05-03 at 07:13 -0400, Josh Boyer wrote:
On Thu, May 2, 2013 at 6:58 PM, Sérgio Basto sergio@serjux.com wrote:
On Qui, 2013-05-02 at 15:22 -0700, Adam Williamson wrote:
On Mon, 2013-04-29 at 15:01 +0100, Sérgio Basto wrote:
On Sáb, 2013-04-27 at 15:59 +0200, Reindl Harald wrote:
this one is no longer relevant and if there would be a karma-option in koji i would have given as i rolled out 3.8.8-102.fc17.x86_64 in production
But 3.8.8-102.fc17.x86_64 is not pushed to updates-testing . Meanwhile kernel-3.8.8-100.fc17 has reached the stable karma threshold and will be pushed to the stable updates repository .
I think the kernel team has intentionally stopped pushing things to -testing so quickly for F(N-1) because the karma doesn't come in fast enough; if they keep pushing builds to updates-testing as they get done, then they *never* get enough karma to go stable before they get obsoleted by the next one. So they're letting kernels sit in updates-testing for longer in the hopes they'll at least get something pushed stable.
I try to do f-e-k for F(N-1) regularly but I'm not doing a great job of it lately :( We definitely need more people to do it. Thinking about it, the problem may be that people running F(N-1) are typically more 'conservative' users who don't want to enable updates-testing. That's certainly the case for me; my real F(N-1) systems are my servers, and I don't want to run updates-testing on those, obviously. I have to use a VM to do karma runs.
OK, also is not normal the number of updates in upstream . Anyway could someone give karma for a bunch of security updates ? https://admin.fedoraproject.org/updates/FEDORA-2013-6999/kernel-3.8.11-100.f...
It's become enough of a problem that if we don't start getting more testers on the oldest release, the kernel team is probably going to break it's rule of not allowing the kernel maintainers give karma to kernel updates. So yes, more help on the oldest release is much needed.
bodhi - 2013-05-02 23:02:24 This update has reached the stable karma threshold and will be pushed to the stable updates repository
bodhi - 2013-05-03 02:00:46 This update has been pushed to testing
kernel was approved before be pushed to testing , will be push to stable or not ?
Thanks,
Am 03.05.2013 13:13, schrieb Josh Boyer:
On Thu, May 2, 2013 at 6:58 PM, Sérgio Basto sergio@serjux.com wrote:
OK, also is not normal the number of updates in upstream . Anyway could someone give karma for a bunch of security updates ? https://admin.fedoraproject.org/updates/FEDORA-2013-6999/kernel-3.8.11-100.f...
It's become enough of a problem that if we don't start getting more testers on the oldest release, the kernel team is probably going to break it's rule of not allowing the kernel maintainers give karma to kernel updates
maybe a good idea because users may often not aware that one of the latest updates fixed 12 CVE's and there are very few breakages from the point fedora started to push recent kernels - well i follow koji and test at my own without to care about karma from others, but that's not everybody
BTW: currently i have 3.9.0-301.fc19.x86_64 on two F18 machines one of them is acting as router/vpn-gateway/firewall/WLAN-AP and personal server including VMware workstation with a bunde of backup- and test-VM's and after my F18-testserver-VM did run for days fine with the 3.9-F19 build i decided today to give it a chance on my personal production machines
all fine and smooth _______________________________________________________________
router-machine (HP Compaq Elite 8300 CMT)
[root@srv-rhsoft:~]$ uname -r; cat /etc/redhat-release 3.9.0-301.fc19.x86_64 #1 SMP Mon Apr 29 13:44:05 UTC 2013 Fedora release 18 (Spherical Cow)
this one is connecting different VPN-networks, has a SIP-phone on the LAN-bridge and does anything a machine can do (networking, ftp, email, http, dns, dhcp, NAT...)
* br0 * eth0 * eth1 * tap0 * vmnet8 * wlan0
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) 00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 (rev c4) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4) 00:1f.0 ISA bridge: Intel Corporation Q77 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) 01:00.0 Network controller: Atheros Communications Inc. AR5418 Wireless Network Adapter [AR5008E 802.11(a)bgn] (PCI-Express) (rev 01) 02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection _______________________________________________________________
workstation at the office (HP Compaq Elite 8200 CMT):
[root@rh:~]$ uname -r; cat /etc/redhat-release 3.9.0-301.fc19.x86_64 #1 SMP Mon Apr 29 13:44:05 UTC 2013 Fedora release 18 (Spherical Cow)
* bond0 * br0 * eth0 * eth1 * vmnet8
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4) 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4) 00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b4) 00:1c.7 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 8 (rev b4) 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4) 00:1f.0 ISA bridge: Intel Corporation Q67 Express Chipset Family LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04) 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 02:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) 03:00.0 Mass storage controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01)
Dne 3.5.2013 00:22, Adam Williamson napsal(a):
On Mon, 2013-04-29 at 15:01 +0100, Sérgio Basto wrote:
On Sáb, 2013-04-27 at 15:59 +0200, Reindl Harald wrote:
this one is no longer relevant and if there would be a karma-option in koji i would have given as i rolled out 3.8.8-102.fc17.x86_64 in production
But 3.8.8-102.fc17.x86_64 is not pushed to updates-testing . Meanwhile kernel-3.8.8-100.fc17 has reached the stable karma threshold and will be pushed to the stable updates repository .
I think the kernel team has intentionally stopped pushing things to -testing so quickly for F(N-1) because the karma doesn't come in fast enough; if they keep pushing builds to updates-testing as they get done, then they *never* get enough karma to go stable before they get obsoleted by the next one. So they're letting kernels sit in updates-testing for longer in the hopes they'll at least get something pushed stable.
Well I would welcome as well, if the newer build would not always obsolete the older build. Is there planned such feature for Bodhi?
Thanks
Vít
On 3 May 2013 14:25, Vít Ondruch vondruch@redhat.com wrote:
me as well, if the newer build would not always obsolete the older build. Is there planned such feature for Bodhi?
I would also like to see it implemented. I would like to have the option to leave updates in "pending" waiting for confirmation rather than always overwriting the ones in "testing".
Regards, --Simone
-
Adam Williamson -
Josh Boyer -
Peter Robinson -
Reindl Harald -
Simone Caronni -
Sérgio Basto -
Vít Ondruch