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
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
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
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
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
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
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
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
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">
<!-- Clean openSUSE Leap 42.3 install with KDE Desktop -->
<!-- http://download.opensuse.org/distribution/leap/42.2/repo/oss/control.xml
-->
<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
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