I created a merge request for desktop-data three weeks ago. It's just
a minor patch that doesn't really fix anything but a warning from
kbuildsycoca4. I'm not sure about how Gitorious works, maintainers are
supposed to notice the "1" in the merge requests section or they
receive an email notifying it?
And since I'm on it. Since I updated my 11.3 system to KDE to 4.5 the
"inline" part of the menu is not honored... Expected behavior? Known
problem?
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all -
Since technically we're in feature freeze for 11.4, I thought I'd put
this out for discussion.
Factory is currently using 2.6.36 which was released 3 weeks ago.
Upstream versions tend to take about 10-11 weeks, on average, to
release. The scheduled release for the first openSUSE RC is Jan 20.
The scheduled release for the first RC is Jan 20. The typical
development time for a kernel release, on average, is about 10-11 weeks.
That puts the release of 2.6.37 around Dec 29 to Jan 12.
That sounds like kind of a tight window, but the reality is that the
differences in the later kernel RCs tend to be small and fix bugs. The
"real" development happens in -rc1, which was released about two weeks
ago. Later -rcs serve to stabilize the development that went into -rc1.
So, the the feature freeze aspect of it will be a one-shot, when I
update to -rc1. (Actually, I hardly ever update to -rc1 and instead use
- -rc2 which tends to be more stable).
I've already done the merge work for 2.6.37-rc1 since the master kernel
always tracks the latest upstream. Xen is the lone exception, as it
usually is, but Jan Beulich has been great about getting that completed
shortly after I do the update. This time might be a little more
difficult because much of the Xen code has been merged into the mainline
kernel so there's some sorting out to be done.
As far as testing goes, we're still early enough that we won't lose a
lot of effort. I'd update Factory to 2.6.37-rc2 as soon as it is
released upstream, which should be this week. Our usual corps of
dedicated testers can dig in quickly. In my experience, though, the
number of testers drastically increases around the RC1 release. I wish
it weren't so, but it is. So revving the kernel now isn't likely to toss
out a lot of testing.
The biggest "feature" I'm going for is not having to backport fixes from
2.6.37. The BKL removal patches and the VFS scalability patches are
going to improve performance on multicore systems. The removal of I/O
barriers should also be pretty noticeable but I haven't had time to
verify that yet.
So, opinions?
- -Jeff
Features that are going into 2.6.37:
- - The inode portion of the VFS scalability patches
- - More BKL removal, including parts of the core kernel
- - Block I/O can be throttled via cgroups
- - Simple pNFS support
- - In-kernel PPTP (tunneling) acceleration
- - "Lazy" inode table creation for ext4 to allow faster fs creation
- - Batched discard support, which allows the file system to advise the
block layer to use the TRIM command. This allows online TRIMs, but
is only implemented in ext4 so far.
- - Xen dom0 support (mostly)
- - The usual round of bug fixes.
- - fanotify
- - Block barriers have been removed[1]
Drivers:
- - Systems and processors:
- Flexibility Connect boards
- Telechips TCC ARM926-based systems
- Telechips TCC8000-SDK development kits
- Vista Silicon Visstrim_m10 i.MX27-based boards
- LaCie d2 Network v2 NAS boards
- Qualcomm MSM8x60 RUMI3 emulators
- Qualcomm MSM8x60 SURF eval boards
- Eukrea CPUIMX51SD modules
- Freescale MPC8308 P1M boards
- APM APM821xx evaluation boards
- Ito SH-2007 reference boards
- IBM "SMI-free" realtime BIOS's
- MityDSP-L138 and MityDSP-1808 systems
- OMAP3 Logic 3530 LV SOM boards
- OMAP3 IGEP modules
- taskit Stamp9G20 CPU modules
- aESOP Samsung S5PV210-based Torbreck boards
- - Block:
- Chelsio T4 iSCSI offload engines
- Cypress Astoria USB SD host controllers
- Marvell PXA168/PXA910/MMP2 SD host controllers
- ST Microelectronics Flexible Static Memory Controllers
- - Input:
- Roccat Pyra gaming mice
- UC-Logic WP4030U, WP5540U and WP8060U tablets
- several varieties of Waltop tablets
- OMAP4 keyboard controllers
- NXP Semiconductor LPC32XX touchscreen controllers
- Hanwang Art Master III tablets
- ST-Ericsson Nomadik SKE keyboards
- ROHM BU21013 touch panel controllers
- TI TNETV107X touchscreens
- - Miscellaneous:
- Freescale eSPI controllers
- Topcliff platform controllher hub devices
- OMAP AES crypto accelerators
- NXP PCA9541 I2C master selectors
- Intel Clarksboro memory controller hubs
- OMAP 2-4 onboard serial ports
- GPIO-controlled fans
- Linear Technology LTC4261 Negative Voltage Hot Swap Controller I2C
interfaces
- TI BQ20Z75 gas gauge ICs
- OMAP TWL4030 BCI chargers
- ROHM ROHM BH1770GLC and OSRAM SFH7770 combined ALS and proximity sensors
- Avago APDS990X combined ALS and proximity sensors
- Intersil ISL29020 ambient light sensors
- Medfield Avago APDS9802 ALS sensor modules
- Basic, memory-mapped GPIO controllers
- Intel Topcliff GPIO controllers
- Intel Moorestown/Medfield i2c controllers
- IDT CPS Gen.2 SRIO RapidIO switches
- Freescale i.MX DMA engines
- ARM PrimeCell PL080 or PL081 DMA engines
- Cypress West Bridge Astoria controllers
- USB ENE card readers
- Asahi Kasei AK8975 3-axis magnetometers
- OLPC XO display controller devices
- Analog Devices AD799x analog/digital converters
- Winbond/Nuvoton W83795G/ADG hardware monitoring chips
- Flarion OFDM usb and pcmcia modems
- Maxim MAX8952 and MAX8998 Power Management ICs
- National Semiconductors LP3972 PMIC regulators
- Broadcom BCM63xx hardware watchdogs
- - Network:
- Brocade 1010/1020 10Gb Ethernet cards
- Conexant CX82310 USB ethernet ports
- Atheros AR9170 "otus" 802.11n USB devices
- Topcliff PCH Gigabit Ethernet controllers
- Intel Topcliff platform controller hub CAN interfaces
- Technologic Systems TS-CAN1 PC104 peripheral boards
- SBE wanPMC-2T3E3 interfaces
- RealTek RTL8712U (RTL8192SU) Wireless LAN NICs (replaces older
rtl8712 driver)
- Atheros AR6003 wireless interface controllers
- Beeceem USB Wimax adapters
- Broadcom bcm43xx wireless chipsets
- - Sound:
- Marvell 88pm860x codecs
- TI WL1273 FM radio codecs
- HP iPAQ RX1950 audio devices
- Native Instruments Traktor Kontrol S4 audio devices
- Aztech Sound Galaxy AZT1605 and AZT2316 ISA sound cards
- Wolfson Micro WM8985 and WM8962 codecs
- Wolfson Micro WM8804 S/PDIF transceivers
- Samsung S/PDIF controllers
- Cirrus Logic EP93xx AC97 controllers
- Intel MID SST DSP devices
- - USB: Intel Langwell USB OTG transceivers
- YUREX "leg shake" sensors
- USB-attached SCSI devices
- - Video4Linux2: remotes using the RC-5 (streamzap) protocol
- Konica chipset-based cameras
- Sharp IX2505V silicon tuners
- LME2510 DM04/QQBOX USB DVB-S boxes
- Samsung s5h1432 demodulators
- Several new Conexant cx23417-based boards
- Nuvoton w836x7hg consumer infrared transceivers
- OmniVision OV6650 sensors
- OMAP1 camera interfaces
- Siliconfile SR030PC30 VGA cameras
- Sony imx074 sensors
- VIA integrated chipset camera controllers
- -Jeff
[1] This is because they were a very big hammer that had a reputation
for killing performance. They're necessary for safely using journals on
devices with write caching enabled, but were implemented by flushing the
entire I/O queue to physical media -- not just "to disk" which includes
the disk's write cache. The new implementation will still use the
flush-to-media feature but will not stall the i/o queue.
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAkzhW0YACgkQLPWxlyuTD7JgBACbBfR+uJwfKKnEcBZIg/KeIj/S
hikAnRiL9nG50QoKZkrn1AsmGljnGvYn
=T/Hp
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
openSUSE 11.3 on one box and openSUSE 11.4 Milestone 4 on the other.
I have a message that says the built modules not found. When I check
e.g /lib/modules/2.7.37-rc3-git7-smp, most modules are zero bytes long.
I have to "make modules_install" and use modprobe on each.
To get the network up on the 11.3 box "modprobe r6189" then "rcnetwork
restart", "modprobe rtl8187", "/etc/init.d/network-remotefs start",
etc., etc.
Then ifconfig is OK for those devices.
eth_s1_0 Link encap:Ethernet HWaddr 00:1C:F0:BB:14:E1
inet addr:192.168.10.10 Bcast:192.168.10.255 Mask:255.255.255.0
inet6 addr: fe80::21c:f0ff:febb:14e1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1927 errors:0 dropped:0 overruns:0 frame:0
TX packets:1923 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:287532 (280.7 Kb) TX bytes:283044 (276.4 Kb)
Interrupt:17 Base address:0xe000
wlan0 Link encap:Ethernet HWaddr 00:15:AF:23:04:37
inet addr:192.168.1.4 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::215:afff:fe23:437/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25 errors:0 dropped:0 overruns:0 frame:0
TX packets:62 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4324 (4.2 Kb) TX bytes:18470 (18.0 Kb)
On 11.3 module-init-tools-3.12-1.3.x86_64
On 11.4 Milestone 4 module-init-tools-3.12-5.3.x86_64
tindog:/usr/src/linux-2.6.37-rc3-git7 # grep MODULE .config
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODULE_SRCVERSION_ALL=y
Another guy has emailed me saying he's seen the same.
11.3
====
gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292] (SUSE Linux)
11.4 Milestone 4
================
gcc version 4.5.1 20101116 [gcc-4_5-branch revision 166793] (SUSE Linux)
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Building xine-lib-1.1.19 on 11.3 x86_64, I hit this error.
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
/usr/lib64/libxcb-shape.a(shape.o): relocation R_X86_64_32 against
`.rodata' can not be used when making a shared object; recompile with
-fPIC
/usr/lib64/libxcb-shape.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[3]: *** [xineplug_vo_out_xcbshm.la] Error 1
make[3]: Leaving directory `/ftp/dec10/xine-lib-1.1.19/src/video_out'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/ftp/dec10/xine-lib-1.1.19/src/video_out'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/ftp/dec10/xine-lib-1.1.19/src'
make: *** [all-recursive] Error 1
It was a rogue library lying around from 2009
"zypper rm xorg-x11-libxcb-unstable-devel" fixed it.
When zypper upgraded it installed xorg-x11-libxcb-devel and left files
from the old one in place. It seems it's not able to detect and deal
with a package name that differs but offers largely the same files, so
it leaves any file that isn't part of the current package in place.
In fact it leaves the old package installed.
I shall open a bug later.
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I know the rescue option in the dvd had to be dropped. Too problematic,
and no maintainer.
Could some of it be "rescued"?
The thing that fails most is grub. Just a repair grub, perhaps a repair
missing kernel/initrd?
Once the system boots, the user should be able to repair the rest (hope).
:-)
- --
Cheers,
Carlos E. R.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
iEYEARECAAYFAkyodsMACgkQtTMYHG2NR9W3mACeL4xQWJevZF3nzSzbYWKtz3dP
yQMAnjtrUrfJRGrGfoyEouiJN6Q2XH37
=T2Uo
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/24/2010 12:05 AM, Mike Galbraith wrote:
> FYI, this isn't limited to openSUSE factory. Peterz has a repeatable
> testcase now (kvm image), and is tracing through it. Systemd is
> triggering a strange use after free cgroups problem.
Yep, but we knew that already. I was able to reproduce it with a vanilla
kernel with the desktop config. CONFIG_PREEMPT seemed to have caused the
difference.
> In about 12 hours, I should have a copy of the thing to play with.
> Hopefully, Peter will have it all figured out before that, as cgroup.c
> is hard to read.
Even better.
Thanks for looking into this.
- -Jeff
> -Mike
> https://lkml.org/lkml/2010/6/29/22
>
> On Thu, 2010-12-23 at 13:33 +0100, Peter Zijlstra wrote:
>
>> systemd-1 0d..1. 2070793us : sched_destroy_group: se: f69e43c0, load: 1024
>> systemd-1 0d..1. 2070794us : sched_destroy_group: cfs_rq: f69e4720, nr: 1, load: 1024
>> systemd-1 0d..1. 2070794us : __print_runqueue: cfs_rq: f69e4720, nr: 1, load: 1024
>> systemd-1 0d..1. 2070795us : __print_runqueue: curr: (null)
>> systemd-1 0d..1. 2070796us : __print_runqueue: se: f6a8eb4c, comm: systemd-tmpfile/1243, load: 1024
>> systemd-1 0d..1. 2070796us : _raw_spin_unlock_irqrestore <-sched_destroy_group
>>
>> So somehow it manages to destroy a group with a task attached.
>
> Its even weirder:
>
> systemd-1 0d..1. 1663489us : sched_destroy_group: se: f69e7360, load: 1024
> systemd-1 0d..1. 1663489us : sched_destroy_group: cfs_rq: f69e72a0, nr: 1, load: 1024
> systemd-1 0d..1. 1663491us : __print_runqueue: cfs_rq: f69e72a0, nr: 1, load: 1024, cgroup: /system/systemd-sysctl.service
> systemd-1 0d..1. 1663491us : __print_runqueue: curr: (null)
> systemd-1 0d..1. 1663493us : __print_runqueue: se: f69d95bc, comm: systemd-sysctl/1209, load: 1024, cgroup: /
> systemd-1 0d..1. 1663496us : do_invalid_op <-error_code
>
> The task enqueued to the cfs_rq doesn't match the cgroup, the thing is,
> I don't see a cpu_cgroup_attach/sched_move_task call in the log, nor
> does a BUG_ON() validating the task's cgroup against the cfs_rq's cgroup
> on account_entity_enqueue() trigger.
>
> So it looks like a task changes cgroup without passing through the
> cgroup_subsys::attach method, which afaict isn't supposed to happen.
>
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAk0U6UMACgkQLPWxlyuTD7IBcQCfZFsaNG0N9HxKxPRwjbyydKxc
XqIAniqZ7HKSAF72pWeM8D0bmT2YtT3E
=LUzP
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi all,
stable virtualbox 4.0.0 will be soon in Factory (I hope:) so here are
few announces:
if you will do update from Milestone2,3,4, 5 or from Factory you have
to remove virtualbox-ose-qt package and install virtualbox-qt by hand
(sorry I really don't know how to trigger update in this case for
virtualbox-ose-qt without adding auxiliar subpackage) - update from
11.3 to 11.4 will work fine
Also I want to announce few (I think major) changes in our virtualbox
package(sr#56739,56738):
1, dropped OSE postfix for vbox's main package and all subpackages
- since 4.0.0 Oracle team doesn't build PUEL version so ose postfix is
not needed
- this means : virtualbox-ose will be deleted from Factory and new
virtualbox package will appear
- devel repo will change from Virtualization:virtualbox-ose to
Virtualization:virtualbox
2, renamed xorg-x11-driver-virtualbox-ose subpackage to virtualbox-guest-x11
- this package doesn't contain only x11 drivers but also tools for
propper x11 guest integration (same name for this stuff use also
debian)
3, update to first 4.0.0 stable release
4,added "Provides: virtualbox-gui" line for virtualbox-qt subpackage
and "Recommends: virtualbox-gui" line for virtualbox package (this is
related to vboxgtk package - I will also create sr for this package
soon )
Also I want to apologize to people who wants to have
VBoxGuestAdditions.iso in our virtualbox package, I decide to NOT
include it to our package for now (again), I think linux and windows
binaries grabbed from outside of buildservice is not standard way how
we do packaging in bs - also as I said many times user could still
download iso using the gui menu.
suggestions, comments, tips are welcome !
bye
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
hello,
I installed mail-notification by Yast.
But now I can't find the package with Software.
Does anyone knows what went wrong ?
Roelof
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Dear List mates,
Will openSUSE 11.4 finally introduce a boot up process that will
eliminate the flicker during the boot up to desktop?
Now that we are introducing systemd, wouldn't this be the ideal time to
fix this? Maybe we'll see Plymouth?
--
Cheers!
Roman
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
