openSUSE Factory June 2011

factory@lists.opensuse.org

115 participants
97 discussions

[opensuse-factory] KDE menus and gitorious

by Cristian Morales Vega

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

8 years, 8 months

[opensuse-factory] Kernel for 11.4?

by Jeff Mahoney

-----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

9 years, 10 months

[opensuse-factory] IPV6 privacy in openSUSE

by Andreas Jaeger

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

9 years, 10 months

[opensuse-factory] HAL and related

by Ilya Chernykh

First of all I want to ask whether hal will be available under 12.1 or it is to be decided? My second question is as follows. As you know, hal is depreciated and people who prepare 12.1 want to remove dependency on hal from different packages. For instance they want to remove it from kdebase3-runtime which will be included in 12.1. But hal is necessary for normal function of KDE3 so we, who use KDE3 as a desktop want hal functions to be enabled. That's why my question. Is it possible to build a package with hal if hal is available in the repository and without hal otherwise? How to properly organize the check on whether the package exists in the repo at the buildtime? Or may be another solution based on an option constant defined in the project's properties is better? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

10 years

[opensuse-factory] I'm a user, and I don't want systemd

by Joe User

Users who want systemd can choose it during install. But it's too big a change to be the default choice. I don't want to change, until it's been proven and polished for several years. I'm also opposed to dumping everything into /usr. I *like* having /bin vs. /usr/bin, /lib vs. /usr/lib, and /sbin vs. /usr/sbin. If you need shared read only mounts for executables, then improve mount and/or the kernel so you can easily mount multiple paths all at once, to the same device. Don't force your organizational prejudices on me. I'm a user, and I want what I want. Question is, do you want users, or not? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

10 years

[opensuse-factory] guile 2.0

by Petr Gajdos

Hi all, I am about to submit guile 2.0.1 into Factory if no one have any objections. It requires newer gc, I have chosen 7.2alpha6. gnucash will get updated to 2.4.6 by the way. gnome-games, trackballs and autogen packages wanted some small changes to build against new guile, I have named them %{name}-guile-2.0.patch. I am still working on lilypond, I hope I will finish it soon. See home:pgajdos:guile19x for details. Any comments? Petr

10 years

[opensuse-factory] The road to systemd for openSUSE 12.1

by Frederic Crozat

Hi all, systemd is coming for next openSUSE (12.1) scheduled next fall. I'll help for systemd integration in openSUSE Factory[1] and will act as an interface between you (openSUSE testers, packagers, developers) and systemd upstream. As you might guess, switching boot manager is not a trivial task and issues will be found. So, we want to have as much feedback and testing as possible, to try to tackle as much (if not all) issues in time for 12.1. Here is our action plan, in several phases: * phase 1: detecting current issues with systemd. Install systemd package and "manually" boot with it, by adding "init=/bin/systemd" at you kernel boot command line. In this setup, we want to find ALL the issues caused by switching to systemd, so please, check systemd on Factory status page[2] and follow the instructions there to fill bug reports. We also want to ensure there is no regression, when using legacy sysvinit initscripts with systemd as boot manager. * phase 2: systemd-sysvinit package installed by default and replace sysvinit. * phase 3: providing systemd unit files to replace legacy sysvinit initscripts: this is a huge task which won't be completed before openSUSE 12.1, but it can be parallelized among a lot of people (ideally, each packager should be able to create unit systemd file). And we should also split this effort in manageable milestones : * phase 3.1: GNOME and KDE live CDs should only use "native" systemd, without any sysvinit involved * phase 3.2: installed system using GNOME and KDE live CDs be a "native" systemd (this involves testing additional paths in live installer) * phase 3.3: install from DVD for GNOME and KDE should be "native" systemd Of course, providing systemd unit file should not be a pure "openSUSE" task, because the ultimate goal for those files is to be cross-distribution and merged in relevant upstream projects. And we also don't want to duplicate effort which is starting in other distributions like Fedora, so, collaboration is key. I strongly recommend reading systemd for Administrators, Part III[3] post about the conversion (and also all other posts : systemd for Administrators #1, #2, #3, #4, #5, #6, #7,#8 they are highly instructive[4]). For discussing / helping with systemd integration for Factory, please use opensuse-factory mailing list or go to #opensuse-factory IRC channel on Freenode. We need your help to make sure openSUSE 12.1 will use systemd at 200% ;) [1]http://en.opensuse.org/SDB:Systemd [2]http://en.opensuse.org/openSUSE:Systemd_status [3]http://0pointer.de/blog/projects/systemd-for-admins-3.html [4]http://0pointer.de/blog/projects/systemd-for-admins-1.html http://0pointer.de/blog/projects/systemd-for-admins-2.html http://0pointer.de/blog/projects/systemd-for-admins-3.html http://0pointer.de/blog/projects/systemd-for-admins-4.html http://0pointer.de/blog/projects/three-levels-of-off http://0pointer.de/blog/projects/changing-roots.html http://0pointer.de/blog/projects/blame-game.html http://0pointer.de/blog/projects/the-new-configuration-files -- Frederic Crozat <fcrozat(a)suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

10 years

[opensuse-factory] New package hdjmod

by Matthias Bach

Hi, I would like to introduce hdjmod to Factory. Hdjmod is a kernel module providing support for Hercules DJ Devices (USB MIDI device). The package has been available in Contrib for quite a while and is now in hardware. Having the will broaden the distributions hardware support. Sadly the package is not continuously developed upstream, but has been provided as is for openSUSE 11.1 by the hardware vendor (Hercules). I have since adapted the package to the newer kernels at each release. With this experience I am confident I can continue to maintain this package for many more releases, though it would of course be nice if somebody integrated this module into vanilla. ;) Below you'll find some additinal information on the package. Regards, Matthias Homepage ======= http://ts.hercules.com/ger/index.php?pg=view_files&gid=17&fid=62&pid=177&ci… License ===== GPL 2 Author ==== Philip Lukidis -- 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

10 years

[opensuse-factory] Are there plans for changing the default browser?

by Kim Leyendecker

Dear all! Like my feature request here: https://features.opensuse.org/312585 I want to ask you, f there some plans to change the default browser. The background of that is, that Mozilla, and the new model of development, could be a factor of more work for our packagers and testers. Switching to another browser by default could be more easy to us, because Firefox could be a potential breaker for the next releases (I remember, that there where several add-ons which didin´t worked with FF 4 and now doesn´t for with FF 5 too. Maybe a change from Firefox to Iceweasel could be the solution. From my point of view, Mozilla is doing a lot wrong from the release of Firefox 4.0 till today and this could destroy the goal, to deliver a *stable* release. Firefox isn´t that bad at all, but I think the new release policy from Mozilla just slam down the distributor´s plans. Mozilla tries to take over the Linux development model and is doing a capital mistake: *On Linux, new releases are coming every 3 months, but the old are still supported *On Firefox, the FF 4.x line ends right now after the release of 5.0 This makes it more difficult for the packagers to deliver a *recent* _and_ *supported* distribution. Maybe a change could be the right way here, but maybe it´s just my personal feeling!? What do you think? thanks -- Kim Leyendecker (kdl(a)k-dl.de.vu) openSUSE Ambassador, openSUSE Wiki Team DE HAVE A LOT OF FUN! http://www.opensuse.org Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute or create your own Linux distro. Give SUSE Studio a try. http://www.susestudio.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

10 years

[opensuse-factory] Package categorization

by Ilya Chernykh

Hi! I first discussed this issue with coolo in private but possible a wider range of ideas may be beneficial. All of us know that is is sometimes confusing to find a package which belongs to your desktop environment, whether Gnome or KDE. Sometimes you have to look into package's dependencies to find out whether it is written in GTK or Qt. As the number of desktops increases, the problem only becomes worser. Currently the packages are classifies using the RPM groups. But for the most packages this groupping only reflects the package's purpose, i.e. network, game or office. This groupping is organized as a tree, and there is no possibility to add another categorization. An obvious solution is to add a desktop environment name to the package's name such as prefixing all KDE apps with "kde-" or simple "k". But this is also confusing and may require much of work as renaming is not an easy task. So are there any ideas on how to organize this better? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

10 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

openSUSE Factory June 2011