openSUSE Factory November 2017

factory@lists.opensuse.org

152 participants
121 discussions

[Tumbleweed] dracut wails about not being able to disassemble device-mapper

by Achim Gratz

Since a few weeks dracut spews about two pages of errors/warnings on shutdown. Yesterday I halted the system instead of poweroff to be able to read those and it seems that the unmount of /oldroot fails and then the disassembly of the device-mapper devices errors out (maybe there'd been other errors before that that already rolled off the screeb). Does anybody have an idea what is going on and how to fix it? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 years, 9 months

FF56 in Tumbleweed

by Achim Gratz

I didn't see any mention of what I am supposed to do until I have used my second machine to figure out how much breakage FF56 creates for me with the plugins I am using and how to fix it. Hopefully that timewindow is going to be short, but if not, where would I get updates for FF52? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 years, 9 months

Request 545194 would cause drop of fortune

by Dr. Werner Fink

Hi, there is a drop request against fortune[1]. I'd like to vote not to drop fortune even it it does not use iconv but recode. Werner [1] https://build.opensuse.org/request/show/545194 -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

2 years, 10 months

XFCE upcoming / planned stuff

by Stefan Seyfried

Hi, (cc'ing Takashi, who does not yet know about my plans even though we are co-maintaining X11:xfce ;-) Now that the XFCE stuff in Factory is somewhat reasonably current, I'd like to propose a change in the default setup. I'd like to switch to the whiskermenu panel plugin (https://gottcode.org/xfce4-whiskermenu-plugin/) as a default start menu. Existing setups will not be changed, just the default for new users. The way this would be achieved would be a change in xfce4-branding-openSUSE package (actually xfce4-panel-branding-openSUSE) to the panel config, and that package then would get a "Requires: xfce4-panel-plugin-whiskermenu". This requires would lead to ~500kB wasted space for people who do not want to use whiskermenu, but that's it, it won't do no harm otherwise. If there are no objections, then I'd submit this soon (first to X11:xfce, then to Factory). And that brings me to the second point: I'm trying to bring the XFCE Live CDs back. OK, the ISO's are too big for CDs, but work well as DVD or hybridpersistent USB stick. If you want to try them out *now*, grab them from http://download.opensuse.org/repositories/home:/seife:/xfce/images/iso/ If there are no serious issues reported, I'd submit them to X11:xfce (and then announce the new location). There are 4 images available: XFCE-Leap-42.3-latest => XFCE from X11:xfce XFCE-Leap-42.3-stable => XFCE as shipped in Leap 42.3 XFCE-Tumbleweed-latest => XFCE from X11:xfce XFCE-Tumbleweed-stable => XFCE as shipped in Tumbleweed The latter two should be pretty identical right now, but once I submit the above whiskermenu change to X11:xfce the Tumbleweed-latest variant will get the newer look. Opinions? Have a lot of fun... seife (Once I get around the kiwi kinks, I'll also try to resurrect the XFCE based openSUSE Rescue sytem image) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 years, 10 months

Nvidia drivers - unable to switch ttys (after Gnome 3.26.1 update?)

by Robert Munteanu

Hi, I have recently lost the ability to switch ttys after a recent upgrade, I think the one with Gnome 3.26.1 . I am using the most recent TW packages, with the Nvidia proprietary drivers from the tumbleweed repo - nvidia-gfxG04-kmp-default-384.90_k4.13.4_1-26.2.x86_64 . The sympton is gdm comes up fine, I can enter my login data but then the screen blanks after logging in. Switching to another tty using Ctrl-Alt-F1 or similar does not work. I suspect that the same problem appears when logging in since (to my knowledge) gdm remains active on tty2 and creates the desktop session on ttty7. Workaround: - boot in multi-user mode, manually issue systemctl start display-manager - immediately restart gdm ( Ctrl-Alt-Backspace ) after reboot, second instance seems to work fine Has anyone seen this? If this is a bug to file, where should it go? Thanks, Robert -- http://robert.muntea.nu/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 years, 10 months

Action-Required for Packagers re: /var/adm/fillup-templates move

by Richard Brown

Hi Packagers, As previously discussed on the opensuse-packaging mailinglist, we are moving our location of fillup-templates from /var/adm to /usr/share https://lists.opensuse.org/opensuse-packaging/2017-11/msg00017.html In order to do this as smoothly as possible we are using a new %_fillupdir macro so spec files can inherit the new location, while still defining the macro as the old location for older distributions to not change anything there. https://en.opensuse.org/index.php?title=openSUSE:Packaging_Conventions_RPM_… As promised, this is the official notification that the new %_fillupdir macro is now present in Tumbleweed and should be used in all specfiles instead of /var/adm/fillup-templates The original plan was going to require all package maintainers to modify their specfiles to use the new macro. However, while taking care of the packages I am interested in for Kubic I decided to do the work for all 207 affected packages. So package maintainers, all you should have to do is review & accept the OBS Submit Requests from me referencing boo#1069468, the tracker bug for this issue. The submit requests include the compatibility definition for older distributions. Feel free to remove it if you do not need to build that package for older distributions. Please do what you can to accept and forward these requests to factory as quickly as possible, especially for those packages also used by SLE & Leap. I am hopeful to get the btrfs subvolumes simplified once these changes are complete, so I need your help to get these done promptly. Thanks in advance, -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 years, 11 months

openssl dependency problems with snapshot 20171129

by Stratos Zolotas

Hello, I'm getting the following result with the latest snapshot and I can't find an obvious solution. Any possible solution results on deinstallation of multiple packages and multiple dependency problems.. sudo zypper dup --no-allow-vendor-change 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. Loading repository data... Reading installed packages... Computing distribution upgrade... 2 Problems: Problem: libopenssl-1_0_0-devel-1.0.2m-1.1.x86_64 conflicts with libopenssl-devel > 1.0.2m provided by libopenssl-devel-1.1.0g-1.1.noarch Problem: openssl-1.1.0g-1.1.noarch requires openssl-1_1_0 = 1.1.0g, but this requirement cannot be provided Problem: libopenssl-1_0_0-devel-1.0.2m-1.1.x86_64 conflicts with libopenssl-devel > 1.0.2m provided by libopenssl-devel-1.1.0g-1.1.noarch Solution 1: deinstallation of libopenssl-1_0_0-devel-1.0.2m-1.1.x86_64 Solution 2: deinstallation of libopenssl-devel-1.0.2m-1.1.noarch Solution 3: keep obsolete libopenssl-devel-1.0.2m-1.1.noarch Choose from above solutions by number or skip, retry or cancel [1/2/3/s/r/c] (c): -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 years, 11 months

openSSL 1.1 is now the default SSL implementation

by Dominique Leuenberger / DimStar

Dear Tumbleweed users and hackers, Over the weekend the Staging for openSSL 1.1 could be finalized and checked in. as of now, openssl 1.1 is the default implementation used for openSUSE Factory (Tumbleweed starting with snapshot 20171126) This did result in quite some build failures (of non-ring packages), that will await some love from the maintainers. The typical issues are: * failed: the package does not build against openSSL 1.1. Preferably the package is ported to openSSL 1.1. For now we still have openssl- 1_0_0-devel available as well in the repo, so it is possible, for now, to revert those packages back. Keep in mind that you can only have one SSL -devel branch in your buildroot. So if your deps are pulling in SSL1.1, you might end up on the next common error * unresolvable: A package specifies it requires 'openssl' (unversionen) and now gets openssl 1.1 added to the buildroot. If you build against another package that pulls in openssl 1.0 though (e.g. libqt4: I understand that porting this to SSL 1.1 is a no-go), you result in this. The 'easiest' would be to not BuildRequire openssl at all and rely on libqt4 bringing it in (implicit dep) or, if you prefer, buildrequire openssl-1_0_0-devel on suse_version >= 1330 Thank you all for looking after your packages Cheers Dominique

2 years, 12 months

OBS: nothing provides /usr/bin/cdrdao needed by k3b

by Linux Kamarada

Hi everyone! First of all, congratulations to the OBS team, the SUSE Studio team, the KIWI team and any other teams involved in doing Studio Express. Keep up the good work! The only thing I'm really missing is testdrive, but considering that now we can use all the KIWI power on OBS, downloading the built image and testing locally on VirtualBox is just a little price worth paying! As a matter of fact, the heavy work is done on the cloud by SUSE servers free of charge... I'm trying to build a LiveDVD as close as possible from a clean openSUSE install on disk. That should be enough for it: config.kiwi (https://build.opensuse.org/package/view_file/home:livesuse:dev/LiveSUSE-Lea…) <packages type="image" patternType="plusRecommended">   <package name="patterns-openSUSE-base" /> <package name="patterns-openSUSE-x11" /> <package name="patterns-openSUSE-kde" /> <package name="sddm" /> <package name="branding-openSUSE"/> (observe the plusRecommended setting) (actually, some more packages are needed, but that is the idea, anyone interested can follow the link to the complete file) OBS succeeds. The image is built. I download it. Test it on VirtualBox. Then I realize it does not have K3b. I install K3b using zypper. Works like a charm. On purpose, I add the k3b package to the package list in config.kiwi: <package name="k3b" /> Then OBS starts building the image again, but fails. The build log shows: [ 143s] Resolving package dependencies... [ 143s] [ 143s] Problem: nothing provides /usr/bin/cdrdao needed by k3b-17.04.2-4.1.x86_64 [ 143s] Solution 1: do not install k3b-17.04.2-4.1.x86_64 [ 143s] Solution 2: break k3b-17.04.2-4.1.x86_64 by ignoring some of its dependencies [ 143s] [ 143s] Choose from above solutions by number or cancel [1/2/c] (c): c https://build.opensuse.org/package/live_build_log/home:livesuse:dev/LiveSUS… I do not understand, because the OSS repo has both k3b and cdrdao. Any ideas on what is going wrong? Thank you very much! Antonio The Linux Kamarada Project http://kamarada.github.io/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 years, 12 months

scons is going to use python3 as interpreter

by Dominique Leuenberger / DimStar

Dear Tumbleweed hackers and packagers, As you all know, python3 is 'the new thing' and pytho2 is being moved to the background. Various packages have already been switched to be using python3 - probably 'the easy ones' are all done. so we enter the jounery of more complex things. One such package is scons, which has been switched to be using python3 in request https://build.opensuse.org/request/show/542087 Now, scons is a bit 'special', as it is written in python and is basiclaly compatible to python2 AND python3, BUT it parses SConstruct/SConscript of different packages. And there the results are a bit mixed when it comes to python3 compliance Martin setup a test branch where he monitors all packages in openSUSE:Factory using scons as their build script, see https://build.opensuse.org/project/monitor/home:pluskalm:python3 Out of those only two packages are tracked as part of the rings (ffado and gpsd), which means from a Factory process perspective, once those two are fixed, the scons-switch to python3 could happen. As this will impact some other packages, I'd like to ask for your help to fix the other failing packages there. Simply branch them using "osc branch openSUSE:Factory $pkg" and submit them back to their original devel project. Martin's project only serves as monitor and should not receive submissions. In many cases, the issue in SConstruct are the usual python3 offenders: print "FOO" needs to be written as print ("FOO") now; so patches can turn out to be easy (in some cases they are more complex though) This mail serves as an info so you won't be surprised when scons is being merged and some packagaes stop building (of course some people will still be surprised, but such is life) Cheers Dominique

2 years, 12 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

openSUSE Factory November 2017