December 2013 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] Your thoughts on dropping pm-utils
by Vojtěch Dziewięcki 13 Jan '14

13 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I maintain pm-utils, and I want to drop them soon, because systemd can handle (sort of) suspend and hibernation and also becouse their upstream is dead and I'm not able to (and don't want to) fix all the bugs all by myself. There is some information and an initial discussion on the topic here: https://bugzilla.novell.com/show_bug.cgi?id=790157 The current state is that pm-utils are sort of "plugged in" to systemd and are called from systemd to perform suspend and hibernate, if they are installed. Doesn't work too well. So I'm interested in other people's opinions on how this should be done and in particular what hooks you would like to see rewritten as systemd units, since I can usually do that. IMO the most important hook is 99Zgrub that prevents to boot another OS if we have hibernated, I've already rewritten that one, if someone wants to look at it or test it (just put it in /usr/lib/systemd/system-sleep, hibernate without pm-utils and see if the grub menu appears when you turn the computer on - it shouldn't) , here's the link: http://bugzillafiles.novell.org/attachment.cgi?id=569356 I just modified it at the end, so it works as a systemd unit, but all the functions are the same as in 99ZGrub from pm-utils. I also think it would be nice to have a "transitional period", when pm-utils won't be used as default, but if someone would be unhappy with using systemd for suspending, pm-utils could be installed. So please share your thoughts on this. I also realize there are people who would like to keep pm-utils, but unfortunately I'm not able to fix those bugs any more, so if someone wants to disagree with dropping pm-utils, that person would have to become the maintainer and fix all the bugs (or find someone else to do it), because I can't and don't want to, thanks for understanding. Wojtek Dziewięcki -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSlhzWAAoJEHrcxBn8c1xjNVMH/2qvaIUSxUz/wtCBPqSmhlv9 nJXyrst1/eM3WMA2cGt6+8DjpeNDq19Fs2j19H/WH4l1MPCyvW6R8b2UKwb++fPt RDJd4T6vKBaK46hzL6DNdigwf7JtSFJB7B69ohN85fNoSNyrzIzVtnQA0Cl5QGU8 SStmp0vy8n67WXKkOerszmpOqdpomUu+GPdy4OCcjbK2Z6VLnwBVGnFw4IcTNw2N Wu2U/Iplyt1e7mpueNOxFCQr3qJePlyqbHLeLRYi3ROshJiJycx/siyD8yB7WGa6 UmKHPj5a+Q2yZ2T9/gzZm5OmQscfum/jgPV+B4Uh53BudnW2wm75xPSuOQOyaQI= =b39f -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

17 27

[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] Why is esound-daemon automatically installed on opensuse 12.3 when using zypper dup?
by Joop Boonen 04 Jan '14

04 Jan '14

Dear all, Today I did a sudo zypper dup. I saw: sudo zypper dup root's password: Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Retrieving repository 'openSUSE-12.3-Update' metadata ................................................................................[done] Building repository 'openSUSE-12.3-Update' cache .....................................................................................[done] Loading repository data... Reading installed packages... Computing distribution upgrade... The following NEW package is going to be installed: esound-daemon The following packages are going to be upgraded: As I wondered why esound-daemon was installed I've checked out what package needs this package: rpm -q --whatrequires esound-daemon no package requires esound-daemon I've deleted this package via: rpm -evh esound-daemon Preparing... ################################# [100%] Cleaning up / removing... 1:esound-daemon-0.2.41-23.1.1 ################################# [100%] without any problems. I wonder why esound-daemon is automatically installed? Regards, Joop. -- 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] smpppd anyone?
by Ludwig Nussel 02 Jan '14

02 Jan '14

Hi, Is anyone interested in maintaining smpppd? My personal usecase is gone so I have no use for smpppd anymore. If no one steps up I'll request dropping it from Factory. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

13 24

[opensuse-factory] Possible 3.13-rc nouveau regression with GT 560 Ti
by Sid Boyce 02 Jan '14

02 Jan '14

System x86_64 with openSUSE 13.1. X.Org version: 1.14.99.905 openSUSE 12.2 kernels boot successfully into a graphical screen, login to KDE4, etc. all normal. 3.13-rc kernels boot fully with X running but no graphical screen and it freezes in VC with not all the startup messages displayed but I could ssh in from another box to check dmesg and logs. Xorg.0.log which I thought I had saved did not log an error. dmesg said "nouveau Playlist update failed". Changed the GeForce GT 560 Ti for a GeForce 8600 GT and 3.13.0-rc6 is up and running. If necessary I can go back to the GT 560 Ti to gather dmesg and Xorg log information. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 10

[opensuse-factory] Cannot fetch build logs from OBS
by Andrey Borzenkov 28 Dec '13

28 Dec '13

I get bor@opensuse:~/obs/home:arvidjaar:grub2-next/grub2> osc rblt home:arvidjaar:grub2-next/grub2 openSUSE_Factory x86_64 Server returned an error: HTTP Error 400: remote error no socket attached remote error: no socket attached for any repository. Also logs are not available post-builds as well. -- 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] Replace laptop-mode-tools with tuned
by denisart benjamin2 22 Dec '13

22 Dec '13

Hello everyone, I don't come back on old reasons of purposing tuned as a laptop-mode-tools replacement. Actually, the maintainer of pm-utils want's to drop pm-utils and laptop-mode-tools requires it to work correctly. That why we need to replace it with tuned https://features.opensuse.org/314309 Regards. Benjamin -- 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] 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] Re: Up coming changes to Enlightenment (e16, e17, e18) + libraries
by Tomas Cech 20 Dec '13

20 Dec '13

Hi, On Thu, Dec 19, 2013 at 12:07:13PM +1030, Simon wrote: > Hi All, > before everyone heads off for Christmas / summer / winter breaks, i'd like > to give a heads up of some changes coming to openSUSE:factory over the > next few weeks we will try to limit breakages however some temporary > issues may be unavoidable. > Firstly the existing enlightenment package will be removed and replaced > with one called e16, this is the only change for e16 users i'll get back > to whats happening with the enlightenment package in a little bit. > > The biggest change will be to the enlightenment foundation libraries (efl) > used by e17, e18 and terminology. As of efl 1.8 all the components of the > efl with the exception of elementary are shipped as one source tar and are > built together as such we have added one new package efl and will be > removing the following packages, eina, eet, evas, eio, emotion, efreet, > e_dbus, embryo, edje and eeze. E_dbus is exception here as it is still needed for e17 to run. But that is OK, because single-source efl doesn't contain it. > As not all the extra modules / themes are available with e18 and because > it requires compositing to be enabled we have had some requests to keep > e17 around. For now we will be keeping e17 pretty much as is but probably > at version 0.17.6 instead of 0.17.3 unless it is found unusable by a > number of people, it will also build from the new efl package rather then > the older split libraries. > > Enlightenment e18 will be built in the enlightenment package, this is > because upstream have indicated they would like to do a new release at > least every year possibly less and i don't want to change the package name > that often. I will try and come up with a way for e17.3 in 13.1 to > automaticlly update to the new enlightenment e18 package that doesn't ask > people who are using e17.6 from 13.2 to update, if someone could help with > that it would be great, i don't know how to do it. > > Previously themes were named e-theme-* and modules e-module-* as themes > and modules need to be built against the right version of enlightenment > the package naming will change to e17-module-* and e17-theme-* for e17 and > enlightenment-module-* and enlightenment-theme-*, e17 users who use > terminology will also need both the e17 and enlightenment theme as e18 and > later themes are used by the libraries as well > > Currently we don't plan to keep e18 around when e19 etc come out like we > have with e16 and e17. > > Summary of changes: > Stage 1 (Basics): > * Add efl > * replace existing enlightenment package with e16) > Stage 2 (core components) > * Update elementary, terminology and e17 to use efl rather then older > libs. > * add new enlightenment package > Stage 3 (everything else) > * replace / add modules, themes and branding > * update other packages i forgot about. > * remove old libraries Thanks for this mail. Until all the changes will be done, EFL and E17 + E18 is expected to be broken. Sleep_Walker

2 1