[opensuse-factory] Cannot get rid of RPC on NFSv4 only server.
Hi. I want to have a NFSv4 without the RPC services running. IIRC it was possible on 13.2 but I cannot get rid of RPC now on Tumbleweed. If I mask the rpcbind service or socket the system won't boot (it gets stuck waiting without limits). If I try to uninstall the rpcbind package it also wants to uninstall the following packages: rpcbind patterns-openSUSE-x11_opt patterns-openSUSE-x11 patterns-openSUSE-sw_management_kde patterns-openSUSE-non_oss_opt patterns-openSUSE-non_oss patterns-openSUSE-imaging_opt patterns-openSUSE-imaging patterns-openSUSE-games patterns-openSUSE-enhanced_base patterns-openSUSE-dhcp_dns_server patterns-openSUSE-base patterns-openSUSE-apparmor nfs-kernel-server nfs-client Not good... And if I disable the rpcbind service it doesn't makes any difference since it seems to be started by the rpcbind socket. So, is it possible to completely disable rpcbind or not? AFAIK it is not needed at all on a NFSv4 only server. P.S.: the NFS server autostart is disabled in YaST → NFS Server module but it is started anyway. I don't know if this should be considered a bug. Greetings. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Jul 21, 2016 at 4:02 PM, jcsl
I want to have a NFSv4 without the RPC services running. IIRC it was possible on 13.2
No, it is (and was) not possible. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El jueves, 21 de julio de 2016 16:32:27 (CEST) Andrei Borzenkov escribió:
On Thu, Jul 21, 2016 at 4:02 PM, jcsl
wrote: I want to have a NFSv4 without the RPC services running. IIRC it was possible on 13.2
No, it is (and was) not possible.
Thanks, but that is not a very helpful answer without any references or a brief ─one or two lines─ explanation. I still think that it is possible because of the following text taken from from SUSE Linux Enterprise Server 12 SP1 Release Notes: 3.1.4.5 NFSv4 only configuration ... Disabling NFSv3 (and lower) can reduce the attack surface. Setting NFS3_SERVER_SUPPORT=no in /etc/sysconfig/nfs will disable NFSv3 support and ensure that lockd and statd are not started. It does not prevent rpcbind from starting though. This is in part because rpcbind is needed for other services including NIS ¹ (aka yellow-pages) and automatically determining that none of these are required is problematic. If rpcbind is not needed (so only NFSv4 is used), it can be disabled with the command: systemctl disable rpcbind.socket I think that this is how I got rid of RPC on 13.2 (no rpc.whatever running). The problem now is that rpcbind.socket is enabled somewhere (probably by another systemd service) so rpcbind, rpc.statd, rpc.mountd and rpc.imapd are also started. The CentOS ² and Red Hat ³ documentation pages (among others) seems to confirm that RPC is not needed anymore on a NFSv4 only server. My English level isn't great so I may be missing or missunderstanding something from the text (or I just didn't explain correctly what I want in my initial message; I apologize if this was the case). If I'm wrong, any reference is welcome. Thanks in advance. [1] AFAIK, I don't use any other services requiring rpcbind. [2] https://www.centos.org/docs/5/html/5.2/Deployment_Guide/s2-nfs-how-daemons.h... [3] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ html/Storage_Administration_Guide/ch-nfs.html Greetings. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2016-07-21 at 17:35 +0200, jcsl wrote:
systemctl disable rpcbind.socket
I think that this is how I got rid of RPC on 13.2 (no rpc.whatever running). The problem now is that rpcbind.socket is enabled somewhere (probably by another systemd service) so rpcbind, rpc.statd, rpc.mountd and rpc.imapd are also started.
You cah check what might be loading rpcbind.socket using: systemctl show rpcbind.socket | grep Wanted this will likely be rpcbind.target You have to disable both. If you want to be sure nothing CAN start rpcbind.socket, just mask it: systemctl mask rpcbind.socket Does that help? Cheers, Dominique
El jueves, 21 de julio de 2016 17:41:09 (CEST) Dominique Leuenberger / DimStar escribió:
On Thu, 2016-07-21 at 17:35 +0200, jcsl wrote:
systemctl disable rpcbind.socket
I think that this is how I got rid of RPC on 13.2 (no rpc.whatever running). The problem now is that rpcbind.socket is enabled somewhere (probably by another systemd service) so rpcbind, rpc.statd, rpc.mountd and rpc.imapd are also started.
You cah check what might be loading rpcbind.socket using:
systemctl show rpcbind.socket | grep Wanted
this will likely be rpcbind.target
You have to disable both. If you want to be sure nothing CAN start rpcbind.socket, just mask it:
systemctl mask rpcbind.socket
Does that help?
Cheers, Dominique
Hi Dominique. Thanks but I have tried that already. As I wrote in the initial message, if I disable rpcbind.socket or rpcbin.service, it does nothing. And if I mask any of them the system just doesn't boot. On boot it appears a line showing a message with a timer that says that it is waiting for NFS or a related service and gets stuck waiting without a time limit (I waited three minutes). I don't remember the exact words, sorry. In addition the same message appears on all VT, so I couldn't change to another one to login, undo my changes and reboot; I had to reboot on single user mode, undo my changes and reboot again. systemctl show rpcbind.socket | grep Wanted outputs this: WantedBy=nfs-server.service rpcbind.target I didn't know that command (thanks), but I got to that file because I saw it when I disabled the rpcbind service or something similar (/etc/systemd/system/ multi-user.target.wants/nfs-server.service is the file that I found indeed). [Unit] Description=NFS server and services DefaultDependencies=no Requires= network.target proc-fs-nfsd.mount Requires= nfs-mountd.service Wants=rpcbind.socket Wants=rpc-statd.service nfs-idmapd.service Wants=rpc-statd-notify.service Greetings. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2016-07-21 at 17:57 +0200, jcsl wrote:
Hi Dominique.
Thanks but I have tried that already. As I wrote in the initial message, if I disable rpcbind.socket or rpcbin.service, it does nothing. And if I mask any of them the system just doesn't boot. On boot it appears a line showing a message with a timer that says that it is waiting for NFS or a related service and gets stuck waiting without a time limit (I waited three minutes). I don't remember the exact words, sorry. In addition the same message appears on all VT, so I couldn't change to another one to login, undo my changes and reboot; I had to reboot on single user mode, undo my changes and reboot again.
Disabling does not work in your case as some other service you start depends on it - so that's correct behaviour (enable/disable only controls if the server starts on its own)
systemctl show rpcbind.socket | grep Wanted outputs this:
WantedBy=nfs-server.service rpcbind.target
And from all the info I gather you of course want nfs-server.
I didn't know that command (thanks), but I got to that file because I saw it when I disabled the rpcbind service or something similar (/etc/systemd/system/ multi-user.target.wants/nfs-server.service is the file that I found indeed).
[Unit] Description=NFS server and services DefaultDependencies=no Requires= network.target proc-fs-nfsd.mount Requires= nfs-mountd.service Wants=rpcbind.socket Wants=rpc-statd.service nfs-idmapd.service Wants=rpc-statd-notify.service
You should be able to duplicate this unit into /etc/systemd/ and adjust the settings to your liking (remove the Wants=rpcbind.socket) Service files in /etc/systemd/ have a higher prio than the ones in /usr/lib/systemd; of course this needs good testing by yourself. Not sure, but I *think* you have to disable, then re-enable the service though to get symlinks properly setup. Cheers, Dominique
21.07.2016 18:35, jcsl пишет:
El jueves, 21 de julio de 2016 16:32:27 (CEST) Andrei Borzenkov escribió:
On Thu, Jul 21, 2016 at 4:02 PM, jcsl
wrote: I want to have a NFSv4 without the RPC services running. IIRC it was possible on 13.2
No, it is (and was) not possible.
Thanks, but that is not a very helpful answer without any references or a
It was also wrong answer. Sorry for that. Learn something new every day :)
brief ─one or two lines─ explanation. I still think that it is possible because of the following text taken from from SUSE Linux Enterprise Server 12 SP1 Release Notes:
3.1.4.5 NFSv4 only configuration ... Disabling NFSv3 (and lower) can reduce the attack surface. Setting NFS3_SERVER_SUPPORT=no in /etc/sysconfig/nfs will disable NFSv3 support and ensure that lockd and statd are not started. It does not prevent rpcbind from starting though. This is in part because rpcbind is needed for other services including NIS ¹ (aka yellow-pages) and automatically determining that none of these are required is problematic.
If rpcbind is not needed (so only NFSv4 is used), it can be disabled with the command:
systemctl disable rpcbind.socket
I think that this is how I got rid of RPC on 13.2 (no rpc.whatever running). The problem now is that rpcbind.socket is enabled somewhere (probably by another systemd service) so rpcbind, rpc.statd, rpc.mountd and rpc.imapd are also started.
nfs-server.service explicitly Requires rpcbind.target, rpc-mountd.service and Wants rpc-statd.service; rpcbind.target explicitly Wants rpcbind.socket. I am not sure about lockd, I do not even see binary with this name on Leap 42.1. So this looks like plain bug; at least, release notes are wrong and dependencies are hardcoded in service definitions. Settings NFS3_SERVER_SUPPORT=no only affects arguments to nfsd. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El jueves, 21 de julio de 2016 19:16:33 (CEST) Andrei Borzenkov escribió:
21.07.2016 18:35, jcsl пишет:
El jueves, 21 de julio de 2016 16:32:27 (CEST) Andrei Borzenkov escribió:
On Thu, Jul 21, 2016 at 4:02 PM, jcsl
wrote: I want to have a NFSv4 without the RPC services running. IIRC it was possible on 13.2
No, it is (and was) not possible.
Thanks, but that is not a very helpful answer without any references or a
It was also wrong answer. Sorry for that. Learn something new every day :)
No problem, really. :)
brief ─one or two lines─ explanation. I still think that it is possible because of the following text taken from from SUSE Linux Enterprise Server 12> SP1 Release Notes: 3.1.4.5 NFSv4 only configuration ... Disabling NFSv3 (and lower) can reduce the attack surface. Setting NFS3_SERVER_SUPPORT=no in /etc/sysconfig/nfs will disable NFSv3 support and ensure that lockd and statd are not started. It does not prevent rpcbind from starting though. This is in part because rpcbind is needed for other services including NIS ¹ (aka yellow-pages) and automatically determining that none of these are required is problematic.
If rpcbind is not needed (so only NFSv4 is used), it can be disabled with
the command: systemctl disable rpcbind.socket
I think that this is how I got rid of RPC on 13.2 (no rpc.whatever running). The problem now is that rpcbind.socket is enabled somewhere (probably by another systemd service) so rpcbind, rpc.statd, rpc.mountd and rpc.imapd are also started.
nfs-server.service explicitly Requires rpcbind.target, rpc-mountd.service and Wants rpc-statd.service; rpcbind.target explicitly Wants rpcbind.socket.
I am not sure about lockd, I do not even see binary with this name on Leap 42.1.
So this looks like plain bug; at least, release notes are wrong and dependencies are hardcoded in service definitions. Settings NFS3_SERVER_SUPPORT=no only affects arguments to nfsd.
I don't understand how systemd works, but it looks weird for me too. Greetings. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2016-07-21 at 17:35 +0200, jcsl wrote:
El jueves, 21 de julio de 2016 16:32:27 (CEST) Andrei Borzenkov escribió:
On Thu, Jul 21, 2016 at 4:02 PM, jcsl
wrote: I want to have a NFSv4 without the RPC services running. IIRC it was possible on 13.2
No, it is (and was) not possible.
Thanks, but that is not a very helpful answer without any references or a brief ─one or two lines─ explanation. I still think that it is possible because of the following text taken from from SUSE Linux Enterprise Server 12 SP1 Release Notes:
3.1.4.5 NFSv4 only configuration ... Disabling NFSv3 (and lower) can reduce the attack surface. Setting NFS3_SERVER_SUPPORT=no in /etc/sysconfig/nfs will disable NFSv3 support and ensure that lockd and statd are not started. It does not prevent rpcbind from starting though. This is in part because rpcbind is needed for other services including NIS ¹ (aka yellow-pages) and automatically determining that none of these are required is problematic.
If rpcbind is not needed (so only NFSv4 is used), it can be disabled with the command:
systemctl disable rpcbind.socket
As you quote Release Notes from SLE: those are applicable to SLE and there are sometimes differences between how SLE handles things and how openSUSE does (this gap is still there, but everybody is hard at work at closing this gap). In this specific case, I would like to point you to this patch that is applied on the nfs-utils package on SLE, but not on openSUSE: https://build.suse.de/package/view_file/SUSE:SLE-12-SP2:GA/nfs-utils/00 01-systemd-unit-files-fix-up-dependencies-on-rpcbind.patch?expand=1 Based on this I'm sure you can re-create the service file. Leap 42.2 being based on SLE12SP2 actually contains this patch as well! Hope this gets you one step further - and this should be great motivation for the NFS maintainers of openSUSE and SLE to sit together, evaluate the differences between the two branches and solve this issue also on Tumbleweed. Cheers, Dominique
21.07.2016 19:28, Dominique Leuenberger / DimStar пишет:
https://build.suse.de/package/view_file/SUSE:SLE-12-SP2:GA/nfs-utils/00
You do know that we mere mortals do not have access to build.suse.de, do not you? :)
On Thu, 2016-07-21 at 19:43 +0300, Andrei Borzenkov wrote:
21.07.2016 19:28, Dominique Leuenberger / DimStar пишет:
https://build.suse.de/package/view_file/SUSE:SLE-12-SP2:GA/nfs-util s/00
You do know that we mere mortals do not have access to build.suse.de, do not you? :)
Dang - I was sure I browsed it on build.opensuse.org :) after all, the sources are available so, here again, this time with build.o.o link: https://build.opensuse.org/package/view_file/SUSE:SLE-12-SP2:GA/nfs-uti ls/0001-systemd-unit-files-fix-up-dependencies-on- rpcbind.patch?expand=1 Sorry for that, Dominique
El jueves, 21 de julio de 2016 18:48:41 (CEST) Dominique Leuenberger / DimStar escribió:
On Thu, 2016-07-21 at 19:43 +0300, Andrei Borzenkov wrote:
21.07.2016 19:28, Dominique Leuenberger / DimStar пишет:
https://build.suse.de/package/view_file/SUSE:SLE-12-SP2:GA/nfs-util s/00
You do know that we mere mortals do not have access to build.suse.de, do not you? :)
Dang - I was sure I browsed it on build.opensuse.org :) after all, the sources are available
so, here again, this time with build.o.o link: https://build.opensuse.org/package/view_file/SUSE:SLE-12-SP2:GA/nfs-uti ls/0001-systemd-unit-files-fix-up-dependencies-on- rpcbind.patch?expand=1
Sorry for that, Dominique
Andrei was faster than me noticing the issue. No problem at all, and thanks for the link. :) Greetings. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le jeudi 21 juillet 2016 à 19:43 +0300, Andrei Borzenkov a écrit :
21.07.2016 19:28, Dominique Leuenberger / DimStar пишет:
https://build.suse.de/package/view_file/SUSE:SLE-12-SP2:GA/nfs-util s/00
You do know that we mere mortals do not have access to build.suse.de, do not you? :)
Did you try: https://build.opensuse.org/package/view_file/SUSE:SLE-12-SP2:GA/nfs-uti ls/0001-systemd-unit-files-fix-up-dependencies-on -rpcbind.patch?expand=1 ? ;) -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El jueves, 21 de julio de 2016 18:28:03 (CEST) Dominique Leuenberger / DimStar escribió:
On Thu, 2016-07-21 at 17:35 +0200, jcsl wrote:
El jueves, 21 de julio de 2016 16:32:27 (CEST) Andrei Borzenkov
escribió:
On Thu, Jul 21, 2016 at 4:02 PM, jcsl
wrote: I want to have a NFSv4 without the RPC services running. IIRC it was possible on 13.2
No, it is (and was) not possible.
Thanks, but that is not a very helpful answer without any references or a brief ─one or two lines─ explanation. I still think that it is possible because of the following text taken from from SUSE Linux Enterprise Server 12
SP1 Release Notes: 3.1.4.5 NFSv4 only configuration ... Disabling NFSv3 (and lower) can reduce the attack surface.
Setting
NFS3_SERVER_SUPPORT=no in /etc/sysconfig/nfs will disable NFSv3
support
and ensure that lockd and statd are not started. It does not
prevent
rpcbind from starting though. This is in part because rpcbind
is needed
for other services including NIS ¹ (aka yellow-pages) and
automatically
determining that none of these are required is problematic.
If rpcbind is not needed (so only NFSv4 is used), it can be
disabled with
the command: systemctl disable rpcbind.socket
As you quote Release Notes from SLE: those are applicable to SLE and there are sometimes differences between how SLE handles things and how openSUSE does (this gap is still there, but everybody is hard at work at closing this gap).
In this specific case, I would like to point you to this patch that is applied on the nfs-utils package on SLE, but not on openSUSE:
https://build.suse.de/package/view_file/SUSE:SLE-12-SP2:GA/nfs-utils/00 01-systemd-unit-files-fix-up-dependencies-on-rpcbind.patch?expand=1
Based on this I'm sure you can re-create the service file.
Leap 42.2 being based on SLE12SP2 actually contains this patch as well!
Cool :)
Hope this gets you one step further - and this should be great motivation for the NFS maintainers of openSUSE and SLE to sit together, evaluate the differences between the two branches and solve this issue also on Tumbleweed.
Cheers, Dominique
Oh, thank you, I plan to modify the file later and that would be really helpful. But is the link private or wrong? In your message the link is split at "/00" but when I add the rest (01-systemd-unit-files-fix-up-dependencies- on-rpcbind.patch?expand=1) I get a "Server not found" when I try to open the link. I can't even get to https://build.suse.de/. Greetings. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
21.07.2016 19:28, Dominique Leuenberger / DimStar пишет:
On Thu, 2016-07-21 at 17:35 +0200, jcsl wrote:
El jueves, 21 de julio de 2016 16:32:27 (CEST) Andrei Borzenkov escribió:
On Thu, Jul 21, 2016 at 4:02 PM, jcsl
wrote: I want to have a NFSv4 without the RPC services running. IIRC it was possible on 13.2
No, it is (and was) not possible.
Thanks, but that is not a very helpful answer without any references or a brief ─one or two lines─ explanation. I still think that it is possible because of the following text taken from from SUSE Linux Enterprise Server 12 SP1 Release Notes:
3.1.4.5 NFSv4 only configuration ... Disabling NFSv3 (and lower) can reduce the attack surface. Setting NFS3_SERVER_SUPPORT=no in /etc/sysconfig/nfs will disable NFSv3 support and ensure that lockd and statd are not started. It does not prevent rpcbind from starting though. This is in part because rpcbind is needed for other services including NIS ¹ (aka yellow-pages) and automatically determining that none of these are required is problematic.
If rpcbind is not needed (so only NFSv4 is used), it can be disabled with the command:
systemctl disable rpcbind.socket
As you quote Release Notes from SLE: those are applicable to SLE and there are sometimes differences between how SLE handles things and how openSUSE does (this gap is still there, but everybody is hard at work at closing this gap).
In this specific case, I would like to point you to this patch that is applied on the nfs-utils package on SLE, but not on openSUSE:
https://build.suse.de/package/view_file/SUSE:SLE-12-SP2:GA/nfs-utils/00 01-systemd-unit-files-fix-up-dependencies-on-rpcbind.patch?expand=1
This patch does not change anything and release notes still remain wrong. Even with this patch nfs-server.service explicitly Wants rpc-statd.service while release notes claim "statd is not started". And it still explicitly Wants (and statd Requires) rpcbind.socket.
Based on this I'm sure you can re-create the service file.
Leap 42.2 being based on SLE12SP2 actually contains this patch as well!
Hope this gets you one step further - and this should be great motivation for the NFS maintainers of openSUSE and SLE to sit together, evaluate the differences between the two branches and solve this issue also on Tumbleweed.
Cheers, Dominique
On Thu, 2016-07-21 at 20:07 +0300, Andrei Borzenkov wrote:
21.07.2016 19:28, Dominique Leuenberger / DimStar пишет:
This patch does not change anything and release notes still remain wrong. Even with this patch nfs-server.service explicitly Wants rpc-statd.service while release notes claim "statd is not started". And it still explicitly Wants (and statd Requires) rpcbind.socket.
It actually does - it removes rpcbind from the Requires= line in nfs- server; a Wanted service is not mandatory, but 'good to have'.. so if it's only Wanted, it can be masked away. --- a/systemd/nfs-server.service +++ b/systemd/nfs-server.service @@ -1,13 +1,14 @@ [Unit] Description=NFS server and services DefaultDependencies=no -Requires= network.target proc-fs-nfsd.mount rpcbind.target +Requires= network.target proc-fs-nfsd.mount Requires= nfs-mountd.service +Wants=rpcbind.socket Wants=rpc-statd.service nfs-idmapd.service Wants=rpc-statd-notify.service Cheers, Dominique
El jueves, 21 de julio de 2016 19:22:49 (CEST) Dominique Leuenberger / DimStar escribió:
On Thu, 2016-07-21 at 20:07 +0300, Andrei Borzenkov wrote:
21.07.2016 19:28, Dominique Leuenberger / DimStar пишет:
This patch does not change anything and release notes still remain wrong. Even with this patch nfs-server.service explicitly Wants rpc-statd.service while release notes claim "statd is not started". And it still explicitly Wants (and statd Requires) rpcbind.socket.
It actually does - it removes rpcbind from the Requires= line in nfs- server; a Wanted service is not mandatory, but 'good to have'.. so if it's only Wanted, it can be masked away.
--- a/systemd/nfs-server.service +++ b/systemd/nfs-server.service @@ -1,13 +1,14 @@ [Unit] Description=NFS server and services DefaultDependencies=no -Requires= network.target proc-fs-nfsd.mount rpcbind.target +Requires= network.target proc-fs-nfsd.mount Requires= nfs-mountd.service +Wants=rpcbind.socket Wants=rpc-statd.service nfs-idmapd.service Wants=rpc-statd-notify.service
Cheers, Dominique
The patch seems to have been already applied on Tumbleweed, no need to change anything. I have removed the references to rpcbind.socket in nfs- server.service but after a system reboot it makes no difference. I have modified the file further removing references to other rpc-xxx units but then the system didn't want to boot (again it was stuck on a no limit timer ─not very surprising given that I don't know what I'm doing). In addition, I think that the final lines containing exportfs commands should not be executed on a NFSv4 only server because IIRC exportfs and showmount don't work in this context (I don't know if they're really executed because I know nothing about systemd or any other startup system). I think that RPC should be started based on the current configuration but in this case it seems that it is executed unconditionally. rpcbind.socked is wanted by nfs-server.service and rpcbind.target; rpcbind.target is wanted by rpcbind.socket (circular dependency?); and nfs-server.service is wanted by multi-user.target. This is really complicated for me. Greetings. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2016-07-21 at 20:02 +0200, jcsl wrote:
The patch seems to have been already applied on Tumbleweed,
Oh right - on closer look it's there; just carries a different name... makes it a bit too easy to miss. With all this, I'd say you're safe to file a bug report... Cheers, Dominique
El jueves, 21 de julio de 2016 20:10:16 (CEST) Dominique Leuenberger / DimStar escribió:
On Thu, 2016-07-21 at 20:02 +0200, jcsl wrote:
The patch seems to have been already applied on Tumbleweed,
Oh right - on closer look it's there; just carries a different name... makes it a bit too easy to miss.
With all this, I'd say you're safe to file a bug report...
Cheers, Dominique
Ok. I'll organize the things in my head and then I'll file the bug report on the weekend. Thank you all for the help and hints. Greetings. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Andrei Borzenkov
-
Dominique Leuenberger / DimStar
-
Frederic Crozat
-
jcsl