From vmoutoussamy at suse.com Thu Jan 4 09:49:17 2018
From: vmoutoussamy at suse.com (Vincent Moutoussamy)
Date: Thu, 4 Jan 2018 17:49:17 +0100
Subject: [sle-beta] Kernel patch (4.12.14-8.3.12) in our online channels
Message-ID:
Happy new year everyone!
For those who didn?t notice it we have released a kernel patch (4.12.14-8.3.12)
on 27th December, the detailed changelog of this patch can be found in attachment
or you can use "sudo zypper info -t patch SUSE-SLE-Module-Basesystem-15-2017-2151?
if you have registered your SLE 15 Beta.
/!\IMPORTANT/!\
This patch was prior to Meltdown and Spectre:
https://www.suse.com/c/suse-addresses-meltdown-spectre-vulnerabilities/
But for sure the Meltdown and Spectre CVE will also be addressed in future
updates for SLE15.
Happy testing,
Regards,
--
Vincent Moutoussamy
SUSE Beta Program and SDK Project Manager
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: SUSE-SLE-Module-Basesystem-15-2017-2151.txt
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL:
From Dick.Waite at softwareag.com Wed Jan 17 11:00:57 2018
From: Dick.Waite at softwareag.com (Waite, Dick (External))
Date: Wed, 17 Jan 2018 18:00:57 +0000
Subject: [sle-beta] Beta5 - UPDATE / migrate ?
Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D0120729301@daeexmbx1.eur.ad.sag>
Grand Beta5 Vincent,
It's Thursday in some parts our world, so will we be celebrate 2018 with a Beta that supports UPDATE / migrate so that many of us can really start to use SLES15 and check it's performance against SLES12. I do understand you want your new features tested and I have done work on that but the real test of SLES15 is it's ability to perform, with these new features, better than sLES12, and for that one needs to be able to migrate working systems to SLES15 to see what we have in "wall clock" for those night batch runs which each year seem to need to do more work in less time et al.
Wishing all an exciting and healthy 2018.
__R
Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt, Dr. Stefan Sigg; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com
From beta-programs at lists.suse.com Fri Jan 19 08:32:36 2018
From: beta-programs at lists.suse.com (SUSE Beta Program)
Date: Fri, 19 Jan 2018 16:32:36 +0100
Subject: [sle-beta] SLE 15 Beta 5 release delayed to the week of January
22nd, 2018
Message-ID: <5a620f942f579_738993931016489@boucane.mail>
Dear Beta user,
As you know, the release of the SUSE Linux Enterprise (SLE) 15 Beta 5 was
scheduled for January 18th, 2018. While we have incorporated all the feedback
received so far as part of the SLE 15 Beta 5 release, we are also working to
incorporate the fixes to the recent hardware security vulnerabilities ? Meltdown
and Spectre. The SUSE Linux Enterprise production releases have all been
updated with the fixes to these vulnerabilities. Unfortunately, due to the
timing of these hardware security vulnerabilities and the work required to
incorporate, fully test and validate the fixes in to the beta release, the
availability of the Beta 5 release has been impacted.
Our updated plan is to delay Beta 5 release originally scheduled for
January 18th, 2018 to the week of January 22nd, 2018. This allows us to deliver the
next Beta release with the fixes for the recent vulnerabilities included.
While we realize this is a delay in getting you the latest Beta release, our top
priority is ensuring these vulnerabilities are addressed so that we are not
prolonging these exposures for our beta customers.
The SLE Release Team will keep you informed on the exact release date of Beta 5
via sle-beta at lists.suse.com.
We thank you for your continued support of the SUSE Linux Enterprise 15 Beta
program and look forward to your feedback on the upcoming SLE15 Beta 5 release.
With Kind Regards,
SUSE Product Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From vmoutoussamy at suse.com Mon Jan 22 07:30:43 2018
From: vmoutoussamy at suse.com (Vincent Moutoussamy)
Date: Mon, 22 Jan 2018 15:30:43 +0100
Subject: [sle-beta] Desktop Applications Module and rpmbuild
In-Reply-To: <499e7aa4580a46e69f59f5899d55d1a1@EXUSDAGORL02.INTERNAL.ROOT.TES>
References: <499e7aa4580a46e69f59f5899d55d1a1@EXUSDAGORL02.INTERNAL.ROOT.TES>
Message-ID: <169EAB1E-B017-4E36-BD38-0F8A2477D462@suse.com>
Hi,
> On 19 Jan 2018, at 23:41, Bong Koo wrote:
>
> Hi,
>
> I have installed a VM with SLES15-Beta4 and registered it.
> During installation, I can?t add ?Development Tools Module?.
Please be more specific with ?can?t add Development Tools Module?:
- Did you register during the installation?
- apart from "Development Tools Module?, were the rest of
the modules fine to be added?
- What was the error message?
> Can I get help on installing it ?
Could you please copy/paste the output of the following command:
$ sudo zypper lr
>
> Anyway, after installation, I tried to install ?gcc? with ?zypper?.
> But, ?rpmbuild? can not be installed again.
> What is the best way to install it ?
gcc is in the "SLE-Module-Basesystem15-Pool?, so you don?t need the Development
Tools for this package. But rpm-build is in the Development Tools Module.
So we need to find the root cause of your online channels registration but you
can also manually add the ?Packages? DVD as a repository via yast/zypper.
> Regards,
> Bong
Regards,
--
Vincent Moutoussamy
SUSE Beta Program and SDK Project Manager
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL:
From beta-programs at lists.suse.com Tue Jan 23 07:32:04 2018
From: beta-programs at lists.suse.com (SUSE Beta Program)
Date: Tue, 23 Jan 2018 15:32:04 +0100
Subject: [sle-beta] [ANNOUNCE] SUSE Linux Enterprise 15 is now Beta 5!
Message-ID: <5a674764932dc_43c0f1331c764b4@boucane.mail>
We are apologizing for the delay, at last here comes Beta 5 of SUSE Linux
Enterprise 15:
SUSE Linux Enterprise Server (SLES),
SUSE Linux Enterprise Just Enough Operating System(JeOS),
SUSE Linux Enterprise Desktop (SLED),
SUSE Linux Enterprise High Availability (SLE-HA),
and SUSE Linux Enterprise Workstation Extension (SLE-WE)
Download[1]
== Important
=Migration from SLE 12 to SLE 15:
With Beta 5, we are still not in an ideal state for the support of the different
Migration scenarios from SLE 12 to SLE 15. You can try it but it is not expected
to be smooth! Nevertheless do not hesitate to share your findings if you face
any issues, but keep in mind that the state of the migration will be improved
for the Release Candidate phase.
- Offline migration: With Beta 5, it is possible by using the "Installer" and
"Packages" isos.
- Online migration: Not possible with Beta 5, the SCC setup of the online
channels still needs adaptation. We hope to get this done for future beta
releases.
=Packages DVD
When using Packages DVD to install SLE modules, please make sure to also add the
Product repository you are installing (SLES / SLED / HA / ...) from Packages DVD.
Not doing so might result in missing system roles during installation.
=Notable changes
- SLE 15 Beta 5 integrates Meltdown and Spectre mitigations for the Linux kernel,
- Starting with Beta5, SLES 15 JeOS images are now available for download and testing!
However the OpenStack JeOS image will only be available in future beta,
- Virtualization: We are moving our virtual machine management tooling from
python2 to python3 for SLE 15, in that matter, Beta5 contains a lot of changes,
- openSSL 1.1.0 is now the default and used in the distribution. The old openSSL
1.0.0 will be provided in the final product in the Legacy module,
Some packages may still encounter issues.
- Planned Releases dates have been updated[5].
=Fixed bugs in beta 5 (selection):
- Modules are not preselected after registration, make sure to select Basesystem
module at minimum (bsc#1056413)
== More information
SLE Beta Page[2]
Release Notes[3]
Known Issues[4]
Your SUSE Linux Enterprise Team
== Beta Program
Please refer to our dedicated SLE Beta Program webpage[1] for any general
information. However, do not hesitate to contact us at
beta-programs at lists.suse.com if you have any questions.
You received this email because you're signed up to get updates from us.
Please send an email to beta-programs at lists.suse.com if you want to
unsubscribe.
[1] https://www.suse.com/betaprogram/sle-beta/#download
[2] https://www.suse.com/betaprogram/sle-beta
[3] https://www.suse.com/betaprogram/sle-beta/#releasenotes
[4] https://www.suse.com/betaprogram/sle-beta/#knownissues
[5] https://www.suse.com/betaprogram/sle-beta/#releases
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jrd at netlab1.net Wed Jan 24 02:22:19 2018
From: jrd at netlab1.net (Joe Doupnik)
Date: Wed, 24 Jan 2018 09:22:19 +0000
Subject: [sle-beta] Beta 5, initial impressions
Message-ID:
??? SLES 15 beta 5. My overall impression thus far is good, and the
system works as an ESXi guest in my case.
??? A few comments about it.
??? A fresh installation of beta 5 would not boot: no O/S found. Some
use of Recovery and Update menus to view and refresh disk partitioning
and initrd brought this under control. I must have made a silly error
somewhere in this familiar process. A guess is I defined a /boot
partition, type EXT2 so there is no journal to be replayed, and not
using the offered EFI choice. Root is XFS. Unless others encounter a
similar problem this will remain as a local fluke.
??? Retention of various standard network utilities (say netstat,
telnet etc) is much appreciated. Yet there remain problems such as
xinetd not installing completely and thus not being usable. What would
significantly help is a document describing the changes/shifts of
direction/replacements so that sysadmins could smoothly cope with the
changes. Presently we are left stranded.? Such a doc could extrapolate
from say SLES11 level to that now in SLES15.
??? I appreciate the gradual reordering of material; that is good.
However, in the process some common installation bits are becoming
buried in the overall structure. Examples are setting the screen
resolution and some menus now have their captions truncated and thus be
nearly unusable, ntp being disabled after its usual initial setup,
PackageKit refusing to get out of the way, nearly buried Cert Authority
config in YaST, non-tracking of GUI keyboard language, and so forth.
Thus, for the future I think a good idea would be to identify such
common practice settings and make them be more visible rather than being
relegated levels deep as now.
??? It is a bit concerning to see the Apache web server identified as
basically unsupported, and its YaST section gone. There must be a good
reasons for this, yet it would be beneficial for us to have Apache
return as a first class item rather than a DIY item.
??? I am pleased to see the system brought to the Openssl v1.1 level
across the board, and having the FIPS option.
??? Lastly, I am impressed with how well SUSE is handling the current
CPU chip security issues. That measured approach is valued.
??? Thanks,
??? Joe D.
From jsrain at suse.cz Wed Jan 24 03:10:20 2018
From: jsrain at suse.cz (Jiri Srain)
Date: Wed, 24 Jan 2018 11:10:20 +0100
Subject: [sle-beta] Beta 5, initial impressions
In-Reply-To:
References:
Message-ID: <9bba24a5-584a-7891-5f6b-c14bab18e79a@suse.cz>
Hello Joe,
On 24.1.2018 10:22, Joe Doupnik wrote:
> ??? SLES 15 beta 5. My overall impression thus far is good, and the
> system works as an ESXi guest in my case.
> ??? A few comments about it.
> ??? A fresh installation of beta 5 would not boot: no O/S found. Some
> use of Recovery and Update menus to view and refresh disk partitioning
> and initrd brought this under control. I must have made a silly error
> somewhere in this familiar process. A guess is I defined a /boot
> partition, type EXT2 so there is no journal to be replayed, and not
> using the offered EFI choice. Root is XFS. Unless others encounter a
> similar problem this will remain as a local fluke.
Hard to guess from this information, anyway: As you mentioned EFI, you
need to have a /boot/efi partition formatted as MS-DOS, otherwise the
EFI firmware will not boot.
Having (additional) /boot with ext2 should not hurt, although I don't
see a use for it.
With Beta6, you should get a warning when you do a mistake in
partitioning that should prevent booting.
Jiri
> ??? Retention of various standard network utilities (say netstat, telnet
> etc) is much appreciated. Yet there remain problems such as xinetd not
> installing completely and thus not being usable. What would
> significantly help is a document describing the changes/shifts of
> direction/replacements so that sysadmins could smoothly cope with the
> changes. Presently we are left stranded.? Such a doc could extrapolate
> from say SLES11 level to that now in SLES15.
> ??? I appreciate the gradual reordering of material; that is good.
> However, in the process some common installation bits are becoming
> buried in the overall structure. Examples are setting the screen
> resolution and some menus now have their captions truncated and thus be
> nearly unusable, ntp being disabled after its usual initial setup,
> PackageKit refusing to get out of the way, nearly buried Cert Authority
> config in YaST, non-tracking of GUI keyboard language, and so forth.
> Thus, for the future I think a good idea would be to identify such
> common practice settings and make them be more visible rather than being
> relegated levels deep as now.
> ??? It is a bit concerning to see the Apache web server identified as
> basically unsupported, and its YaST section gone. There must be a good
> reasons for this, yet it would be beneficial for us to have Apache
> return as a first class item rather than a DIY item.
> ??? I am pleased to see the system brought to the Openssl v1.1 level
> across the board, and having the FIPS option.
> ??? Lastly, I am impressed with how well SUSE is handling the current
> CPU chip security issues. That measured approach is valued.
> ??? Thanks,
> ??? Joe D.
> _______________________________________________
> sle-beta mailing list
> sle-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sle-beta
--
Regards,
Jiri Srain
Project Manager
---------------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: jsrain at suse.com
Krizikova 148/34 tel: +420 284 084 659
186 00 Praha 8 fax: +420 284 084 001
Czech Republic http://www.suse.com
From jrd at netlab1.net Wed Jan 24 03:28:58 2018
From: jrd at netlab1.net (Joe Doupnik)
Date: Wed, 24 Jan 2018 10:28:58 +0000
Subject: [sle-beta] Beta 5, initial impressions
In-Reply-To: <9bba24a5-584a-7891-5f6b-c14bab18e79a@suse.cz>
References:
<9bba24a5-584a-7891-5f6b-c14bab18e79a@suse.cz>
Message-ID: <8b25093d-d58d-2931-bc39-5f98eba740bd@netlab1.net>
??? Comment placed in-line below.
On 24/01/2018 10:10, Jiri Srain wrote:
> Hello Joe,
>
> On 24.1.2018 10:22, Joe Doupnik wrote:
>> ??? SLES 15 beta 5. My overall impression thus far is good, and the
>> system works as an ESXi guest in my case.
>> ??? A few comments about it.
>> ??? A fresh installation of beta 5 would not boot: no O/S found. Some
>> use of Recovery and Update menus to view and refresh disk partitioning
>> and initrd brought this under control. I must have made a silly error
>> somewhere in this familiar process. A guess is I defined a /boot
>> partition, type EXT2 so there is no journal to be replayed, and not
>> using the offered EFI choice. Root is XFS. Unless others encounter a
>> similar problem this will remain as a local fluke.
> Hard to guess from this information, anyway: As you mentioned EFI, you
> need to have a /boot/efi partition formatted as MS-DOS, otherwise the
> EFI firmware will not boot.
>
> Having (additional) /boot with ext2 should not hurt, although I don't
> see a use for it.
>
> With Beta6, you should get a warning when you do a mistake in
> partitioning that should prevent booting.
>
> Jiri
---------
Jiri,
??? Thanks for that quick clarification.
??? I do not use, nor need, the EFI scheme. I use /boot (EXT2) to avoid
historical problems merging everything into /. I do not use BTRFS,
thanks. Historically that /boot partition was/is needed to accommodate
updating the kernel, where the initrd would not be properly
reconstructed (root set as XFS). It uses EXT2 to avoid possibly needing
to update root from a journal during boot while root is still read-only
(yes, I know about file systems). To avoid all that hassle I use an EXT2
/boot partition, which works. Just what went wrong in my initial
installation process is uncertain, but a guess points to /boot and
initrd composition during the initial installation process because a
following review of that area resulted in a working version. Could be a
bug, or just a human error on my part, but I thought the problem worth
noting while matters are still fluid. Returning "/boot" to the partition
choice menu would be a wise move.
??? That future "silly me" check about partitioning errors would be
most welcomed.
??? Thanks,
??? Joe D.
>> ??? Retention of various standard network utilities (say netstat, telnet
>> etc) is much appreciated. Yet there remain problems such as xinetd not
>> installing completely and thus not being usable. What would
>> significantly help is a document describing the changes/shifts of
>> direction/replacements so that sysadmins could smoothly cope with the
>> changes. Presently we are left stranded.? Such a doc could extrapolate
>> from say SLES11 level to that now in SLES15.
>> ??? I appreciate the gradual reordering of material; that is good.
>> However, in the process some common installation bits are becoming
>> buried in the overall structure. Examples are setting the screen
>> resolution and some menus now have their captions truncated and thus be
>> nearly unusable, ntp being disabled after its usual initial setup,
>> PackageKit refusing to get out of the way, nearly buried Cert Authority
>> config in YaST, non-tracking of GUI keyboard language, and so forth.
>> Thus, for the future I think a good idea would be to identify such
>> common practice settings and make them be more visible rather than being
>> relegated levels deep as now.
>> ??? It is a bit concerning to see the Apache web server identified as
>> basically unsupported, and its YaST section gone. There must be a good
>> reasons for this, yet it would be beneficial for us to have Apache
>> return as a first class item rather than a DIY item.
>> ??? I am pleased to see the system brought to the Openssl v1.1 level
>> across the board, and having the FIPS option.
>> ??? Lastly, I am impressed with how well SUSE is handling the current
>> CPU chip security issues. That measured approach is valued.
>> ??? Thanks,
>> ??? Joe D.
>> _______________________________________________
>> sle-beta mailing list
>> sle-beta at lists.suse.com
>> http://lists.suse.com/mailman/listinfo/sle-beta
From jsrain at suse.cz Wed Jan 24 05:21:40 2018
From: jsrain at suse.cz (Jiri Srain)
Date: Wed, 24 Jan 2018 13:21:40 +0100
Subject: [sle-beta] Beta 5, initial impressions
In-Reply-To: <8b25093d-d58d-2931-bc39-5f98eba740bd@netlab1.net>
References:
<9bba24a5-584a-7891-5f6b-c14bab18e79a@suse.cz>
<8b25093d-d58d-2931-bc39-5f98eba740bd@netlab1.net>
Message-ID:
Hello Joe,
On 24.1.2018 11:28, Joe Doupnik wrote:
> ??? Comment placed in-line below.
>
> On 24/01/2018 10:10, Jiri Srain wrote:
>> Hello Joe,
>>
>> On 24.1.2018 10:22, Joe Doupnik wrote:
>>> ???? SLES 15 beta 5. My overall impression thus far is good, and the
>>> system works as an ESXi guest in my case.
>>> ???? A few comments about it.
>>> ???? A fresh installation of beta 5 would not boot: no O/S found. Some
>>> use of Recovery and Update menus to view and refresh disk partitioning
>>> and initrd brought this under control. I must have made a silly error
>>> somewhere in this familiar process. A guess is I defined a /boot
>>> partition, type EXT2 so there is no journal to be replayed, and not
>>> using the offered EFI choice. Root is XFS. Unless others encounter a
>>> similar problem this will remain as a local fluke.
>> Hard to guess from this information, anyway: As you mentioned EFI, you
>> need to have a /boot/efi partition formatted as MS-DOS, otherwise the
>> EFI firmware will not boot.
>>
>> Having (additional) /boot with ext2 should not hurt, although I don't
>> see a use for it.
>>
>> With Beta6, you should get a warning when you do a mistake in
>> partitioning that should prevent booting.
>>
>> Jiri
> ---------
> Jiri,
> ??? Thanks for that quick clarification.
> ??? I do not use, nor need, the EFI scheme. I use /boot (EXT2) to avoid
> historical problems merging everything into /. I do not use BTRFS,
> thanks. Historically that /boot partition was/is needed to accommodate
> updating the kernel, where the initrd would not be properly
> reconstructed (root set as XFS). It uses EXT2 to avoid possibly needing
> to update root from a journal during boot while root is still read-only
> (yes, I know about file systems). To avoid all that hassle I use an EXT2
> /boot partition, which works. Just what went wrong in my initial
> installation process is uncertain, but a guess points to /boot and
> initrd composition during the initial installation process because a
> following review of that area resulted in a working version. Could be a
> bug, or just a human error on my part, but I thought the problem worth
> noting while matters are still fluid. Returning "/boot" to the partition
> choice menu would be a wise move.
If you could tar-up the /var/log/YaST2 directory of your system after
installation and send it to me via email (perhaps exclude the mailing
list), I could quickly check it and possibly find what went wrong.
Separate /boot should not hurt; after your last description, it looks
more like improper location of GRUB chosen. Anyway, the logs should say
that.
> ??? That future "silly me" check about partitioning errors would be most
> welcomed.
As I wrote above, expect it for next Beta, you should get warned if
partitioning does not match the product's or bootloader's requirement.
Jiri
> ??? Thanks,
> ??? Joe D.
>
>>> ???? Retention of various standard network utilities (say netstat,
>>> telnet
>>> etc) is much appreciated. Yet there remain problems such as xinetd not
>>> installing completely and thus not being usable. What would
>>> significantly help is a document describing the changes/shifts of
>>> direction/replacements so that sysadmins could smoothly cope with the
>>> changes. Presently we are left stranded.? Such a doc could extrapolate
>>> from say SLES11 level to that now in SLES15.
>>> ???? I appreciate the gradual reordering of material; that is good.
>>> However, in the process some common installation bits are becoming
>>> buried in the overall structure. Examples are setting the screen
>>> resolution and some menus now have their captions truncated and thus be
>>> nearly unusable, ntp being disabled after its usual initial setup,
>>> PackageKit refusing to get out of the way, nearly buried Cert Authority
>>> config in YaST, non-tracking of GUI keyboard language, and so forth.
>>> Thus, for the future I think a good idea would be to identify such
>>> common practice settings and make them be more visible rather than being
>>> relegated levels deep as now.
>>> ???? It is a bit concerning to see the Apache web server identified as
>>> basically unsupported, and its YaST section gone. There must be a good
>>> reasons for this, yet it would be beneficial for us to have Apache
>>> return as a first class item rather than a DIY item.
>>> ???? I am pleased to see the system brought to the Openssl v1.1 level
>>> across the board, and having the FIPS option.
>>> ???? Lastly, I am impressed with how well SUSE is handling the current
>>> CPU chip security issues. That measured approach is valued.
>>> ???? Thanks,
>>> ???? Joe D.
>>> _______________________________________________
>>> sle-beta mailing list
>>> sle-beta at lists.suse.com
>>> http://lists.suse.com/mailman/listinfo/sle-beta
>
> _______________________________________________
> sle-beta mailing list
> sle-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sle-beta
--
Regards,
Jiri Srain
Project Manager
---------------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: jsrain at suse.com
Krizikova 148/34 tel: +420 284 084 659
186 00 Praha 8 fax: +420 284 084 001
Czech Republic http://www.suse.com
From ecki at zusammenkunft.net Sat Jan 27 16:00:42 2018
From: ecki at zusammenkunft.net (Bernd)
Date: Sun, 28 Jan 2018 00:00:42 +0100
Subject: [sle-beta] packages of minimal vs. base
Message-ID:
Hello,
what would be a command to compare the packages installed with minimal (no
package DVD) vs. base-module and text-mode pattern in SLES15?
It looks to me like the minimal system would be enough to run applications,
is that actually supported/intended or should the base module always be
present (for SLES).
BTW: in minimal I missed "sudo" and "less", both packages seem to be on the
installer media and can manually be installed. Is there a policy on what
will be on installer CD but not in minimal?
Greetings
Bernd
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ecki at zusammenkunft.net Sat Jan 27 16:23:11 2018
From: ecki at zusammenkunft.net (Bernd)
Date: Sun, 28 Jan 2018 00:23:11 +0100
Subject: [sle-beta] Packages DVD is Add-On
Message-ID:
Hello,
it is described in the manual, that you have to provide the packages DVD as
a "add-on" product if you want to install SLES15 (beta5 in my case) without
registration. However neither the "do not register" warning message nor the
"add on product" screen mention this relationship.
Maybe the screen should be titled "I would like to install an additional
Add-On product or package media" to make this more clear? (or at least
mention it in the warning message)
...
A full system can be installed using the SLE-15-Packages media from....
Please provide the location of the media files in the following Add-On
Product screen. Without these media only a minimum system is available in
this installation.
(or something).
Gruss
Bernd
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ecki at zusammenkunft.net Sat Jan 27 17:31:02 2018
From: ecki at zusammenkunft.net (Bernd)
Date: Sun, 28 Jan 2018 01:31:02 +0100
Subject: [sle-beta] beta5: Cannot adjust 'NTP' service when NTP was enabled
in installer
Message-ID:
Hello,
If I install beta5 with no registration/packages and select under settings
to get the time from the NTP pool the screen with the timezone map shows me
the right (updated) time.
But if I proceed with the installation the "Performing Installation" screen
(Step: "Save Installation Settings" -> "Writing NTP Configuration...")
shows a popup "Cannot adjust 'NTP' service.". This popup does not happen
when I do not enable NTP. When clicking OK the installation proceeds.
Gruss
Bernd
PS: in the timezone selection the "hardware clock in UTC" does not adjust
the currently displayed time. It is a bit frustrating when you select a
timezone and the displayed current time is off by an hour. Because you have
to switch on the UTC mode and then go to manual settings and correct the
time (or turn on NTP as I did). I think former versions of SLES has that
"feature" as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From kukuk at suse.de Sat Jan 27 23:15:07 2018
From: kukuk at suse.de (Thorsten Kukuk)
Date: Sun, 28 Jan 2018 07:15:07 +0100
Subject: [sle-beta] packages of minimal vs. base
In-Reply-To:
References:
Message-ID: <20180128061507.GA11802@suse.de>
On Sun, Jan 28, Bernd wrote:
> Hello,
>
> what would be a command to compare the packages installed with minimal (no
> package DVD) vs. base-module and text-mode pattern in SLES15?
Install it, run rpm -qa|sort and compare the result.
> It looks to me like the minimal system would be enough to run applications, is
> that actually supported/intended or should the base module always be present
> (for SLES).
Depends on the requirements of the application.
> BTW: in minimal I missed "sudo" and "less", both packages seem to be on the
> installer media and can manually be installed. Is there a policy on what will
> be on installer CD but not in minimal?
You have 4 products on the installer DVD, not only one. So of course
you have packages on the DVD which will not be installed with every
product.
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
From jrd at netlab1.net Sun Jan 28 04:16:51 2018
From: jrd at netlab1.net (Joe Doupnik)
Date: Sun, 28 Jan 2018 11:16:51 +0000
Subject: [sle-beta] beta5: Cannot adjust 'NTP' service when NTP was
enabled in installer
In-Reply-To:
References:
Message-ID:
??? There is also the step of going into systemd services and enabling
service NTP, at least in my experiments.
??? In the overall time keeping mix are two client-style competitors.
It seems to me, as some say, the wise choice would be use regular NTP
itself which can be both client and server, under our control. This also
avoids the mistake of force jumping clocks which are out of
synchronization, an act which can clobber cron jobs and other time
sensitive things. The initial setting of the local machine's time is
properly done by adding tag "iburst" to a server line within
/etc/ntp.conf. such as? server uk.pool.ntp.org iburst.? That causes
rapid slewing, rather than the normal more gradual one and has no jumps.
??? Nuances about choosing a time source amongst competitors is another
soft spot best left to the seasoned solutions of NTP proper. That puzzle
has been worked out over many years through much experience with the
protocol. Another thing to do in most cases is turn off using the local
clock as a time source competitor (meaning comment out the lines in
/etc/ntp.conf saying ? server 127.127.1.0 ? and ? fudge 127.127.1.0
stratum 10).
??? Thanks,
??? Joe D.
On 28/01/2018 00:31, Bernd wrote:
> Hello,
>
> If I install beta5 with no registration/packages and select under
> settings to get the time from the NTP pool the screen with the
> timezone map shows me the right (updated) time.
>
> But if I proceed with the installation the "Performing Installation"
> screen (Step: "Save Installation Settings" -> "Writing NTP
> Configuration...") shows a popup "Cannot adjust 'NTP' service.". This
> popup does not happen when I do not enable NTP. When clicking OK the
> installation proceeds.
>
> Gruss
> Bernd
>
> PS: in the timezone selection the "hardware clock in UTC" does not
> adjust the currently displayed time. It is a bit frustrating when you
> select a timezone and the displayed current time is off by an hour.
> Because you have to switch on the UTC mode and then go to manual
> settings and correct the time (or turn on NTP as I did). I think
> former versions of SLES has that "feature" as well.
>
>
> _______________________________________________
> sle-beta mailing list
> sle-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sle-beta
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ecki at zusammenkunft.net Sun Jan 28 04:37:02 2018
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sun, 28 Jan 2018 12:37:02 +0100
Subject: [sle-beta] beta5: Cannot adjust 'NTP' service when NTP was
enabled in installer
In-Reply-To:
References:
Message-ID: <5a6db5de.47a5500a.af295.64ac@mx.google.com>
Hello,
I think the Problem here is that chrony is not part of the minimal System, at least it is not installed after the Installation and I dont see the package on the Installer-DVD1.
The NTP Option in the installer is not only a one shot Option (which seems to work) but it also offers a checkbox to start the daemon. I had selected that one. The chrony config file is written with the pool entry.
(I pretty much prefer chrony over ntpd, it producs less Problems with time warping on customer systems, so it would be good to make it a essential package. Glad that SuSE catched up here)
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Joe Doupnik
Gesendet: Sonntag, 28. Januar 2018 12:16
An: sle-beta at lists.suse.com
Betreff: Re: [sle-beta] beta5: Cannot adjust 'NTP' service when NTP wasenabled in installer
??? There is also the step of going into systemd services and enabling service NTP, at least in my experiments.
??? In the overall time keeping mix are two client-style competitors. It seems to me, as some say, the wise choice would be use regular NTP itself which can be both client and server, under our control. This also avoids the mistake of force jumping clocks which are out of synchronization, an act which can clobber cron jobs and other time sensitive things. The initial setting of the local machine's time is properly done by adding tag "iburst" to a server line within /etc/ntp.conf. such as? server uk.pool.ntp.org iburst.? That causes rapid slewing, rather than the normal more gradual one and has no jumps.
??? Nuances about choosing a time source amongst competitors is another soft spot best left to the seasoned solutions of NTP proper. That puzzle has been worked out over many years through much experience with the protocol. Another thing to do in most cases is turn off using the local clock as a time source competitor (meaning comment out the lines in /etc/ntp.conf saying ? server 127.127.1.0 ? and ? fudge 127.127.1.0 stratum 10).
??? Thanks,
??? Joe D.
On 28/01/2018 00:31, Bernd wrote:
Hello,
If I install beta5 with no registration/packages and select under settings to get the time from the NTP pool the screen with the timezone map shows me the right (updated) time.
But if I proceed with the installation the "Performing Installation" screen (Step: "Save Installation Settings" -> "Writing NTP Configuration...") shows a popup "Cannot adjust 'NTP' service.". This popup does not happen when I do not enable NTP. When clicking OK the installation proceeds.
Gruss
Bernd
PS: in the timezone selection the "hardware clock in UTC" does not adjust the currently displayed time. It is a bit frustrating when you select a timezone and the displayed current time is off by an hour. Because you have to switch on the UTC mode and then go to manual settings and correct the time (or turn on NTP as I did). I think former versions of SLES has that "feature" as well.
_______________________________________________
sle-beta mailing list
sle-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sle-beta
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jrd at netlab1.net Sun Jan 28 05:34:26 2018
From: jrd at netlab1.net (Joe Doupnik)
Date: Sun, 28 Jan 2018 12:34:26 +0000
Subject: [sle-beta] beta5: Cannot adjust 'NTP' service when NTP was
enabled in installer
In-Reply-To: <5a6db5de.47a5500a.af295.64ac@mx.google.com>
References:
<5a6db5de.47a5500a.af295.64ac@mx.google.com>
Message-ID: <01f118cb-a797-bed1-68af-c55fb1210994@netlab1.net>
??? For general amusement and perhaps education, the NTP problem of
choosing amongst competing time givers is known as the Byzantine
Generals Problem. The situation is a group of Generals/time givers offer
their views, but some may not be truthful (are traitors) and ought to be
excluded from the group. The first step in a solution is to form a
majority group (a quorum, a concensus), and for that there needs to be
2N+1 participants to caste out N possible non-truthful members. Then
stratum number and optionally other measurements come into play. Thus
for us we ought to have an odd number of time givers, a minimum of three
and a few more than that can be better.
??? Including the PC local clock amongst them biases matters if the
local clock is far off the mark. It's presence is in case there are no
other time givers for this machine (network problems) and yet this
machine may offer time to other machines. Oh dear, that's an awkward
situation if the local clock may be well off, which in turn can upset a
site. To minimize the problem of possibly insane local machine clock
sources have each machine reference a set of likely external sources
located both on-site and remotely (forms overlapping meshes). Friends
helping friends based on widely spread expertise.
??? The Byzantine Generals problem arises in many kinds of
fault-tolerant systems.
??? Thanks,
??? Joe D.
On 28/01/2018 11:37, Bernd Eckenfels wrote:
>
> Hello,
>
> I think the Problem here is that chrony is not part of the minimal
> System, at least it is not installed after the Installation and I dont
> see the package on the Installer-DVD1.
>
> The NTP Option in the installer is not only a one shot Option (which
> seems to work) but it also offers a checkbox to start the daemon. I
> had selected that one. The chrony config file is written with the pool
> entry.
>
> (I pretty much prefer chrony over ntpd, it producs less Problems with
> time warping on customer systems, so it would be good to make it a
> essential package. Glad that SuSE catched up here)
>
> Gruss
>
> Bernd
>
> --
> http://bernd.eckenfels.net
>
> *Von: *Joe Doupnik
> *Gesendet: *Sonntag, 28. Januar 2018 12:16
> *An: *sle-beta at lists.suse.com
> *Betreff: *Re: [sle-beta] beta5: Cannot adjust 'NTP' service when NTP
> wasenabled in installer
>
> ??? There is also the step of going into systemd services and enabling
> service NTP, at least in my experiments.
> ??? In the overall time keeping mix are two client-style competitors.
> It seems to me, as some say, the wise choice would be use regular NTP
> itself which can be both client and server, under our control. This
> also avoids the mistake of force jumping clocks which are out of
> synchronization, an act which can clobber cron jobs and other time
> sensitive things. The initial setting of the local machine's time is
> properly done by adding tag "iburst" to a server line within
> /etc/ntp.conf. such as? server uk.pool.ntp.org iburst.? That causes
> rapid slewing, rather than the normal more gradual one and has no jumps.
> ??? Nuances about choosing a time source amongst competitors is
> another soft spot best left to the seasoned solutions of NTP proper.
> That puzzle has been worked out over many years through much
> experience with the protocol. Another thing to do in most cases is
> turn off using the local clock as a time source competitor (meaning
> comment out the lines in /etc/ntp.conf saying ? server 127.127.1.0 ?
> and ? fudge 127.127.1.0 stratum 10).
> ??? Thanks,
> ??? Joe D.
>
> On 28/01/2018 00:31, Bernd wrote:
>
> Hello,
>
> If I install beta5 with no registration/packages and select under
> settings to get the time from the NTP pool the screen with the
> timezone map shows me the right (updated) time.
>
> But if I proceed with the installation the "Performing
> Installation" screen (Step: "Save Installation Settings" ->
> "Writing NTP Configuration...") shows a popup "Cannot adjust 'NTP'
> service.". This popup does not happen when I do not enable NTP.
> When clicking OK the installation proceeds.
>
> Gruss
>
> Bernd
>
> PS: in the timezone selection the "hardware clock in UTC" does not
> adjust the currently displayed time. It is a bit frustrating when
> you select a timezone and the displayed current time is off by an
> hour. Because you have to switch on the UTC mode and then go to
> manual settings and correct the time (or turn on NTP as I did). I
> think former versions of SLES has that "feature" as well.
>
>
>
>
> _______________________________________________
>
> sle-beta mailing list
>
> sle-beta at lists.suse.com
>
> http://lists.suse.com/mailman/listinfo/sle-beta
>
>
>
> _______________________________________________
> sle-beta mailing list
> sle-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sle-beta
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From okurz at suse.de Sun Jan 28 09:12:28 2018
From: okurz at suse.de (Oliver Kurz)
Date: Sun, 28 Jan 2018 17:12:28 +0100
Subject: [sle-beta] Packages DVD is Add-On
In-Reply-To:
References:
Message-ID: <1665585.v5TZZrM4ht@linux-28d6.suse>
Hello,
On Sunday, 28 January 2018 00:23:11 CET Bernd wrote:
> it is described in the manual, that you have to provide the packages DVD as
> a "add-on" product if you want to install SLES15 (beta5 in my case) without
> registration. However neither the "do not register" warning message nor the
> "add on product" screen mention this relationship.
>
> Maybe the screen should be titled "I would like to install an additional
> Add-On product or package media" to make this more clear? (or at least
> mention it in the warning message)
>
> ...
> A full system can be installed using the SLE-15-Packages media from....
> Please provide the location of the media files in the following Add-On
> Product screen. Without these media only a minimum system is available in
> this installation.
>
> (or something).
Yes, I think extending the string in the warning message could be possible.
From fcrozat at suse.com Mon Jan 29 04:40:40 2018
From: fcrozat at suse.com (Frederic Crozat)
Date: Mon, 29 Jan 2018 12:40:40 +0100
Subject: [sle-beta] beta5: Cannot adjust 'NTP' service when NTP was
enabled in installer
In-Reply-To:
References:
Message-ID: <1517226040.9477.0.camel@suse.com>
Le dimanche 28 janvier 2018 ? 01:31 +0100, Bernd a ?crit?:
> Hello,
>
> If I install beta5 with no registration/packages and select under
> settings to get the time from the NTP pool the screen with the
> timezone map shows me the right (updated) time.
>
> But if I proceed with the installation the "Performing Installation"
> screen (Step: "Save Installation Settings" -> "Writing NTP
> Configuration...") shows a popup "Cannot adjust 'NTP' service.". This
> popup does not happen when I do not enable NTP. When clicking OK the
> installation proceeds.
This is a known issue, the installer is still not 100% migrated to
chrony but it will be soon.
> PS: in the timezone selection the "hardware clock in UTC" does not
> adjust the currently displayed time. It is a bit frustrating when you
> select a timezone and the displayed current time is off by an hour.
> Because you have to switch on the UTC mode and then go to manual
> settings and correct the time (or turn on NTP as I did). I think
> former versions of SLES has that "feature" as well.
Please open a bug report for this.
--
Frederic Crozat
Enterprise Desktop Release Manager
SUSE
From vmoutoussamy at suse.com Tue Jan 30 01:46:37 2018
From: vmoutoussamy at suse.com (Vincent Moutoussamy)
Date: Tue, 30 Jan 2018 09:46:37 +0100
Subject: [sle-beta] packages of minimal vs. base
In-Reply-To:
References:
Message-ID: <89F2188A-2AEC-4455-A099-D309E59307CC@suse.com>
Hi,
> On 28 Jan 2018, at 00:00, Bernd wrote:
>
> Hello,
>
> what would be a command to compare the packages installed with minimal (no package DVD) vs. base-module and text-mode pattern in SLES15?
This is not exactly right, minimal here in your sentence mean the Installer.
However "The scope of an installation, only containing the base system, is
comparable to the installation pattern minimal system of previous SUSE Linux
Enterprise Server versions.?
(cf https://www.suse.com/betaprogram/wp-content/uploads/2017/12/sles_installquick_20171221.pdf).
So Installer + Basesystem Module = minimal system.
The installer alone for us is not intend to be used as a ?minimal system"!
>
> It looks to me like the minimal system would be enough to run applications, is that actually supported/intended or should the base module always be present (for SLES).
Well for ?minimal system? we already provide and support JeOS. Did you take a
look at it?
> BTW: in minimal I missed "sudo" and "less", both packages seem to be on the installer media and can manually be installed. Is there a policy on what will be on installer CD but not in minimal?
> Greetings
> Bernd
Regards,
--
Vincent Moutoussamy
SUSE Beta Program and SDK Project Manager
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL:
From ecki at zusammenkunft.net Tue Jan 30 07:57:57 2018
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 30 Jan 2018 15:57:57 +0100
Subject: [sle-beta] packages of minimal vs. base
In-Reply-To: <89F2188A-2AEC-4455-A099-D309E59307CC@suse.com>
References:
<89F2188A-2AEC-4455-A099-D309E59307CC@suse.com>
Message-ID: <5a7087f9.668c500a.11874.143c@mx.google.com>
Yes you have different wordings in manual, meta data and installer gui. it woukd be good to unify minimal/base/text-only. However I was refering to the variant called ?minimal? by the installer when no package media is registered (and sles product is selected).
I am.mostly researching to give a minimal package base for installation prerequisites
Gruss
Bernd
Von: Vincent Moutoussamy
Gesendet: Dienstag, 30. Januar 2018 09:47
An: Bernd
Cc: sle-beta at lists.suse.com
Betreff: Re: [sle-beta] packages of minimal vs. base
Hi,
> On 28 Jan 2018, at 00:00, Bernd wrote:
>
> Hello,
>
> what would be a command to compare the packages installed with minimal (no package DVD) vs. base-module and text-mode pattern in SLES15?
This is not exactly right, minimal here in your sentence mean the Installer.
However "The scope of an installation, only containing the base system, is
comparable to the installation pattern minimal system of previous SUSE Linux
Enterprise Server versions.?
(cf https://www.suse.com/betaprogram/wp-content/uploads/2017/12/sles_installquick_20171221.pdf).
So Installer + Basesystem Module = minimal system.
The installer alone for us is not intend to be used as a ?minimal system"!
>
> It looks to me like the minimal system would be enough to run applications, is that actually supported/intended or should the base module always be present (for SLES).
Well for ?minimal system? we already provide and support JeOS. Did you take a
look at it?
> BTW: in minimal I missed "sudo" and "less", both packages seem to be on the installer media and can manually be installed. Is there a policy on what will be on installer CD but not in minimal?
> Greetings
> Bernd
Regards,
--
Vincent Moutoussamy
SUSE Beta Program and SDK Project Manager
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ronald.j.bynoe at intel.com Tue Jan 30 09:01:03 2018
From: ronald.j.bynoe at intel.com (Bynoe, Ronald J)
Date: Tue, 30 Jan 2018 16:01:03 +0000
Subject: [sle-beta] targetcli
Message-ID: <1517328059.2533.3.camel@intel.com>
Looks like the beta5 ISO is missing the targetcli-fb package, but it was present in the previous betas. Was this an oversight or is it being removed? If targetcli is being removed, what iSCSI target software is replacing it?
Pleasantly,
Ronald Bynoe
ND SW: IP Development
QoS and Drivers Linux Validation Lead
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From lduncan at suse.com Tue Jan 30 12:34:38 2018
From: lduncan at suse.com (Lee Duncan)
Date: Tue, 30 Jan 2018 11:34:38 -0800
Subject: [sle-beta] targetcli
In-Reply-To: <1517328059.2533.3.camel@intel.com>
References: <1517328059.2533.3.camel@intel.com>
Message-ID:
On 01/30/2018 08:01 AM, Bynoe, Ronald J wrote:
> Looks like the beta5 ISO is missing the targetcli-fb package, but it was
> present in the previous betas. Was this an oversight or is it being
> removed? If targetcli is being removed, what iSCSI target software is
> replacing it?
>
>
> Pleasantly,
> Ronald Bynoe
> ND SW: IP Development
> QoS and Drivers Linux Validation Lead
>
Have you checked for python3-targetcli-fb? This is the new name of the
package I believe, since python2 support is removed for SLE 15.
I am downloading the ISOs now the test them. If it is indeed missing
please file a bug, and please cc me?
--
Lee Duncan
SUSE Labs
From scottx.register at intel.com Tue Jan 30 13:57:08 2018
From: scottx.register at intel.com (Register, ScottX)
Date: Tue, 30 Jan 2018 20:57:08 +0000
Subject: [sle-beta] targetcli
In-Reply-To:
References: <1517328059.2533.3.camel@intel.com>
Message-ID: <1DD97F252888F94BB0FC25E64E6807792EE871AF@ORSMSX112.amr.corp.intel.com>
It does indeed look like it targetcli/python3-targetcli-fb is missing.
lin-vm-6274e:~ # zypper refresh
Repository 'SLES-15-Basesystem' is up to date.
Repository 'SLES-15-Desktop-Applications' is up to date.
Repository 'SLES-15-Desktop-Productivity' is up to date.
Repository 'SLES-15-Development-Tools' is up to date.
Repository 'SLES-15-HA' is up to date.
Repository 'SLES-15-HPC' is up to date.
Repository 'SLES-15-Legacy' is up to date.
Repository 'SLES-15-Public-Cloud' is up to date.
Repository 'SLES-15-SAP-Applications' is up to date.
Repository 'SLES-15-Server-Applications' is up to date.
Repository 'SLES-15-x86_64' is up to date.
lin-vm-6274e:~ # zypper search targetcli
Loading repository data...
Reading installed packages...
No matching items found.
-----Original Message-----
From: sle-beta-bounces at lists.suse.com [mailto:sle-beta-bounces at lists.suse.com] On Behalf Of Lee Duncan
Sent: Tuesday, January 30, 2018 11:35 AM
To: sle-beta at lists.suse.com
Subject: Re: [sle-beta] targetcli
On 01/30/2018 08:01 AM, Bynoe, Ronald J wrote:
> Looks like the beta5 ISO is missing the targetcli-fb package, but it
> was present in the previous betas. Was this an oversight or is it
> being removed? If targetcli is being removed, what iSCSI target
> software is replacing it?
>
>
> Pleasantly,
> Ronald Bynoe
> ND SW: IP Development
> QoS and Drivers Linux Validation Lead
>
Have you checked for python3-targetcli-fb? This is the new name of the package I believe, since python2 support is removed for SLE 15.
I am downloading the ISOs now the test them. If it is indeed missing please file a bug, and please cc me?
--
Lee Duncan
SUSE Labs
_______________________________________________
sle-beta mailing list
sle-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sle-beta
From fcrozat at suse.com Wed Jan 31 01:56:41 2018
From: fcrozat at suse.com (Frederic Crozat)
Date: Wed, 31 Jan 2018 09:56:41 +0100
Subject: [sle-beta] targetcli
In-Reply-To: <1DD97F252888F94BB0FC25E64E6807792EE871AF@ORSMSX112.amr.corp.intel.com>
References: <1517328059.2533.3.camel@intel.com>
<1DD97F252888F94BB0FC25E64E6807792EE871AF@ORSMSX112.amr.corp.intel.com>
Message-ID: <1517389001.7503.5.camel@suse.com>
Le mardi 30 janvier 2018 ? 20:57 +0000, Register, ScottX a ?crit?:
> It does indeed look like it targetcli/python3-targetcli-fb is
> missing.
This will be fixed for upcoming Beta6.
Thanks for your report.
--
Frederic Crozat
Enterprise Desktop Release Manager
SUSE