openSUSE Users December 2016

users@lists.opensuse.org

91 participants
162 discussions

[opensuse] Why no 'still' (LibreOffice 5.1) packages available for 42.2

by David C. Rankin

Leap Devs, Why are there no 'still' (libreoffice 5.1) packages available for leap 42.2. There are a number of bugs in 5.2 concerning re-arrangement of the context menu that impacts document formatting. The stable 'still' packages are available for all versions though 42.1, but not 42.2. Are these going to be built? See: http://download.opensuse.org/repositories/LibreOffice:/5.1 -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 years, 6 months

[opensuse] Leap 42.2 - Why NO Persistent Block Device Naming for 'resume' in /etc/default/grub??

by David C. Rankin

Leap Devs, Why is Persistent Block Device Naming not used for 'resume' in /etc/default/grub? Specifically, I ran into an issue when moving my leap42 drive to sdb in my laptop. On boot, there was a 'root switch', but then there was a 90 sec timeout looking for the 'resume' device (previously sda8, now sdb8). Checking, I find: GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sda8 splash=silent quiet showopts" in /etc/default/grub. Why on earth are we not using UUIDs there (which is the grub2 default)? Had this been, GRUB_CMDLINE_LINUX_DEFAULT="resume=3cadab5b-13b4-4dce-84d3-05e2070f741c ... (which it is now), there would have been no problem. Using the default persistent block device naming also eliminates the need for the antiquated 'device.map' file in /boot/grub2. Is there some specific reason the old naming convention is being used instead of UUIDs here? Grub2 will use UUIDs unless you explicitly tell it not to with 'GRUB_DISABLE_LINUX_UUID=true' in /etc/default/grub. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 years, 6 months

[opensuse] Extra cursor after 13.1 => 13.2 upgrade

by Jeffrey L. Taylor

There is a arrow pointer/cursor in the middle of the screen after an upgrade from 13.1 to 13.2. Plus the usual cursor. The extra is a white arrow with black outline. Any thoughts on how to get rid of it. Lenovo T520 w/ just Intel graphics. TIA, Jeffrey -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 years, 6 months

[opensuse] upgrade question re postgresql

by Carlos E. R.

Hi, I upgraded from 13.1 to 42.2. During the process, there were some errors about postgresql94 (it failed). So now I look in YaST package manager to see about postgresql, and I see it is installed (version 9.4-2.2). I also see postgresql93 (9.3.11-4.1) and postgresql94 (9.4.9-8.1), not installed. Which one should I really have installed on Leap 42.2? -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

5 years, 6 months

[opensuse] Re: [opensuse-factory] updating tumbleweed - best practices

by Richard Brown

On 28 December 2016 at 20:39, Anton Aylward <opensuse(a)antonaylward.com> wrote: > On 12/28/2016 12:49 PM, Richard Brown wrote: >>> > >>> > I must admit I'm confused here. >>> > Regular readers will recall that I make use of the kernel_Stable repository. >>> > I'm running kernel 4.9.0. >> Why? are you involved in Tumbleweed kernel testing? If not ,then the >> correct way to consume a new kernel is to wait until it's actually >> tested and in Tumbleweed properly. > > Someone described TW as not factory but a perpetual beta release. That is not how I would describe it. TW is not Factory, TW is a rolling release. Every single 'release' of the rolling release is only given to users after several hundred installations, upgrades, and other tests have been carried out On several architectures These are not artificial 'some code gets poked by some script' tests, but fully automated human-interaction testing. openQA installs openSUSE using YaST, using various different YaST mechanisms (graphical, ncurses, ssh, etc). openQA installs various different combinations of software, such as GNOME or KDE or XFCE. openQA boots those systems up and checks all the core applications of those desktop environments, by actually opening them and making sure they work, using the same mouse and keyboard and graphics drivers real users would use. 24 hours a day, 7 days a week, thousands of tests a day, and that's ignoring the dozens of tests we do in 'staging' which happens before any new packages even reach Factory and therefore go anywhere near to Tumbleweed. It's a rolling release. It's tested. It works. Maybe not perfectly, but well enough for it's users to rely on it every day, as I do. > In some ways alternative repositories are like that. (That's certainly the way I > use Darktable.) In other ways they are things (such as exFAT for reading SDXC > memory cards from my camera) that are from other repositories because they are > outside the licence that openSuse uses. Hmm a few other things like that, too. No, it is nothing like that The repositories you use for darktable and other things have no testing - none at all The repositories you use for darktable and other things have no integration standards - Tumbleweed has countless checks, manual and automatic, to make sure its packages are built, and built properly, with sensible dependency configurations and such The repositories you use for darktable and other things have no quality & legal standards - Even ignoring the testing, every Tumbleweed submission is reviewed by at least 3 pairs of eyes before reaching any humans. Licenses are checked to make sure we can legally distribute those packages as part of the openSUSE distribution. Devel projects are for Development. Home projects are for people to do whatever they want in. They MAY have proactive maintainers. They MAY make some effort to do some of the above. But there is no guarantee. And even in those cases of 'well-maintained' devel projects, none of them yet approach even a fraction of the careful engineering, review, and testing that Tumbleweed goes through. And if they did, I think the entire purpose of Devel and Home projects would be undermined - applying all those checks so early in the development process of a package is going to slow things down, and that's not going to help that package or the users who want a package that works. > Some of 'tested .. and properly' might not happen or might not happen soon > enough or when you need it. There was a discussion about disk queueing > algorithms on this thread recently, the advantage of BFQ, but while its the > default in other distributions, openSuse seems reluctant to adopt it. And lets > face it, we're slow to keep up with updates to things like systemd as well. We move at the pace of contributions. There is lots of talk about lots of things. Lets take the two examples you gave. Did anyone actually submit a proposed change to BFQ as a default? If yes, then you have a point and I & the rest of the openSUSE Board would be interested in following that up. But I believe the answer to be no, and so your point is not valid. Contributions matter, not talk. Same for systemd - systemd is moving at the pace of comfort for our current systemd maintainers. If others are prepared to do the work to move faster, I'm sure we could find an accommodation between new faster-moving contributors and the current one..but talking about wanting a faster moving systemd is all for nothing is no one is stepping up to do the work, and I don't see anyone at this time. Hope this helps -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 years, 6 months

[opensuse] rpm problems on upgrades

by Carlos E. R.

Hi, When one upgrades a package it can happen that you get these configuration files: configfile.rpmnew configfile The idea is that the admin reviews the changes and accepts what he wants. Now, just one example. Package open-iscsi-2.0.873-43.1.x86_64. I get: Telcontar:/etc/iscsi # l total 56 drwxr-xr-x 3 root root 4096 Dec 26 14:56 ./ drwxr-xr-x 214 root root 20480 Dec 27 13:36 ../ drwxr-xr-x 2 root root 4096 Nov 9 10:49 ifaces/ -rw------- 1 root root 421 Dec 26 14:57 initiatorname.iscsi -rw-r--r-- 1 root root 11955 Oct 28 21:12 iscsid.conf -rw------- 1 root root 11955 Nov 25 08:30 iscsid.conf.rpmnew Telcontar:/etc/iscsi # diff iscsid.conf iscsid.conf.rpmnew Telcontar:/etc/iscsi # See? The old and the new files are exactly the same one. IMHO, rpm should directly and perhaps silently replace the old file. On many other cases, the config file has not being changed by the admin (a fact that 'rpm' knows), settings at defaults, but the update still leaves the old and the new file. I think that also in this case rpm can replace the config file. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar) -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 years, 6 months

[opensuse] Re: Fixing usr merge and boot probs...

by L A Walsh

Anton Aylward wrote: > > Which gets back to the issue, how many of those are essential > for whatever you view as 'boot'? I ask this because those don't > appear in the 'lsinitrd'. > --- I differentiated between boot and getting to login prompt, but was told that sysd wanted /usr mounted in order to drive everything up to the login prompts in parallel. I have no problem separating them. Things to boot are in "boot.d", and run-level scripts are in rcX.d.. > You might also notice when you run 'lsinitrd'... --- What would I run lsinitrd on? I boot directly from my root partition on my hard disk. Then it mounts /usr, et al. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 years, 6 months

[opensuse] Can not enable syslog in 42.2 - Failed to execute operation: Too many levels of symbolic links

by Carlos E. R.

Hi, I get this: Minas-Anor:~ # rcsyslog status Usage: /sbin/rcsyslog {start|stop|status|try-restart|restart|force-reload|reload} ● rsyslog.service - System Logging Service Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: disabled) Active: inactive (dead) Minas-Anor:~ # systemctl status syslog ● rsyslog.service - System Logging Service Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: disabled) Active: inactive (dead) Minas-Anor:~ # systemctl enable syslog Failed to execute operation: Too many levels of symbolic links Minas-Anor:~ # systemctl start syslog Minas-Anor:~ # systemctl enable syslog Failed to execute operation: Too many levels of symbolic links Minas-Anor:~ # systemctl status syslog ● rsyslog.service - System Logging Service Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2016-12-22 14:01:16 CET; 55s ago Process: 3978 ExecStartPre=/usr/sbin/rsyslog-service-prepare (code=exited, status=0/SUCCESS) Main PID: 3986 (rsyslogd) Tasks: 5 (limit: 512) CGroup: /system.slice/rsyslog.service └─3986 /usr/sbin/rsyslogd -n Dec 22 14:01:16 Minas-Anor.Valinor systemd[1]: Starting System Logging Service... Dec 22 14:01:16 Minas-Anor.Valinor systemd[1]: Started System Logging Service. Minas-Anor:~ # -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 42.2, at Minas-Anor) -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 years, 6 months

[opensuse] Using GPG in XFCE (L 42.2)

by Carlos E. R.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, The release notes for Leap 42.2 say: +++...................... 2.1.3 GNOME Keyring Does Not Integrate with GPG Anymore The integrated GPG agent of GNOME Keyring has been removed. Therefore, GNOME Keyring cannot be used to manage GPG keys anymore. You can still manage GPG keys on the command line using the gpg tool. ......................++- This means that enigmail does not work. I can no longer send signed emails on Thunderbird, because it complains there is no agent. What is the alternative? Command line GPG with Thunderbird? Really? - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlhifzkACgkQja8UbcUWM1waDwD/V1JZedEkMGu0OGNZg5mQ15zk G96ISRCuQGJhlcJozNsA/0F+olIhpQ6JgQW2t9g/tRXQErQsvFWDbMgq4xw6wgEg =2NS0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 years, 6 months

[opensuse] Re: Fixing usr merge and boot probs...

by L A Walsh

Anton Aylward wrote: > Maybe those udev script were simply in /usr/lib/udev or possibly the > executable ... --- greping, I get: > grep -i /usr/share * apport:AGENT=/usr/share/apport/apport cobblerd: sed -i -e "[...]" /usr/share/cobbler/web/settings.py dkimproxy:DKIMPROXYDIR=/usr/share/dkimproxy festival: CHROOT_PREFIX="/usr/share/festival/" ipmi_port:shardir=/usr/share ipmiutil_evt:# /usr/share/ipmiutil/evt.sh ipmiutil_evt:# RUNSCRIPT="-r /usr/share/ipmiutil/evt.sh" kbd:# /usr/share/kbd - for finding keymaps kbd:KBDBASE="/usr/share/kbd" lirc: DEVINPUTCONF='/usr/share/lirc/remotes/devinput/lircd.conf.devinput' monit:MONIT_MODIFY_INITTAB="/usr/share/monit/monit-modifyinittab" named:NAMED_CONF_META_INCLUDE_FILE_SCRIPT="/usr/share/bind/createNamedConfInclude" named: test "${script:0:1}" = "/" || script="/usr/share/bind/${script}" sfcb: /usr/share/sfcb/genSslCert.sh /etc/sfcb smb:SMB_APPARMOR_UPDATE="/usr/share/samba/update-apparmor-samba-profile" tog-pegasus: if [ -x /usr/share/Pegasus/scripts/genOpenPegasusSSLCerts ]; then tog-pegasus: /usr/share/Pegasus/scripts/genOpenPegasusSSLCerts; ---- A few of those are third party scripts, others may have been moved elsewhere. Anyway, those are ones I have now. I think the one that caused probs was a virtual-machine sw-package that had usb drivers (or a script for such) in /usr/share/... It may be that they've been weeded out of post 13.1 or post 13.2 dists. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 years, 6 months

← Newer
1
2
3
4
5
6
7
...
17
Older →

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

openSUSE Users December 2016