September 2012 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] Tumbleweed is now empty for 12.2
by Greg KH 14 Sep '12

14 Sep '12

As part of the Tumbleweed lifecycle, with the 12.2 release of openSUSE, the openSUSE:Tumbleweed repo is now empty so that you can start out with a "clean" 12.2 release. It will stay that way for a few weeks for things to settle down with 12.2, and then will start to add packages back to it (new kernel, KDE 4.9, etc.) as time permits. So, if you wish to stay at 12.1 with Tumbleweed right now, I recommend NOT updating your system until you feel comfortable moving to 12.2. If anyone has any questions, please let me know. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 9

[opensuse-factory] Fwd: [Dissemination-simtkmembers] Request for letters of support for Simtk.org's continued development
by Juan Erbes 14 Sep '12

14 Sep '12

---------- Forwarded message ---------- From: Joy P. Ku <joyku(a)stanford.edu> Date: 2012/9/13 Subject: [Dissemination-simtkmembers] Request for letters of support for Simtk.org's continued development To: dissemination-simtkmembers(a)simtk.org Dear Simtk.org Member, We are writing a proposal to renew NIH support for the Simtk.org website, which supports OpenSim, OpenMM, MSMBuilder, SAFA, the whole cell computational model of Mycoplasma genitalium, and 600+ other biocomputational projects. It would be a great help to our proposal to have testimonial letters from you, stating how you are using or plan to use Simtk.org. We are sure that a diversity of letters from around the world will help our renewal effort. Attached is a template you may find useful for writing the letter. We would be very grateful if you could send a signed letter (preferably as an attached PDF file on your letterhead) to simbiosfeedback(a)stanford.edu by September 24th so that we can meet Stanford’s internal deadline for submitting the proposal. If you would like to provide a letter but cannot meet this deadline, please let me know. We can add a few letters after this deadline, if we know they are coming. Thanks so much for your ongoing participation and support. Sincerely, Scott Delp Simbios National Center for Physics-based Simulation of Biological Structure --- Joy P. Ku, PhD Director, Simbios Director of Communications & Training, NCSRR Stanford University (w) 650.736.8434, (f) 650.723.7461 Email: joyku(a)stanford.edu _______________________________________________ Dissemination-simtkmembers mailing list Dissemination-simtkmembers(a)simtk.org https://simtk.org/mailman/listinfo/dissemination-simtkmembers -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/

1 0

[opensuse-factory] Re: [opensuse-kde] our goals for 12.3
by Alin M Elena 13 Sep '12

13 Sep '12

On Thursday 13 Sep 2012 17:05:44 you wrote: > I think it may also be time to move on from our default font and use > something easier to read and render, like openSans font. It is a very > complete font family. Also enable "forced dpi" and add sub-pixel rendering > full rgb for it. > > Andy (anditosan) Good one... as I just played with open sans for the last weeks... It looks indeed good and nice. though I do not like its greek letters... but for sure a font we should ship. Alin > > On Sep 13, 2012, at 3:20 PM, Luiz Fernando Ranghetti <elchevive68(a)gmail.com> wrote: > > 2012/9/13 Alin M Elena <alinm.elena(a)gmail.com>: > >> add your favourites.. > >> > >> regards, > >> Alin > > > > Hi, > > > > Evaluate the use of oxygen-fonts on KDE > > > > Regards, > > > > Luiz -- Without Questions there are no Answers! ______________________________________________________________________ Alin Marin ELENA Advanced Molecular Simulation Research Laboratory School of Physics, University College Dublin ---- Ardionsamblú Móilíneach Saotharlann Taighde Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath ----------------------------------------------------------------------------------- http://alin.elenaworld.net ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] New packages: nip2, vips, matio
by Dmitry Roshchin 13 Sep '12

13 Sep '12

New packages for processing large images: 1. nip2 nip2 is a user interface for the VIPS image processing library. http://www.vips.ecs.soton.ac.uk/index.php?title=Nip2 https://build.opensuse.org/package/show?package=nip2&project=graphics 2. vips VIPS is a free image processing system. It is good with large images (images larger than the amount of RAM you have available), with many CPUs, for working with colour, for scientific analysis and for general research and development. http://www.vips.ecs.soton.ac.uk/index.php?title=VIPS https://build.opensuse.org/package/show?package=vips&project=graphics 3. matio (for access data from MATLAB MAT files) matio is an open-source library for reading and writing MATLAB MAT files. This library is designed for use by programs/libraries that do not have access or do not want to rely on MATLAB's shared library. http://sourceforge.net/projects/matio https://build.opensuse.org/package/files?package=matio&project=science -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] Remove sax2-tools from 12.3 default installation
by Saulo Moraes 13 Sep '12

13 Sep '12

Hi, I have installed OpenSuse 12.2 KDE CD and after the instalation complete I could find the sax2-tools package was installed in my system. I think sax2 is not used as default configuration tool since 11.2. And as I could see sax2-tool also require icewm-lite with is a old (not sure if maintened windows manager). So my question is if SAX2 can/will be removed from 12.3 default instalation? I dont have anything against sax2 as I have used a few years ago.. see this as a cleanup as package can still be available to be installed. Oh and using suseStudio the sax2-tools and icewm is also automatically added on all default 12.2 templates too. thx, sauLo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] Packaging Guideline enforcement
by Dominique Leuenberger a.k.a DimStar 13 Sep '12

13 Sep '12

Dear Factory contributors and packagers, As openSUSE 12.2 is frozen and Factory is 'open to go wild' again, I would like to announce that the packaging guidelines have some extensions (not really new) that will be stricter enforced than they used to be. Currently a common rule to be 'ignored' or packagers are not aware is around the topics of: - .Changes entries - Patches First, the .changes entry (rpm changelog) surves two purposes: - News for the user - History tracking of packaging changes (often referenced in bugs to verify if a user has the latest packaging bugfixeS). A simple "Update to version x.y.z" is, as before, not accepted. There should be some buzz around the update for the user; some major reasons to the upgrade should be listed Changes on the package itself should be mentioned in a way that any other contributor to the same package can follow traces of why something is the way it is. Commonly, Added (build)dependencies are interesting to be seen, special hacks to make something work in a particular way [..]: Always consider that package maintenance is a distributed task and various contributors need to be able to step up at will. Patches: The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines . Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed) The main appeal is to the devel project maintainers / reviewers, to keep out for those rules, to live according to them, as it is frustrating for everybody if a package needs to be declined by the Factory Review team: - The dev prj maintainer is the one getting the 'decline' (as it was usually a forwarded request), which often leaves the 'fixing' to the devel project maintainers, where the 'originator' of the fix would have been willing to actually do that... And the Factory Review team also prefers to see complying submissions to having to reject SRs... reject is not fun for anybody! Looking forward to many more SRs to accept! Dominique / DimStar -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

19 44

[opensuse-factory] plan for 12.3 - multiple Python runtimes
by Jan Matejek 13 Sep '12

13 Sep '12

fellow openSUSErs, with the advent of Python 3 and still almost unnoticeable decline of Python 2, i have come to a realization that the way we separate them into "python" and "python3" is less than ideal. The granularity of this can be often too coarse (you can't run two apps requiring two different python2 versions, unless they are specifically packaged and bring their own python runtime package), and too fine at the same time (there are already packages that don't actually care whether they run in python 2 or 3) In the spirit of fixing what ain't broken, I humbly propose a grand plan: let's turn "python" into "python2.7", "python3" into "python3.3", and tinker with Provides until it all works just fine. Then, as a last step, symlink /usr/bin/python into /etc/alternatives and let the users pick whichever runtime they like better. This would probably go better if broken into several phases. My current idea is this: Phase 1: - rename "python" to "python2.7", providing "python = 2.7" - rename "python3" to "python3.3", providing "python3 = 3.3" - install the update-alternatives symlink Impact: - Unsure of what would happen on package upgrade. Would we need Obsoletes/Provides combo for this? Perhaps we'd have to create the metapackages outlined in the following phases at this point already. Phase 2: - unify RPM macros - python3 will have %py_(something) macros as well as %py3_(something) macros, the %py3_ versions being aliases to the %py_ versions - make python2.7 provide "python2 = 2.7" instead of "python = 2.7" - make a "python" meta-package requiring, at this time, python2 - each pythonX.Y package now only installs /usr/bin/pythonX.Y binary, python2 and python3 are alternatives for python2.Y and python3.Y respectively, and python is an alternative for either python2, python3, or a specific version. I don't know update-alternatives too well - is this even viable? Impact: - this should mark a clear upgrade path for each of the python variants and for the systemwide "default python" as well - at this phase, i would like to make it possible to build a package for any python (2 or 3 or 50) from the same specfile. i'm not sure that these outlined steps are enough, though. Originally I thought that every python would provide "python = X.Y" and the packages could select which "Requires: python" to pick through package or project meta. But that would result in a horrible breakage, and we need "python" as a separate package for upgrading in any case. We could use "python(abi)" symbol for this, or do the same just with "python-devel"? Any other options? Phase 3A: - when python 3.4 comes out, introduce a new package "python3.4", new meta-package "python3" requiring "python3.4", and corresponding alternatives Impact: - This is the other difficult one. What about lifetime of the pythonX.Y packages? What happens with old systems on perpetual-upgrade? Such as tumbleweed - will the old python runtimes rot there forever-and-ever, or can we force uninstall at some point? Perhaps "Obsoletes: python3 < 3.x" in the "python3" metapackage? Which versions do we support? The newest and the most popular, probably? I know we do something similar with gcc, how does it work there? Phase 3B: - steal and improve Debian's python-central (or however they call it these days) - designate /usr/lib/python-central or something similar for packages that don't want to depend on a specific python runtime version - introduce %post/%postun scriptlet macros for packages that would compile bytecode in /usr/lib/python-central for all known python runtimes on the system, and for pythons so that they compile every package for their versions. This is now actually fully supported by upstream, we can have as many different versions of bytecode for the -same- .py file as we want. Impact: - package can specify "Requires: python" and Just Work(tm) from now until eternity, or until it runs into a deprecated API. Or specify a range of pythons it wants to support - by the time we get here, I'm sure RPM will allow that ;e) With a limited ABI in python3, this can even work for arch-based packages across python minor versions. Phase 4: - when we decide to switch to python3 system-wide, make "python" require "python3" instead of "python2", change default alternative, and be done with it Impact: - breakage of packages still incompatible at that time. that will help us see what needs fixing and what needs to explicitly specify that it wants python2. Somewhere in this is lurking a possibility of supporting different python runtimes such as Jython, Cython, PyPy and whatever else crops up. That's neat, too. Thanks for your attention. Comments, questions? regards m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

10 19

[opensuse-factory] rpm .repo release files
by Damian Ivanov 13 Sep '12

13 Sep '12

Hi ppl, In openSUSE for adding a repo we do a zypper ar $repo, the repo files are not owned by any rpm package AFAIK. Fedora has $REPO_NAME-release rpm in each repository installing the gpg key and the .repo file. Is there any purpose openSUSE not doing so or has this other reasons? Best regards, Damian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 4

[opensuse-factory] 12.3 GOAL: GStreamer 1.0 instead of 0.10
by Dimstar / Dominique Leuenberger 13 Sep '12

13 Sep '12

Hi all, I have another suggestion as a goal to work on for openSUSE 12.3, driven by the GNOME Stack: * Switch to GStreamer 1.0 * Rationale: GNOME 3.6 (to be released end of Sept 2012) has mostly (few exceptions) been ported to GStreamer 1.0 (latest releases of GStreamer are 0.11.93). GStreamer 0.10 and GStreamer CAN be parallel installed; but it's expected that once 1.0 is out, the 0.10 tree will only get very limited care by upstream. So not having to maintain it is surely recommended. There are a few critical components, that we have to take into account though, but having it as a goal is, in my opinion, still worthy. * 3rd party codecs (fluendo) Having contacted Fluendo, I was re-assured that work on the codec packs is in full progress and communication between Fluendo and GStreamer hackers is well established. The 'mp3 codec' for example is available in git trees hosted by fluendo (and could thus be packaged for our favorite 3rd party codec repo) * Applications depending on GStreamer: We will have to compile a list of applications that require GStreamer. I did several (easy) ports myself, and it *can* vary from simply changing configure, through simple API replaces (there is a rather exhaustive 'Port to GStreamer 0.11 How-To', through to 'half rewrites'. Once a of apps is compiled, work can start. * Automatic codec installer PackageKit integrates with GST to automatically install codecs. This works sometimes more, sometimes less reliable. Would be a good moment to work with PackageKit upstream to sort those issues out as well. == RELEASE GOAL == The goal should be to have only GStreamer 1.0 in the repositories. == Test Plan == * Switch apps that do support it to GStreamer 1.0 * Verify functionality of the switched applications + If needed, work with upstream on a port to GStreamer 1.0 * This is NOT ONLY limited to GNOME Stack! Whereas the GNOME Stack is surely the most dominant driver here, there are multiple other apps depending on it as well. == Backout plan == Ship GStreamer 1.0 and 0.10, and have them parallel installable; GST 1.0 is the recommended version of GStreamer for GNOME 3.6 and will likely be required for GNOME 3.8 (due March 2013) == 3rd Party Repos == As there is also a multitude of additional repositories with GStreamer based software, it might simply not be feasible in the short term to drop GStreamer 0.10 entirely. If we think catering for this usecase is a must for the distribution, then the goal for us should at least be to have GStreamer 0.10 not to be installed in a standard install; having additional packages pull it in could be an option, Any thoughts on this? Shall we add it as a goal to our 12.3 GOAL site? Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

6 5

[opensuse-factory] Serious problem with Tumbleweed upgrade to 12.2
by superandrzej＠epf.pl 12 Sep '12

12 Sep '12

Hi, There is something seriously wrong with upgrade of Tumbleweed to 12.2 My Tumbleweed based on 12.1 was up to date day before 12.2 was announced. Yesterday I run actualization and now I'm not able to run X sever. First I thought that there was some bug in new version of X server related to my video card, but today my cousin with completely different hardware informed me about the same problem. I also googled out similar problems in opensuse forums e.g.: http://forums.opensuse.org/english/get-technical-help-here/tumbleweed/47793… http://forums.opensuse.org/english/get-technical-help-here/tumbleweed/47782… http://forums.opensuse.org/english/get-technical-help-here/tumbleweed/47794… Do you know about this problem and maybe identified the sources of it? Is there any way to recover to usable system other than installation of 12.2 from ground up? I will provide any additional information needed to solve this bug. I would appreciate any hint. thank you in advance Andrzej -- Poczta wyslana z portalu Panorama Internetu sp. z.o.o -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 3