May 2011 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] KDE menus and gitorious
by Cristian Morales Vega 06 Nov '12

06 Nov '12

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

4 6

[opensuse-factory] Kernel for 11.4?
by Jeff Mahoney 22 Sep '11

22 Sep '11

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

15 33

[opensuse-factory] IPV6 privacy in openSUSE
by Andreas Jaeger 13 Sep '11

13 Sep '11

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

7 6

[opensuse-factory] Cronie as default cron in Factory
by Michal Seben 07 Jun '11

07 Jun '11

Hi all! Next week I will move cronie[1] package to Factory, so it will replace old cron. If someone is against this step, please just write what's wrong. As I announced earlier, you could find Cronie in Base:System repo [2] there is also prepared wiki about known changes after switch to cronie [3] [1]https://fedorahosted.org/cronie/ [2]https://build.opensuse.org/package/show?package=cronie&project=Base%3ASys… [3]http://en.opensuse.org/Cron_replace#Differences_between_old_openSUSE.27s_… -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

12 28

[opensuse-factory] Systemd by default
by Tim 07 Jun '11

07 Jun '11

Hi, to my knowledge systemd supposed to be the default init daemon in 12.1. Doesn't it make sense to activate it now (or as early as possible) to get at least some feedback from the people running factory? Tim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

21 57

[opensuse-factory] libqt-* package links in tumbleweed
by Jiri Slaby 05 Jun '11

05 Jun '11

Hi Greg, libqt4-doc-devel and libqt4-sql-plugins should point to libqt4 sources in Tumbleweed, not in KDE:Qt. Otherwise they can get out of sync (the fixed libqt4-doc-devel/sql-plugins links from TW to KDE:Qt still point to the latest liqt4 sources in KDE:Qt, not fixed ones). I've fixed it for now. However could you modify your scripts to not update these packages the same as for kernel-<non-source>? thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

4 7

[opensuse-factory] Can packages in the 11.4 standard or update repos build against tumbleweed?
by Dave Plater 03 Jun '11

03 Jun '11

Can packages in 11.4 standard or update repositories build against packages provided in the tumbleweed update repository.? I've filed bnc#696826 about 11.4's lv2core-devel's lv2config being unable to function due to a lack of package python-redland. The LV2 plugin system cannot be used at all if the package can't build against lv2core and slv2, I submitted new packages lv2core, slv2 and an updated redland package that included the python bindings before 11.4's release, lv2core is in the 11.4 distribution but slv2 is still in review, here is it's history : 62079 State:declined By:autobuild When:2011-02-18T16:30:51 submit: multimedia:libs/slv2 -> openSUSE:Factory note: obsoleted by submitreq 62078 From: plater(new) Descr: Removed conflict for libslv2-8 62078 State:review By:coolo When:2011-03-28T16:14:46 submit: multimedia:libs/slv2 -> openSUSE:Factory From: plater(new) -> saschpe(review) Descr: Removed conflict for libslv2-8 60049 State:declined By:autobuild When:2011-02-18T16:30:43 submit: multimedia:libs/slv2 -> openSUSE:Factory From: plater(new) Descr: Add slv2-0.6.6-licencefix.patch to remove file with conflicting GPLv2 statement in the header. See bnc#669117 and slv upstream drobillad #630 59638 State:declined By:autobuild When:2011-02-04T17:25:01 submit: multimedia:libs/slv2 -> openSUSE:Factory From: plater(new) Descr: New package slv2 is a library to make the use of LV2 plugins as simple as possible for applications.slv2 is free software (GPL v2 or later) written in C99 using the Redland RDF toolkit, and is known to work on GNU/Linux and Mac OS X. This package is the other part of the slv2 lv2core needed for openSUSE packages to use the LV2 plugin system and compliments submit request sr#59624 the home url for this package is http://drobilla.net/software/slv2/ apart from the url and licence all of the other relevant information is contained in submit request id 59624 and this is sr#62078 the last request which is still open : Request #62078: submit: multimedia:libs/slv2(r5) -> openSUSE:Factory/slv2 Message: Removed conflict for libslv2-8 State: review 2011-03-28T16:14:46 coolo Comment: run checker Review: new darix None None None Please decide accepted None factory-auto 2011-03-29T16:16:48 coolo Builds for all Factory repos found Output of check script (non-fatal): History: review 2011-03-18T10:39:07 saschpe new 2011-02-18T16:18:50 plater This last request effectively blocks slv from even going into factory. There was a comment made in a reply during one of my many emails pleading for slv2 to be accepted that it was a duplicate of a Packman package and I replied that it's purpose was to enable multimedia applications to build with support for LV2 plugins and openSUSE packages cannot build against Packman packages. I'm busy updating qtractor from 0.7.8 to 0.7.9 the earlier version would have been in 11.4 had slv2 been present and now it seems that version 0.7.9 is also going to be blocked. Reference threads : http://lists.opensuse.org/opensuse-factory/2011-02/msg00678.html http://lists.opensuse.org/opensuse-factory/2011-02/msg00004.html http://lists.opensuse.org/opensuse-factory/2011-01/msg00377.html I originally created the lv2core and slv2 packages when a user requested LV2 plugin support for ardour which isn't in the main distribution but he was happy with the result and this verifies that there isn't anything wrong with the package. Maybe I violated an openSUSE rule inadvertently but if nobody explains what it was I may do it again. I'm passionate about openSUSE multimedia and I feel that it presents an important face of openSUSE. Regards Dave Plater -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

2 4

[opensuse-factory] new openSUSE:* source processing method. PLEASE TEST !
by Adrian Schröter 02 Jun '11

02 Jun '11

Hello, I look for some more people who want to try our hopefully soon to be applied new source processing method for openSUSE:Factory and the maintenance updates to :Update projects. It should work good already, so you do not need to be brave ;) You may know that currently all package source submissions to Factory and friends get SUSE in-house be reviewed, re-validated and reformated. You can see this in the additional "autobuild" commits in the openSUSE:Factory commits. We plan to do following changes in future: * We would like to do these steps out there and as soon as possible in future. This means in best case before any packager is commiting his changes the validating and reformating is done already. This avoids any possible merge problems, unnecessary commits and extra turn around times. * these services can be code stream specific (unlike current osc_source_validator). That means we will be able to do better checks in future for Factory then for maintenance updates (where we need to stay compatible). And we do not need to take care about non-SUSE code streams, eg. Fedora or MeeGo people can still work and submit their changes to their projects or write their own services. * In addition to existing checks, we want to track where upstream sources (tar balls) are comming from. So far we had the download_url source service, which downloaded files and stored them with _service: prefix what not everybody liked. The new and project wide working "download_files" service is just validate the URL's from the spec file. The new osc will commit these files as usual files and the server is just validating this. (People with low upstream bandwidth can still decide to skip the commit, the server will store it with prefix again.) So, if everybody is using this current osc & source service stack, the source services will be used to do these steps, but there will be no _service* file(s) in your package sources. And the last really SUSE in-house part of Factory development would be the legal review db, really everything else would be out there in build.o.o... How to test this ? ================== First of all you need the new services and a new osc installed. Please add the proper openSUSE:Tools project repo and install zypper in obs-service-download_files obs-service-format_spec_file obs-service-source_validator In addition to that please install "osc" from openSUSE:Tools:Unstable project. If you do not like to add the repo, just run osc getbinaries openSUSE:Tools:Unstable osc $YOUR_REPO $YOUR_ARCH and install the osc package manually. To activate this for your entire devel project (it would work also per package) do # osc co $YOUR_DEVEL_PROJECT _project # cd $YOUR_DEVEL_PROJECT/_project # cat > _service <<EOF <services> <service name="format_spec_file" mode="trylocal"/> <service name="download_files" mode="trylocal"/> <service name="source_validator" mode="trylocal"/> </services> EOF # osc addremove # osc ci -m "activate factory default source services" Afterwards these services running on "osc build" and "osc commit" actions, if not disabled via CLI switch. Reformated spec files will be uploaded directly and in case of validation errors, osc will abort before commit/build'ing. What happens to people with old osc version (0.130 and before) or just using the webui after activating these services ? Nothing. The services will run on the server only. => The source state will turn into "broken" if a validation error exists. => if tar ball is missing/different or spec file is different formated they will be visible with _service:* prefix again. How to get rid of them again ? Just anyone with a current osc stack will merge these changes automatically on next commit and the server side generated files will disappear again. If this testing phase works out fine, we will of course make a maintenance update for all these packages, so everybody should have a current stack. I have activated this already for the openSUSE:Tools* projects and everything seems to work. And I found out that 3 out of 3 random packages from openSUSE:Factory contain broken Source: $URL lines ;) Feel free to branch any openSUSE:Tools package into your branch and try to edit it. With the new osc you will use these local services automatically. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

2 10

[opensuse-factory] Banshee update to 2.0.1
by Nelson Marques 01 Jun '11

01 Jun '11

I've submitted the updated version of Banshee (2.0.1) to Factory today and also banshee-community-extensions (which wasn't a part of Factory). If the community extensions package isn't attractive to factory, then feel free to decline it, though it would be somehow interesting to be available also on Factory. banshee-1 : SR 71891 banshee-community-extensions: SR 71890 NM -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

2 1

[opensuse-factory] Recursive login - 12.1 M1
by Steven Sroka 01 Jun '11

01 Jun '11

I just downloaded the Factory KDE LiveCD (which contains 12.1 M1), and I can't log in. I haven't even installed it yet, but when I press enter to login, the screen flashes and I get the login screen again. I also *did* do a seperate install from the NET iso and I get the same issue. I'll check for existing bug reports, but I don't think the coming M1 is testable :( Steve -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

6 11