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
I wonder whether our IPv6 settings are the right ones after reading the following article (sorry, German only):
http://www.heise.de/newsticker/meldung/IPv6-Smartphones-gefaehrden-Privatsp…
which references:
http://www.heise.de/netze/hotline/IPv6-anonym-1100727.html
We set use_tempaddr to 0 by default (disabling privacy extensions) and set it to 1
if enabled. The article advises to use 2.
Background: By default (value 0) my IPv6 address will be derived from my hardware
(macaddr) and therefore be the same independend how I connect to the internet. So,
it's easy to track my computer...
So, my proposal is to do the following two changes:
* Use 2 instead of 1 in /etc/rc.d/boot.ipconfig for enabling the privacy extensions
* Set IPV6_PRIVACY=yes in /etc/sysconfig/sysctl
Any concerns with this change?
Btw. here's an Ubuntu bugreport:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/176125
and Windows (since XP) is doing it the same way on desktops.
Andreas
--
Andreas Jaeger, Program Manager openSUSE, aj(a){novell.com,opensuse.org}
Twitter: jaegerandi | Identica: jaegerandi
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Maxfeldstr. 5, 90409 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
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 -
I know someone else mentioned this briefly WRT to Tumbleweed, but I'd
like to bring up for discussion the adoption of gcc 4.6 for Factory.
A bit of background. We currently maintain a kernel-trace flavor to
allow people to make use of the tracing facilities. Historically, there
has been overhead associated with these, which is why they were in their
own flavor. Most users don't care about them, so there's no sense in
slowing everyone down to satisfy them. Over time, the maintainers of
these facilities have worked to lower the overhead to the point where
now dynamic ftrace only adds memory overhead. It uses gcc's profiling
facility to call out to a function at the beginning of every function
call to allow tracking. At boot, this is a function that returns
immediately but during the boot process those calls are hot-patched to
nop operations so that they carry virtually zero runtime overhead.
This sounds great, right? There's one last bit, and that is actually the
reason why ftrace is still disabled in our regular kernel flavors. The
compiler's profiling feature calls the profiling function after the
function prologue. That means that the stack pointer has already been
advanced and since it can advance a different amount based on the needs
of each function, we don't have an easy way to get the caller's stack
frame back. It's needed to resolve where the caller was called from and
the only way to do that is to dedicate a register to track the start of
the current stack frame. Dedicating a register for this increases
register contention and forces more accesses to CPU cache or main
memory, slowing everything down. So, it's not worth it when most users
will never actually take advantage of the feature that requires it.
For some time, I've been trying to come up with ways to work around this
so that the fast path stays fast and the tracing path takes any
performance hit necessary. Until recently, the performance hit would've
been too big to make it worthwhile. With gcc 4.6, we have the -mfentry
option which moves the call to the profiling function *before* the
function's prologue. This means that the caller's stack frame is still
intact and we can resolve the caller's parent without issue. I've spent
the past few days working up a proof of concept that takes advantage of
this and doesn't require a dedicated register. It turns out that Steven
Rostedt has already posted a patch set to do exactly this and he's
targeting 2.6.40 for inclusion in the mainline kernel. For now it looks
like it's x86-64 only but it should be ok for i386 as well.
This would go a long way to eliminate the -trace flavor from our kernel
packages. The benefits are multiple: It eliminates the maintenance of
another kernel flavor, but it also allows everyone to use tracing
facilities without installing a separate kernel release to do so.
One last bit is needed, though, and that is for gcc to allow using -pg
- -mfentry with -fomit-frame-pointers. Once that bit is taken care of then
we can rid the kernel of the frame pointer requirement for ftrace and
eliminate the -trace flavor entirely.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAk263RwACgkQLPWxlyuTD7JhyQCfXcCcDjH0dYmnoguTCe+7J2FH
YWkAn3+K1qintX3acivGSmUYCDVnDuqi
=3BMz
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
I need the gtkglextmm-devel package to build a program I want. It
seems to be available for every openSUSE release besides 11.4. Is
there a particular reason this package is incompatible with openSUSE
11.4?
-Todd
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi,
Today, hopefully, we'll finish the review of GNOME 3 packages for G:F.
There's some integration work to do and patches to rebase (we filed bugs
for all of those), but I believe none of this should block a push to
Factory.
If the testing of G:F goes well this week, I'd like to do the push at
the end of the week.
I'd like to hear what people think is best to deal with this push, as it
will be a big push, that needs to be handled with some care:
+ some package have really a lot of changes, and it's painful to review
that (which is partly why it took so much time to review the changes)
+ there are some new packages we can't submit before the push because
they will cause issues in Factory (eg, providing a library that exist
in another package in Factory)
+ there are some new packages that are just the 2.x/3.x branches of
existing packages (gtkmm2 vs gtkmm3, for example)
+ we probably will need a rebuild of everything since it'll be hard to
push/accept packages in the best order in terms of build dependencies
+ if we need to freeze Factory soon (for a milestone, eg), we can't
have half of the packages accepted and the other half rejected
Do you have any opinion on what's best? Should we just push everything as
usual, or do you want us to take some extra care in some way?
Thanks,
Vincent
--
Les gens heureux ne sont pas pressés.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
http://download.opensuse.org/YaST/Repos/openSUSE_114_Servers.xml
gives 403 - Permission denied. This means the "add community repository"
feature in YaST doesn't work. Could someone take a look?
Anders
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Just a short note saying that I've added the latest xfce4 update to
Tumbleweed. It has survived my limited testing, and if anyone has any
problems with it, please let me know.
Next up, KDE 4.6.2...
thanks,
greg k-h
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi,
As part of the Contrib-Repository Cleanup I would like to include the package
pngtoico into Factory. As the name suggests it is used to transform an icon
from the PNG to the ICO format.
It has been around since 2002, so one can safely say it's well tested, the
last update happend in 2006. There is no real upstream project, though. The
code can be retrieved from
http://www.kernel.org/pub/software/graphics/pngtoico/ and is simple enough
that, if ever an issue comes up, it should be fixable by the maintainer, aka.
me. Als the original author is known it should also be possible to merge such
a fix upstream.
Users are developers, web or code, that still need to support applications
that make use of the ICO format, e.g. when porting from windows.
The license of the package is GPL 2 or later.
Regards,
Matthias
--
Matthias Bach
www.marix.org
„Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig
über diese hinaus in das Unmögliche vorzustoßen.“ - Arthur C. Clarke
