November 2014 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Python 2 and 3 in single specfile
by Jan Matějek 22 Jul '15

22 Jul '15

Fellow packagers, after some discussions in our team, we figured that it would be neat if we could build python modules for Python 2 and 3 from a single spec file. Now that a great deal of python modules work with both pythons, this makes a lot of sense. A good deal of work can be done by RPM macros. Then we could even seamlessly start building modules for PyPy, Jython and other pythons. A sample specfile, and the corresponding set of RPM macros, is attached. As you can see, the appropriate subpackage is generated automatically by %python_subpackages, build and install steps are handled through %python_build and %python_install respectively. There is some more magic involved, as well as possibilities for customization. There is a minor problem with BuildRequires. As long as you only need python-devel, it's not too bad to just list $flavor-devel requirements by hand. It's worse when you require more subpackages, because then you need all of them in both python2 and python3 versions. It would be nice to be able to specify %{python_require Mako} and expand that to all the necessary BuildRequires, but OBS blocks us here, because the limited environment will not expand such macros. mls, ro, or anyone from the OBS team, would it be possible to solve this? Still, it basically doesn't matter if you list all the BuildRequires twice in one spec or in two specs, so there. Another thing I'm still unclear on are the filelists. It's certainly possible to make a generic filelist, something along the lines of: %package -n %flavor-%modname # python3-Mako %defattr(-, root, root) %{%flavor_sitelib}/* %{%flavor_sitearch}/* but this doesn't solve docs and possible other files. Again, obviously, we can write the filelists by hand. But if you have good suggestions for some smart macros here, I'd love to see them. What do you folks think? Comments, questions? m.

3 5

[opensuse-packaging] Can Cacti package be updated to 0.8.8c from 0.8.8b
by doiggl＠velocitynet.com.au 14 Dec '14

14 Dec '14

Hello Can Cacti package be updated to 0.8.8c from 0.8.8b http://forums.cacti.net/viewtopic.php?f=8&t=53725 https://build.opensuse.org/package/show/server:monitoring/cacti Thanks Glenn -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 5

[opensuse-packaging] systemd service presets: branding files or packages?
by Stanislav Brabec 04 Dec '14

04 Dec '14

I would like to open a discussion about use of systemd presets while packaging. Systemd preset files are preferred way how packages set the default state of services. Preset files are located in /usr/lib/systemd/system-preset directory. %service_add_post is aware of presets, and if the package adds systemd service together with presets, %service_add_post performs one-time set to the preset default state. Current policy is simple: All presets belongs to: systemd-presets-branding-{product} /usr/lib/systemd/system-preset/90-default-openSUSE.preset and the default to disable all other: /usr/lib/systemd/system-preset/99-default-disable.preset It makes a lot of sense for packages with optional services, that should be always on, like apache, network servers etc. But I think that makes less sense for packages that are optional to install, but it they are installed and not active, they are broken. Especially if they are socket activated, the standby state means no more than one socket opened by systemd. I have two examples from last weeks: uuidd: Optional socket activated util-linux daemon providing support for UUIDs. pcsc-lite pcscd: Smart Card daemon that is socket activated whenever application attempts to use Smart Card PC/SC API. If it is not enabled, Smart Card access does not work. Note that it has a security implication: Each package that installs default-on preset, should be audited by security team. Security team would need to watch the whole directory, not only a branding file. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

12 46

[opensuse-packaging] need help writing specfile for OBS
by Steffen Sledz 27 Nov '14

27 Nov '14

I hope i'm on the right ML with my problem. Please forgive me if not. I need to write a specfile for use with openSUSE Build Service and have problems with the source fetching and versioning part. The sources for the project are hosted at GitHub and i like to build a snapshot from the HEAD of the master branch. So the package version should contain a (generated) numerical part which increments on each build and the (short) hash of the latest commit. I believe that the tar_scm, set_version and recompress services are needed here. But i could not find a good tutorial or example for this. Thanx for help, Steffen -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 4

[opensuse-packaging] A few failures of ruby packages in Tumbleweed
by Dimstar / Dominique Leuenberger 25 Nov '14

25 Nov '14

Dear Ruby specialists, For a while already, a few ruby packages in Factory/Tumbleweed are not able to build (generally due to some packages changing to 'new' packaging style, but not others). The current list of packages is: * rubygem-locale_rails * rubygem-owncloud-admin * rubygem-xmlhash All of them being unresolvable. not directly a ruby build failure, but still related: puppet fails to resolve with: have choice for rubygem(ruby:2.1.0:json_pure) >= 0 needed by rubygem-hiera: ruby2.1-rubygem-json_pure-1_5 ruby2.1-rubygem-json_pure It would be greatly appreciated to have those corrected soon. Best regards -- Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org> -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Issues with plasma5-openSUSE packages
by Stanislav Baiduzhyi 23 Nov '14

23 Nov '14

Hi All, I want to make a modified version of plasma5-openSUSE package for 13.2, but even the original unmodified package fails to build: https://build.opensuse.org/package/live_build_log/home:TheIndifferent:brand… Could anyone please explain me what is this about, what am I doing wrong and how the same package is built in KDE:Frameworks5 repository without issues? -- Regards, Stas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

[opensuse-packaging] Why is "recommends" required to install minimalist chromium?
by Felix Miata 21 Nov '14

21 Nov '14

13.1 zypp.conf: solver.onlyRequires = true zypper.conf: installRecommends = no # zypper -v in chromium 2 packages will be installed package chromium will be installed "recommended" package chromium-ffmpeg will be installed (cancel) # zypper al chromium-ffmpeg # zypper -v in chromium nothing provides chromium-dev needed by chromium-dev-ffmpeg (cancel) Why when "recommended" package installation is refused does chromium require a -dev package or risk breaking yet another (unwanted) package? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

[opensuse-packaging] new bot reviewing maintenance submission
by Ludwig Nussel 19 Nov '14

19 Nov '14

Hi, Released distributions like openSUSE 13.2 do not have devel projects. Therefore the process used for Factory where any submission has to pass by the actual package maintainers does not work. This has caused some surprises in the past. Now we have a new review bot meant to avoid non-maintainer submissions. The bot is now automatically added as reviewer for maintenance requests. It checks whether the package was submitted by someone who is maintainer of the Factory package. If the request was created by someone else the bot adds the devel project/package as reviewer. The Factory maintainer¹ then has the chance to accept or decline the update. Right now OBS has a bug that prevents it from sending mail notifications for those new reviews. I hope it will be fixed soon. The submit request are correctly listed on package maintainer's tasks lists on build.opensue.org though. cu Ludwig [1] only works for packages that are still in Factory of course. The bot doesn't know what to do with packages that were dropped (or renamed) from Factory so just let's them pass like before. -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] How do I build the -32bit variant of a package using osc build?
by Robert Munteanu 19 Nov '14

19 Nov '14

Hi, I'm trying to rebuild wine with a patch applied on top. I've updated the spec file and rebuilt the rpm, both for x86_64 and i586, but I did not get an -32bit RPM. In the OBS repositories page [1] I see that the -32bit RPM is located in the i586 repo, but I'm not sure how it's built. I know I can branch the project and built it with the patch I need on OBS, but it is slow and wasteful to do that just to build a patch. Thanks, Robert [1]: https://build.opensuse.org/package/binaries/Emulators/wine?repository=openS… -- http://robert.muntea.nu/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

[opensuse-packaging] Are bashisms in RPM scriptlets allowed?
by Johannes Meixner 17 Nov '14

17 Nov '14

Hello, are bashisms in RPM scriptlets allowed? Up to now I ignorantly assumed that bash is used for RPM scriptlets so that bashisms in RPM scriptlets "just work". But I got https://build.opensuse.org/request/show/260498 By Googling for "bash rpm scriptlet site:opensuse.org" I did not find an authoritative answer. In particular neither https://en.opensuse.org/openSUSE:Packaging_scriptlet_snippets nor https://en.opensuse.org/openSUSE:Specfile_guidelines helps. I found http://lists.opensuse.org/opensuse-packaging/2010-03/msg00076.html where comments therein seem to indicate that bash is o.k. for shell scripts but to be on the safe side one should explicitly require it via "#!/bin/bash" shebang but as far as I know I cannot have a bash shebang in RPM scriptlets. FYI: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Default_Shell reads: "In Fedora, you can assume that the default shell (/bin/sh) is bash. Thus, all scriptlets can safely assume that if they are running in shell code, they are running within bash." Kind Regards Johannes Meixner -- SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 4

[opensuse-packaging] Usage of gpg_verify in .spec files
by Dimstar / Dominique Leuenberger 17 Nov '14

17 Nov '14

Hi geeko packagers, Please note that we are receiving a new version of gpg (2.1.0) in Factory probably rather soon... One thing to note is that the current version of %gpg_verify passes --gpg2 to the command, which is no longer understood. There are obviously two ways to fix it: - Fix %gpg_verify to no longer pass --gpg; surely simple, but I don't prefer the solution - Remove the gpg_verify commands from the .spec files; In fact, usage of gpg_verify has been deprecated in favor of the obs service source_validator (which runs at each osc ci call or you can call it using osc service lr source_validator). As we already have implicit verification of the signatures there, it is of no use to verify the signature during build again. Which is also the reason why option one is not that appealing. Can I please ask the package maintainers to work with us and eliminate this wherever it is still used in Factory? Thanks a lot! -- Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org> -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 7

[opensuse-packaging] [Nodejs] Can we give some more love and care?
by marguerite 13 Nov '14

13 Nov '14

Hi, This is a complaint. The mess in this repo still happens. Just saw a bug report filed about npm for Tumbleweed, and fixed another bunch of packages again. Although most of the mess come from the fragment of nodejs package system, the massive & strict (introduced by nodejs-packaging) dependencies, and the migration from macros.nodejs to nodejs-packagin, there're still things we can take care of: 0. factory auto SRs. If it's accepted, that's okay. But if it's rejected, please at least take some time to see what's wrong and fix it. 1. care. I saw two of the commits that said "use nodejs-packaging to package" but no BuildRequires: nodejs-packaging at all. That shouldn't happen. 2. changelog. I saw patches were not mentioned in many of the rejected auto SRs. And what's most important: please do not alter the packages directly. because: 0. other maintainers will not receive any notification for that. so no one else will be awared of what's going on, review, and cover for us. 1. it'll not forward to Factory. that's why auto SRs were triggered. Most of the times, auto SRs may be likely to be ignored. I know there are so many packages in this repo, which makes such suggestion ridiculous, but think about devel:languages:python (it has many more packages I think). Again we can develop a script to do the SRs from branched projects to the devel repo itself. And a few more things: 0. wiki should be updated. because the new nodejs-packaging tool 1. Is there any function in nodejs-packaging that can alter the auto detected/parsed dependencies? I remember I saw such things in Fedora. now we use patches, which is hard to track and mostly do a simple same thing. 2. Is nodejs so strict about package versions? because I saw many SRs trying to submit old versions of packages, and we did lots of rollback things. How did we verify if a package really can't use a newer version? and what to do/how to do when it needs to have two versions of the same packages in our repo (I saw two situations: one just renames the module to, like, nan-0_8; another uses update-alternatives)? we may need to discuss and develop a policy for that. Marguerite

2 1

[opensuse-packaging] Faling build for Tumbleweed build target
by Todd Rme 12 Nov '14

12 Nov '14

It looks like at least some repositories are having issues with the Tumbleweed build target. Packages that work fine for the openSUSE_Factory snapshot build target are failing to build for openSUSE_Tumbleweed. The failure in all cases is "error: Failed build dependencies:" In all cases, this failure always happens for BuildRequires that are enabled only for openSUSE versions > 13.1. The dependencies in all cases are available and build properly. The really strange thing is that when I branch the package, it builds just fine. It also builds fine when I try to build locally. And forcing a rebuild does not work. So this has made debugging the problem hard, since I don't want to potentially break other working build targets. Does anyone know what might be going on and how it can be fixed? Here is an example: https://build.opensuse.org/package/show/devel:languages:python/python-matpl… The failure: [ 318s] + exec rpmbuild -ba --define '_srcdefattr (-,root,root)' --nosignature --define '_build_create_debug 1' --define 'disturl obs://build.opensuse.org/devel:languages:python/openSUSE_Tumbleweed/cb5af0d…' /home/abuild/rpmbuild/SOURCES/python-matplotlib.spec [ 320s] error: Failed build dependencies: [ 320s] python-qt5 is needed by python-matplotlib-1.4.2-89.2.i586 [ 320s] python-qt5-devel is needed by python-matplotlib-1.4.2-89.2.i586 The relevant portion of the spec file is line 76-79: %if 0%{?suse_version} > 1310 BuildRequires: python-qt5 BuildRequires: python-qt5-devel %endif -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

Re: [opensuse-packaging] systemd service presets: branding files or packages?
by Stanislav Brabec 11 Nov '14

11 Nov '14

Andrei Borzenkov wrote: > В Tue, 11 Nov 2014 17:33:02 +0100 > Stanislav Brabec <sbrabec(a)suse.cz> пишет: > Just like using preset if it is called on update. It will not overwrite > current state if it is called only on initial install. The only > difference between preset and enable is where decision comes from. Imagine preset like a way to implement "Reset to default" button. Without preset, there can not be "Reset to default". > But somehow I'm not sure I follow the logic. If installed package is > not functional without active service, service should be statically > enabled. If it is intended to leave decision to enable service to > admin, package should be useable without active service. The question her is not "Activate this service?" but "Activate this service by package preset or branding preset?" Or even better: Where should be the border line between "package is not functional without active service" (and preset should be probably part of the package) and "package activation should be brand-able" (and preset should be probably part of the branding). > > Package should use presets. Then %service_add_post is sufficient. It > > does one time set to preset, and on the next update, service will stay > > in the previous state, > > Not because it is preset, but simply because preset is called only on > initial install. Correct. The current implementation %service_add_post does it in smart way only for presets.* If somebody adds "systemctl enable" to %post, then one-shot activation needs to be handled by package maintainer. (*) Well, the smart way works only if the preset is introduced together with the service. Hopefully, there is an easy trick to introduce one-time preset call even if preset is introduced later: if [ $1 -gt 1 ] ; then if ! {test if preset exists in file or branding file} ; then echo -n "" >/run/rpm-%{name}-update-{service name}-new-in-upgrade fi fi > If security team has to approve each preset for each package, what > advantage shipping them as part of each package has? Policy change for particular package does not involve change of all existing branding files. (openSUSE distributes just one branding file, but authors of derived products can create their own branding files.) -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Fwd: Branching a specific revision of package
by Greg Freemyer 11 Nov '14

11 Nov '14

All, Given merge conflicts in an older package revision, how can I branch the older revision of the package regardless? == details For one of my tools I need to have python-psutil v1.2.1 available in my repo. That is in rev 26 of d:l:p python-psutil, so I tried: > osc bco -r 26 devel:languages:python python-psutil But I'm getting an error: "Server returned an error: HTTP Error 400: Bad Request conflict in file python-psutil.spec" Adding -f (force) doesn't help. -- For now I just used "osc mkpac" to create a new package and populated it with the old files, but branching the old revision I assume is preferred. Thanks Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] SUSE:SLE-12:GA project is there
by Adrian Schröter 07 Nov '14

07 Nov '14

Good news everyone .... more work for OBS and all of us :) SLE 12 got imported. Right now only the x86_64 architecture is usable. ppc64le will come when we have the hardware in place. SLE 12 got added to the simple default target list in webui or when you want to add it manually use SUSE:SLE-12:GA / standard repository. Please note that the former existing SUSE:SLE-12 project got removed. -- Adrian Schroeter email: adrian(a)suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

10 15

[opensuse-packaging] Re: Cinnamon Stable repo for openSUSE X11:Cinnamon?
by marguerite 06 Nov '14

06 Nov '14

Hi, Cinnamon 2.4.0 is now landing in X11:Cinnamon:Factory. * MDM not updated yet (need a new splash instead of the old ugly one) * Artwork not updated yet. * Some package like patterns-openSUSE-Cinnamon not created yet. (so you have to install package by package if you want to be the early bird. maybe tomorrow) When all done, packages will be copied and the new Current repo will launch. The launch note will not be published in opensuse-"packaging", but in openSUSE-"factory" ML. Not working: cinnamon-bluetooth. because it's written to be used with gnome-bluetooth 3.8. We have 3.10 for a long time. And I have no plan to fix it by providing an outdated gnome-bluetooth 3.8 as Linux Mint does. NOTICE: Currently the whole thing is not tested, at all. Because I'm updating my Factory box so zypper can't do the two things together. PS: X11:Cinnamon:Current will be the "Stable" branch you asked for. It'll track upstream "stable" releases at https://github.com/linuxmint according to the version number scheme you mentioned in previous posts. X11:Cinnamon:Factory then goes it's own way...eg: another 2.5.0 may be landing there because I myself have neither battery nor bluetooth devices :-) That is, there'll be no such thing like X11:Cinnamon:Stable which would track like: what Linux Mint uses. Because I have made my point of view clear on our wiki: Cinnamon is _NOT_ a desktop environment. It's a community project by Linux Mint. The best experience you can get will always from Linux Mint itself, if you don't care deb system or outdated fundamental softwares. Clearly I'm an openSUSE user, so I'll try to provide the best I can produce using openSUSE instead of simulating another distribution. That is, such way, eg, the way Arch Linux used to provide like Unity by creating every packages Ubuntu uses, is out of my way. We're not faking Linux Mint, but making an openSUSE spin. (Of course, bugfix from those versions Linux Mint use, should be added if someone open bugreports for any specific bug) X11:Cinnamon:* are development repositories, why manually add "freeze" for it? Marguerite

1 0

[opensuse-packaging] Missing packages for SLE_12 target
by Dmitry Roshchin 06 Nov '14

06 Nov '14

Some packages from SUSE:SLE-12:GA are missing for SLE_12 target. For example glew, wxWidgets-3_0 (nothing provides <package name>). Target: <repository name="SLE_12"> <path project="SUSE:SLE-12:GA" repository="standard"/> <arch>x86_64</arch> </repository> What is wrong? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 11

[opensuse-packaging] What provides this-is-only-for-build-envs?
by Andrei Borzenkov 05 Nov '14

05 Nov '14

bor@opensuse:~/obs/home:arvidjaar:bnc:902612:13.1/systemd> osc results -v standard i586 unresolvable: nothing provides this-is-only-for-build-envs needed by libudev-mini1 nothing provides this-is-only-for-build-envs needed by udev-mini standard x86_64 unresolvable: nothing provides this-is-only-for-build-envs needed by libudev-mini1 nothing provides this-is-only-for-build-envs needed by udev-mini ports aarch64 blocked: systemd-mini, libudev-mini1, udev-mini ports armv7l blocked: systemd-mini, libudev-mini1, udev-mini ports ppc succeeded(unpublished) ports ppc64 succeeded(unpublished) ??? It was successful on ppc, so it is not really package issue ... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] Recommends tag
by Jean Delvare 05 Nov '14

05 Nov '14

Hi all, I have a package which builds fine for all SUSE targets in OBS, but fails for Redhat-like distributions with the following error: error: line 68: Unknown tag: Recommends: procmail I seem to understand that Redhat's rpm does not support the "Recommends" tag, is that right? I would like to know what is the proper way to deal with this. I could not find anything related to this topic in the packager's guidelines. The first thing I would try is: %if 0%{?suse_version} > 0 Recommends: procmail %endif Is that the right approach? Or is there a different tag I should use for non-SUSE targets? Either way, I am surprised that OBS does not handle this all by itself, as this seems to be a fairly generic problem. Thanks, -- Jean Delvare SUSE L3 Support -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

10 34

[opensuse-packaging] Re: Cinnamon Stable repo for openSUSE X11:Cinnamon?
by marguerite 04 Nov '14

04 Nov '14

Hi, As 13.2 is released and I didn't have any plan yet, my second round of Cinnamon Adventure will begin in a few days.. This time I think I can update stable 2.4 packages and copy them to X11:Cinnamon:Current...to avoid the "rapid" development cycle in X11:Cinnamon:Factory... Marguerite

1 0

[opensuse-packaging] Re: AW: AW: Cinnamon Stable repo for openSUSE X11:Cinnamon?
by S. 03 Nov '14

03 Nov '14

Hello Marguerite and Stefan, I hope this message finds both of you in good health and good spirits. Upon further investigation of how the Mint project releases Cinnamon, I discovered that they do indeed have official release tags that could be considered as "stable releases". For example, here is the main Cinnamon project: https://github.com/linuxmint/Cinnamon/releases As can be seen above, the major previous stable version was 2.2.x, and they just today announced the 2.4.x series as a "release" (http://segfault.linuxmint.com/2014/11/cinnamon-2-4/) Please note that the 2.3.x series was never declared as stable, since major.minor numbers that are odd (2.3) are considered unstable and are not released for public consumption. Other components of Cinnamon have different version numbers, but their stable releases are also clearly tagged. For example: https://github.com/linuxmint/nemo/releases https://github.com/linuxmint/cinnamon-screensaver/releases https://github.com/linuxmint/cinnamon-settings-daemon/releases https://github.com/linuxmint/cinnamon-control-center/releases I think that Marguerite's limited development time would be best focused on packaging for openSUSE the versions that Linux Mint officially tags as a "release", instead of packaging development GIT snapshots that even the Linux Mint developers recognize to be unstable and full of bugs. The official Linux Mint "releases" may still require just a few patches to be compatible with openSUSE. Fortunately, Linux Mint officially offers some patches for newer distros, and other patches are maintained by Arch. Since I am a heavy user of Cinnamon, and since I have some experience with Arch, I would be glad to give Marguerite some links to any necessary patches (there will probably be about 4 patches required in total) to make the cutting-edge Cinnamon packages in X11:Cinnamon as stable and compatible as possible. Please let me know if I can help. Thanks again to Marguerite and Stefan for your time and effort at packaging Cinnamon for openSUSE, it is by *FAR* the best Linux desktop for me and several other users that I support. I wouldn't be able to use the fantastic openSUSE distro if this project didn't exist. All the best, Sam On 10/20/2014 02:30 AM, Stefan Elser wrote: > Hello everbody, > > I had take some time and searched at the Fedora, Debian and Linux Mint > repositories how they build their cinnamon versions. > > Marguerite is totally right that there is no real "stable" version or a > release tagged "stable" from the Cinnamon developers itself, however it > seems that Debian and Fedora are useing the .tar.gz sources of the > latest stable version from Linux Mint repositories (which is actually > 2.2.16 in 17 / Qiana). > > Also I've done some selftesting and switched from GNOME Shell to > Cinnamon for fulltime this weekend. I have to admit, that there are > really some annoying bugs in the latest git build. For instance, the > battery icon does not refresh and the clock widget for the taskbar is > defunct. > > Marguerite said, that we haven't have that manpower to work on two > versions and I have to agree in this point (even if there were a lot of > submits with the latest updates) but we really should think about to > either switch to the "stable" version or at > least trying to provide this "stable" version in another repository. > Cinnamon isn't really useable in this state (IMHO). > > The dependencies is another upcoming thing which gives me a little > headache. As far is I know, the GTK3 version is heavily patches and > Linux Mint, however version 2.2.16 is running fine with latest Fedora > and Debian unstable releases without any "special" patches for GTK. > > I can just offer that I will make a "home project test build" with > 2.2.16 and we can see how this is working out for us. Later we can think > about how to move on. But again, I don't want to do something Marguerite > isn't comfortable with. > > Best regards > Stefan > > > > > > -----Ursprüngliche Nachricht----- >> Von:S. <sb56637(a)gmail.com <mailto:sb56637@gmail.com>> >> Gesendet: Don 16 Oktober 2014 17:00 >> An: marguerite <i(a)marguerite.su <mailto:i@marguerite.su>>; Stefan Elser <stefan(a)fam-elser.de <mailto:stefan@fam-elser.de>>; opensuse-packaging <opensuse-packaging(a)opensuse.org <mailto:opensuse-packaging@opensuse.org>> >> Betreff: Re: AW: Cinnamon Stable repo for openSUSE X11:Cinnamon? >> >> Hello Marguerite and Stefan, >> >> Thanks to both of you for your time and replies. >> >> I think that if you can only focus on a single branch, it would be best >> to focus on the one that Linux Mint releases to their stable >> distribution. At the moment, the Cinnamon version that Linux Mint is >> offering to the public is version 2.2.16: >>https://github.com/linuxmint/Cinnamon/tree/2.2-maintenance >> >> Would it be possible to use Arch Linux's Cinnamon sources? >>https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h… >> I currently use Cinnamon 2.2 on Arch, and it is extremely stable and >> relatively bug-free. >> >> I think that the best use of your limited time and development resources >> would be best focused on the branch that Linux Mint offers to the >> public. Because the currently major bugs in Cinnamon 2.3 that are >> present in OBS X11:Cinnamon:Factory are because the Linux Mint >> development team is still developing it, and it is very much a beta >> product. It is practically unusable at this point. In fact, I'm sure >> that the same 2.3 branch of Cinnamon doesn't work correctly on Linux >> Mint either, because it's not released to the public. On the other hand, >> if the openSUSE Cinnamon team could track the currently stable branch of >> Cinnamon, you would only have to focus on bugs that are related to >> openSUSE integration, and not on bugs that Linux Mint is working to fix >> in their development process. >> >> Again, I really appreciate your efforts to offer a stable Cinnamon >> environment for openSUSE. I tried to use Mate and XFCE, but they have >> major problems with GTK3 windows that use client-side decorations. Apart >> from Gnome Shell, only Cinnamon properly handles GTK3 windows with >> client-side decorations. So for the**huge** number of users that don't >> want to use Gnome Shell or KDE, the only real alternative is Cinnamon. >> >> Thanks for your time! >> Best regards, >> Sam >> > -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Where's xulrunner?
by marguerite 02 Nov '14

02 Nov '14

Hi, listmates, I found that there's no more xulrunner-devel package inside openSUSE:Factory. but it's still releasing: http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/latest/source/ So what happened to it? (I need it to build gpac package in Packman, which is a dependency for x264) Greetings Margueirte

4 11

[opensuse-packaging] Please enable 13.2 target for devel:languages:ruby and devel:languages:ruby:extensions <EOM>
by Robert Munteanu 01 Nov '14

01 Nov '14

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] glibc-locale will not install if / space is "limited"
by Felix Miata 01 Nov '14

01 Nov '14

Surely there must be some error. I tried to zypper up, and it refused to install glibc-locale-2.18-4.21.1.x86_64 because of inadequate space on /, even when retrying after all other updates had been installed, and running zypper clean -a. I had to bring / space available from 412148 1k blocks (92% used) to 475409 1k blocks (90% used), by temporarily moving all of /boot/ to a different filesystem. I've never run into such an obstacle with so much freespace available. How could a locale package (that I dont' even need) possibly require so much space? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0