Hi,
please add the new YaST package yast2-usbauth from
https://github.com/kochstefan/yast-usbauth or
https://build.opensuse.org/package/show/home:kochstefan/yast2-usbauth to
openSUSE Tumbleweed.
This work was initially created for SUSE in 2015. Part of it was the USB
interface authorization for the Linux kernel. It's contained in Linux
since kernel version 4.4. The packages libusbauth-configparser, usbauth
and usbauth-notifier are already part of openSUSE Tumbleweed.
packages from the usbauth development:
- libusbauth-configparser is a library that is used to parse the usbauth
config file.
- usbauth is a firewall against BadUSB attacks. It allows/denies USB
interfaces using a config file. The needed USB interface authorization
is part of Linux 4.4 and newer.
- usbauth-notifier is a graphical notifier for user interaction to allow
or deny USB devices.
- yast2-usbauth: is a YaST module to edit the usbauth configuration file
Thank you.
Best regards
Stefan Koch
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
On Wed, Oct 03, 2018 at 11:36:53PM +0000, Bugzilla_NoReply(a)novell.com wrote:
> --- Comment #31 from Gerry Makaro <suseforum(a)Fraser-Bell.ca> ---
> (In reply to Petr Gajdos from comment #30)
> Unfortunately, no. All other servers, such as microfocus, opensuse.org, and so
> on are responding decently. On the Forums, I can sit with a blank page
> "Waiting for www.suse.com ..." for a few minutes.
>
> Here, on bugzilla, I was waiting for "bugzilla.suse.com" for almost two minutes
> before I could write this reply.
We need to figure out why. I believe there will have to be ticket
against our infra created, I am in process figuring how and where ..
stay tuned.
> > Anyway, I think there's no hurry, this
> > is a minor issue. After you solve your internet connection problem, feel
> > free to contact me or YaST guys whenever needed.
>
> Okay, will do, I still have way too much to learn and way too little learned.
> :-(
If I get it correctly (you can ask yast guys to be completely sure),
they want to change module name in control center appearance. If you
open any (graphical or textual) version of 'yast2' ui, you will see
'Fonts' there. They want to change it to 'System Fonts'.
The name is taken from
/usr/share/applications/YaST2/fonts.desktop
You can try it yourself: Change
Name=Fonts
to
Name=System Fonts
rerun the yast2 control center and see the result :).
So all you would need to do is to change it in git/yast/yast-fonts
too.
Petr
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
In 15.1 we wanted to switch to using NetworkManager by default for all
desktop installations, replacing the not so obvious magic that only uses
NetworkManager when installing on a Laptop. Only the Server and
Transactional Server installations should keep wicked.
Furthermore, since SLE uses roles for such things, Richard
volunteered to rework Leap's control.xml using roles in Leap too.
The hope was to get rid of the desktop_roles code too.
So far so good:
https://openqa.opensuse.org/tests/759914#step/system_role/1
However, now we lost the ability to install with online repos
enabled. In 15.0 there was a button for that in the desktop selection:
https://openqa.opensuse.org/tests/678918#step/installer_desktopselection/1
In SLE that is covered when registering. There's a popup that asks
whether to enable online repos:
https://openqa.suse.de/tests/2084621#step/scc_registration/6
Since Leap doesn't use registration that popup doesn't exist there.
So now I wonder what alternatives we have. I'd rather like to avoid
introducing this ugly screen again:
https://openqa.opensuse.org/tests/302627#step/installation_mode/1
So any ideas how to get the feature back?
Would it be possible to add the "Configure Online Repositories"
button on the role selection dialog?
Or maybe have the popup of SLE when the system can reach
download.o.o, just without prior registration?
What's easier code wise?
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi all,
because the SLE12-SP4 project does not accept fixes to GMC anymore (only the bug
fixes for the P1 blockers approved by the release managers) I have disabled the
autosubmit to the SUSE:SLE-12-SP4:GA project in Jenkins.
**Since now you need to submit the packages to SLE12-SP4 manually!**
There are two options:
- Run "rake osc:commit" to commit the package to Devel:YaST:SLE-12-SP4, then manually
create a SR either to SUSE:SLE-12-SP4:GA (P1 blocker) or to SUSE:SLE-12-SP4:Update
(the rest).
or
- Update the ruby2.5-rubygem-yast-rake package to version 0.2.28 (or newer) from
YaST:Head or Git and run "rake osc:sr", this updated version now submits to
SUSE:SLE-12-SP4:Update.
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi all,
Short version: see https://github.com/yast/yast-yast2/pull/859
Full version:
The Rubocop version we currently use (0.41.2) is quite old (~2.5 years) and Github
even reports a low severity security issue with this version [1]. So I'd like to
propose upgrading the Rubocop to the latest version.
I have created a RFC PR with the updated global configuration [2], but besides the
option renames and specifying Ruby 2.5 there is nothing interesting. More interesting
is the testing run in the "yast2" package (I deliberately used one of the biggest and
oldest packages), see [3].
I have collected and commented some new checks which we should probably disable or at
least discuss the default values. Of course, we can later fine tune the config per
package, so if we decide to enable something globally we can still disable it in
specific packages (even only for specific files, we can be less strict for the legacy
Ruby YCP code).
The newer version adds many more checks but either I find them useful so they should
be enabled or at least I did not find a reason why they should be disabled. But feel
free to discuss any issue not mentioned in the list.
Also you might try running it in some other packages (yast2-storage-ng might be a
good candidate), it might report other issues not present in yast2. But you need to
install the gem manually with "gem install rubocop". No RPM yet, even
devel:languages:ruby:extensions does not contain the latest one.
RFC
---
Please check PR [3] and discuss the possible issues there.
Note
-----
I started testing the upgrade with Rubocop 0.59.2 but in the meantime they released
version 0.60.0. The change log [4] does not list any new checks or major changes so I
expect the upgrade to 0.60.0 should be basically the same.
(But maybe I'd wait with the upgrade a bit, usually after releasing the x.0 version
they quite often release a bug fix version x.1 or even x.2 in few days/weeks ;-))
Integration
===========
The Travis integration will be easy, we use Docker images and we install the Rubocop
gem as RPM from YaST:Head. We can build a different version for Tumbleweed/Factory in
OBS and keep the old version for 15.0 (and older).
We run Rubocop only in Travis, that means the Jenkins autosubmission or OBS builds
will not be affected by this change.
Development
-----------
The only problem is running Rubocop locally during development. Rubygems can be
easily packaged to RPMs with multiversion support, you could install more versions in
parallel. (This will possibly require a small fix in the current YaST:Head package.)
The problem is how to distinguish which version to run in a Git checkout. We define
"rake check:rubocop" task so we could modify it to somehow automatically find out
which version to use. I think we could use a similar approach as we use for the osc
target in Rakefile, something like:
Yast::Tasks.rubocop_version "0.60.0"
We would add this only in "master". For the backward compatibility we would assume
version "0.41.2" if the option is not set so we do not have to touch all maintenance
branches.
Obviously if you run rubocop directly (without the rake wrapper) then you have to
know which exact version to run, no magic.
Any comments, ideas?
[1] https://nvd.nist.gov/vuln/detail/CVE-2017-8418
[2] https://github.com/yast/yast-devtools/pull/134
[3] https://github.com/yast/yast-yast2/pull/859
[4] https://github.com/rubocop-hq/rubocop/blob/master/CHANGELOG.md#0600-2018-10…
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi Ken (and yast-devel audience in general).
We already implemented a first prototype of the new partitioner UI which
makes RAIDs partitionable by adapting dynamically the set of buttons at
the bottom of the table (to reflect only actions that apply to the
selected row).
But there are still too many buttons to fit nicely in 80x24. So we
prepared the following gist with (animated) images explaining the
current problems and some possible solutions. We need advise to move
forward.
https://gist.github.com/ancorgs/bf81a230e2a4634df7a05b90a1241116#file-parti…
Cheers.
--
Ancor González Sosa
YaST Team at SUSE Linux GmbH
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi all,
I want to inform you about change[1] in yast2-ruby-bindings affecting SLE12 SP4, SLE15 GA and SLE15 SP1, respective related Leap and TW.
What changes? It overwrites default ruby mechanism for setting default external/internal encoding. Now already some parts of ruby-bindings expect UTF-8 strings and in some scenarios like LC_ALL=C it can be set to ASCII. Result is that UTF-8 string cause exception. So now with that change it always expect UTF-8 as encoding of external IO.
Josef
[1] https://github.com/yast/yast-ruby-bindings/pull/221
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org