November 2013 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] YaST2 "install/remove" doesn't display solver diagram
by Kyrill Detinov 13 Jan '14

13 Jan '14

Hello. There is a regression in YaST2 *Qt* "install/remove software" module. It doesn't show solver diagram. First, no dependencies on libqdialogsolver. Second, installed libqdialogsolver doesn't help. Reported ages ago. And confirmed. All the info is provided. https://bugzilla.novell.com/show_bug.cgi?id=785431 WBR Kyrill

3 3

Re: [opensuse-factory] Nothing provides /usr/bin/php5
by Sascha Peilicke 11 Jan '14

11 Jan '14

On 12/01/2011 11:44 AM, Kyrill Detinov wrote: > > Hello. > > We have one package affected in standard repo: leechcraft-eiskaltdcpp. > The program itself doesn't require php5. But the package includes > example scripts with shebang '!/usr/bin/php5'. So the package isn't > installable. > > Also I see the same problem with pgfouine from Contrib (written in > PHP) and eiskaltdcpp from filesharing repo. Maybe more in third-party > repositories. > > Can we have symlink /usr/bin/php -> php5 in php5 package? Or affected > packages should be fixed? > Please file a bug against php5 and assign to Cristian Rodríguez. -- Viele Grüße, Sascha -- 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] O Factory - Where art Thou?
by Stephan Kulow 20 Dec '13

20 Dec '13

Hi It's Thanksgiving today and we had a great harvest - "Bottle" rocks. But today is also a good time to plant new seeds for even better openSUSE releases. Factory has a healthy growth, but we have to make sure it's growing in the right direction and so the openSUSE team at SUSE had an on-and-off discussion basically since 12.3 on how to improve things. But first let me give you some background, that you might not be aware of: 10.3 had 3334 packages, 11.1 3746, 3605 for 11.2, 3807 for 11.3, 4784 in 12.1, 5710 in 12.2, 6246 in 12.3, 6678 in 13.1, 6800 right now in Factory. If you need a picture, look at http://s.kulow.org/packages Integrating these to make a good distribution is real work. And one of my favourite songs (in that context) goes: No one said it would be easy But no one said it'd be this hard No one said it would be easy No one thought we'd come this far In that song Sheryl Crow sings "It's just a question of eliminating obstacles", so what did we in the openSUSE Team do to help? We focused on getting a grip on testing by improving openqa (http://s.kulow.org/openqa-blog), but we soon found out that it was not good enough to test Factory ISOs. Factory is broken often enough not to produce ISOs at all, ISOs can't be installed and once these problems are sorted out, we found in openqa very basic things to be broken, but it was too late to protect factory users to run into them. One thing I tried was to setup "rings" to help easing the very painful staging projects (with 6800 packages, every staging project as we use them is a monster). That experiment has shown rings to be worthy way to check, but they won't work as I thought with the OBS as it is. We need to think bigger. So we tried to come up with an idea on how to improve the factory development process that includes a more clever way to utilize staging projects and openQA. As this development process is a bit hard to explain in email, Alberto and Ancor prepared an interactive diagram: https://progress.opensuse.org/workflow/factory-proposal.html We basically want to put the pressure on the submitting packager not the user. Using factory should be safe, for this we want to revive a thing that has been lost on the way: Bernhard's factory-tested project. And we want to open another submission path: from staging projects. Consider a situation where recent updates to GNOME and automake 'clash', causing problems when they're installed together. Right now we throw both into Factory, breaking both for our Factory users until we solve the issues. Instead, we think working on these issues in a separate 'staging project' could be the solution. None of us knows how *exactly* it will look alike because we need to get a conversation with the OBS team going. But the basic idea is: - GNOME:Factory stays the devel project of things that relate to GNOME updates - devel:tools stays the devel project of things that relate to automake updates - on automake updates, we open up a new devel project that stages GNOME packages for the new automake. In there, GNOME devs and automake experts work together to fix them and updates in there are submitted either back to GNOME:Factory and are integrated right into Factory. Or if that's not possible, the automake update is "grouped" with various GNOME package updates and these updates end in Factory together. There are several problems with the current "everything through devel project" approach we need to solve. Our ideas are just ideas, but I had several discussions in various places and nobody offered a better idea. So we really would like to start with it and I would like to hear your concerns so they can be part of the final solution. We have more ideas, but we can only achieve that if we get help, so let me finish with another favourite of mine What would you think if I sang out of tune? Would you stand up and walk out on me? Lend me your ears and I'll sing you a song And I'll try not to sing out of key Oh, I get by with a little help from my friends Greetings, Stephan -- Ignorance is when you don't know anything and somebody finds it out. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

32 132

[opensuse-factory] New packages submission to factory - rubygem-rspec, rubygem-packaging_rake_tasks and rubygem-yast-rake
by Josef Reidinger 09 Dec '13

09 Dec '13

Hi, I'd like to introduce a few new packages that I would like to have in factory ( not 13.1 ). All is related to changes in YaST development and conversion to ruby. rubygem-rspec[1]: Very famous testing frame-work for ruby. It is quite stable now and it is widely used in various projects for testing. Inclusion allows YaST to runs its new tests written in rspec during rpm build to help with early bugs detection ( Yast use CI, but check in during rpm helps with problem detection if dependency change and obs trigger rebuild ). I am willing to maintain it in factory and fix related bugs. rubygem-packaging_rake_tasks[2]: The gem is set of tasks for ruby build tool rake contains helpers for checking code quality, easy submit to Build Service or run local build. Project is around 2 years old and I maintain it myself. It is used in few projects to make submitting ruby projects to build service easier. It reaches version 1.0.0 where API of tasks is stable. I am author and I am willing to maintain it. rubygem-yast-rake[3]: The gem is rake configuration for yast projects. It is very young project and started few weeks ago, but it is needed for new yast CI. It uses packaging rake tasks. It provides to them configuration for yast projects ( like default devel project, default target project, etc. ) and add tasks specific for yast development. It is not much stable now, but yast is only project which depend on it and now it is not needed to build, so there is no risk, it just make yast developer life easier. I am author and I am willing to maintain it. If you have any question, complain or you are interested in such packages, do not hesitate to contact me. Josef [1] http://rspec.info/ [2] https://github.com/openSUSE/packaging_tasks/ [3] https://github.com/yast/yast-rake -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 3

[opensuse-factory] Apache config changes needed
by Christian Boltz 07 Dec '13

07 Dec '13

Hello, if you are updating to the latest Apache packages from Factory, you'll get a "Forbidden" error, and the log contains: AH01630: client denied by server configuration This is probably caused by * Mo Nov 04 2013 freek(a)opensuse.org - Removed obsolete directive DefaultType - Changed all access control to new Require directive The solution is to replace Order allow,deny Allow from all with Require all granted in the apache config. This change is needed even if the access_compat module is loaded [1] :-( Freek, was this an intentional change, or something we should call a bug? ;-) Regards, Christian Boltz [1] APACHE_MODULES="actions alias auth_basic authz_host authz_groupfile authz_user authn_dbm autoindex cgi dir env expires include log_config mime negotiation setenvif ssl suexec userdir php5 rewrite proxy proxy_http reqtimeout unixd access_compat authz_core systemd authn_core" -- Maybe the next openSUSE conference should have a mandatory group hug after all... ;-) [Jos Poortvliet in opensuse-factory] -- 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] yast2-http-server no longer usable with apache 2.4 in openSUSE 13.1 and Factory
by Freek de Kruijf 05 Dec '13

05 Dec '13

With the appearance of apache2 version 2.4 in openSUSE 13.1 and Factory. the module yast2-http-server is no longer usable. I studied the ruby code, but I don't think I will be able to adopt it to the requirements of apache2 2.4, without putting a lot of effort in it, but it will take too long time to complete. I have a general idea about what needs to be changed, so when there is somebody who is knowledgeable in ruby and in the details of how a yast2 module must be made, I can give directions on what the module needs to do. This all is under the condition that the community has a need for such a module. -- fr.gr. Freek de Kruijf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 8

[opensuse-factory] RE: [Bug 847971] Chromium from openSUSE has MP3/MP4 support
by Ignacio Areta 03 Dec '13

03 Dec '13

Oh sorry, you understood (and I too). So, let's redo the story. (= This is a little strange. Recently, you changed the package to add protobuf dependency. This is a major change, isn't it? In the last year, you moved Chromium to Packman because of FFMpeg. At that time, Chromium was shipped without FFMpeg. Some days after doing this, you moved these packages back to openSUSE after discovering a method to compile Chromium's FFMpeg only with free codecs support. Then was born the chromium-ffmpegsumo package. Support to the the proprietary codecs weren't in openSUSE's package beacause as we know, these formats has issues with patents in some countries. Right? People, now this isn't working properly, because chromium-ffmpegsumo is reproducing MP3/MP4. The chromium.spec has these two lines: -Dproprietary_codecs=1 -Dffmpeg_branding=Chrome According to the Chromium's wiki ( www.chromium.org/audio-video ) the use of these 2 build flags activates the support for the proprietary formats. I think the way to fix this is changing these values to 0 and Chromium, respectively. Any other idea? Regards, Ignacio PS: Raymond, I forgot to subscribing to the list, so I can't reply your email directly. PS2: sorry for the 6th paragraph in the comment 1 of the bug. I used the wrong words. >Thanks for making me look stupid and that I do not understand the issue. The >reason why I asked you to write to this mailinglist was your statement that >Chromium should be build without the proprietary-codec and branding=chrome >options. This would mean that Chromium no longer would support H.264, MP4, etc >codecs that normally are supported by Chrome. As that this is a major change, >I asked you to validate this on this mailinglist. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

12 28

[opensuse-factory] Have php-pear-Net_IDNA2 in openSUSE:Factory
by Aeneas Jaißle 01 Dec '13

01 Dec '13

In an effort to push most packages currently in server:Kolab:Extras to openSUSE:Factory, I'd like to open a submit request from server:php:applications/php-pear-Net_IDNA2[1] to openSUSE:Factory/php-pear- Net_IDNA2. php-pear-Net_IDNA2 is a PHP library for Punycode encoding and decoding. It is required by roundcubemail, that is used as the default web client for Kolab. Any objections? [1] https://build.opensuse.org/package/show/server:php:applications/php5-pear-N… -- Aeneas Jaißle » e: aj(a)ajaissle.de Sent using Kontact and Kolab on openSUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 2

[opensuse-factory] Re: [opensuse] Re: What happened to dovecot?
by L.A. Walsh 30 Nov '13

30 Nov '13

On 28/11/2013 01:01, Marcus Meissner wrote: > On Wed, Nov 27, 2013 at 08:43:46PM -0800, Linda Walsh wrote: >> On 27/11/2013 13:16, Carlos E. R. wrote: >>> Because 13.1 reinstated apparmor as installed and running by default. >>> This was not the case in 12.3 and perhaps some versions earlier. >> ---- >> >> ??? Didn't someone else mention documented problems in the release >> notes with apparmor? Are you saying the "new" default is to turn on a >> non-standard security mechanism on all machines??? >> >> Why would they do that? > > It is a standard security mechanism. --- It is not the Linux nor the Unix standard security mechanism. It is an "advanced" or "alternate" security system that is not selected by default when you create a new kernel. > If there are issues then we can fix them. --- Since it runs at boot, you are presuming the person is able to login, and bring up some mechanism to doing that. If they find themselves locked out of their machine...they likely won't. If they have an alternate way to access the net, they still may not be able to give any useful information if locked out of machine. Certainly, if they are a new user to OS, or, worse, Linux in general, they will be completely clueless. If they have close friends they generally turn to for help, first, those friends will be less likely to be able to help them unless they already know 1) OpenSuse, and 2)app armor. That will cut off a sizable portion of their (possibly non-existent) "close support group" as well. vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv * If it was ***an option**, on install -- "do you want to install the * Advanced Security Mechanism, AppArmor or do you want to use the * standard Linux security mechanism? [If you didn't understand those * terms, choose the latter]. (y/[n]) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > You can run "logprof" or similar and report missing things in > profiles. --- While I could probably figure it out, I have a computer background, but until now I'd wouldn't have known logprof would have helped me -- I won't say I haven't seen the word before, but it wasn't something I was familiar with or how to use it to get into a machine I was locked out of due to AppArmor. If the option, at install (or upgrade time) was offered -- then they can take can take responsibility and, at least, know they installed a non-standard security system that isn't the default linux security mechanism. But if they are expecting a basic-linux install, I'd find a default installation of apparmor, to be like installing a Greek-font and language interface for the default installation -- sure, you could call them standard, in Greece (maybe), but it doesn't seem like a wise choise for new users OR users using the older (or perhaps a different) model. It violates the premise of "least surprise". None of this should be taken as a reflection on Apparmor being good or bad, just that it's something else that might go wrong, that, if it isn't configured "perfectly", will cause odd and random symptoms of programs being able to start, but access no resourses (like happened to the OP)... In order to create an experience with fewer unpleasant surprises (or surprises of any kind), I wouldn't *enable* (might install), AppArmor as a default. Same with "rtmond" -- installed, sure. But for a personal computer with only 1 user... I would question the need for such a mechanism as enabled by default. *cheers*, Linda p.s. -- NOTE -- in GENERAL, configuring packages to be ON by default if if they are installed, is a troublesome behavior. I see many things at install that I'd like to *try*, but usually 1 at a time. I'd prefer many things (if not most) to be "chkconfig'ed off" or whatever equivalence the SW has, by default on install (except for basic services needed to run the system). Might even have a "configcheck service" -- like the rpmconfigcheck, that checks for installed but unconfigured or disabled (have never been enabled) services -- and given to users on a list, so they can go down the list and configure & check out each of the new options. For me, I'd find such much better than the -- "we tried to set things up based on our test systems in Laos, and we had no complaints"...;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 18

[opensuse-factory] DROP proposal: gsynaptics
by Dimstar / Dominique Leuenberger 30 Nov '13

30 Nov '13

Hi all, After having debugged an issue of not being able to configure TouchPads, it became apparent that some bitrot is at fault here: gsynaptics still lies around in our repos and happens to build.. but, that does not make it any usable. The daemon is configured to only fire up in a gnome session, where this used to be 'preferred long ago', but nowadays, this functionality is provided by GNOME intrnally, and it interacts directly with syndaemon (from xf86-input-synaptics). GNOME still has code detecting the presence of gsynaptics and would move itself out of the way, but then of course anything the user does in gnome-control-center is useless; the user would have to (and need to know to) configure all the settings in gsynaptics.. which is an ugly tool and provides no additional functionality (in my view). so, if nobody comes up with a very compelling argument as to why gsynaptics should not be removed from Factory (and this, openSUSE 13.2), I will file for a delete request soon. Cheers, Dominique -- Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org> -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

6 10