Bug 5828 - Debian and Ubuntu have officialy abandoned LSB
Summary: Debian and Ubuntu have officialy abandoned LSB
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Server OS (show other bugs)
Version: pre-1.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.7.0
Assignee: Peter Åstrand
URL:
Keywords: derfian_tester, hean01_tester, relnotes, samuel_tester
: 5994 (view as bug list)
Depends on: 5974
Blocks: 5829
  Show dependency treegraph
 
Reported: 2016-04-01 14:46 CEST by Pierre Ossman
Modified: 2016-12-05 15:06 CET (History)
2 users (show)

See Also:
Acceptance Criteria:


Attachments
check_lsb_5.0.py (1.70 KB, text/plain)
2016-08-17 16:23 CEST, Peter Åstrand
Details
check_lsb_4.1.py (488 bytes, text/x-python)
2016-08-30 14:09 CEST, Peter Åstrand
Details
libs-to-packages (2.24 KB, application/octet-stream)
2016-08-30 14:35 CEST, Peter Åstrand
Details

Description Pierre Ossman cendio 2016-04-01 14:46:03 CEST
So Debian has official abandoned LSB and have dropped the 'lsb' package that pulls in the necessary dependencies. Ubuntu has simply followed upstream and 16.04 therefore no longer has any meta package to get the necessary packages.

(for extra fun there is also some bug in Ubuntu that pulls in cups-filters-lsb when you ask for "lsb")
Comment 1 Pierre Ossman cendio 2016-04-01 14:46:40 CEST
Debian discussion thread:

https://lists.debian.org/debian-lsb/2015/07/msg00000.html
Comment 2 Peter Åstrand cendio 2016-04-04 09:27:49 CEST
https://lwn.net/Articles/658809/
Comment 3 Peter Åstrand cendio 2016-04-11 12:58:28 CEST
See also Bug 5405. I guess we need to do the same for Debian/Ubuntu?
Comment 4 Pierre Ossman cendio 2016-06-30 13:23:49 CEST
We've discussed several ways we could approach this. We started by looking at why we have the LSB requirement and what our needs are:

 1. What libraries and binaries can we assume exist on the system? What do we need to ship/link statically ourselves?

 2. How does a ThinLinc developer know what libraries/functions/binaries are safe to use, and which require new packaging?

 3. How to we communicate our requirements in a clear manner to our customers?

 (4. Where should files be located? (FHS))

We also discussed that no matter the solution, there could be value in clarifying the requirements in terms of which of the popular distributions fulfill the requirements.

When we discussed solutions, there were two main themes that could be seen:

 a) Make the requirements a bit more fuzzy. E.g. refer to specific distributions rather than specific technical requirements.

 b) Take over the burden of specification to ourselves, essentially copying relevant portions of LSB to our documentation/product.

Some more tangible suggestions we discussed:

 1. Only support a few specific distributions (essentially just the recommended ones), and keep track of what they contain. We also had a slightly softer approach where these where reference platforms that bugs would need to be replicated on for us to care.

 2. Have an explicit list of dependencies, somewhat copying the work from LSB in to our own documentation.

 3. No documented requirements and just try to have a feel for what libraries are "always present".

 4. Enforce the LSB requirement harder and drop support for non-LSB distributions. In practice this would probably limit us to the Red Hat sphere.

 5. Continue referring to LSB, but in a softer way. Essentially just turning it in to an externally composed list of libraries, rather than some form of certification and compliance issue. This would mean we would stop using LSB-specific stuff but still use the "normal" portions of LSB.

We decided to explore the last alternative. The obvious steps so far would be to find a good description for the documentation, and update tl-setup to be more explicit about what libraries are needed rather than lsb meta packages.

Two important questions arose as part of this:

 - Can we rely on just the core part of LSB, or do we need to drag along more LSB modules?

 - Can we restrict ourselves to just libraries specified by LSB and solve the issue of necessary commands some other way?
Comment 5 Pierre Ossman cendio 2016-06-30 13:40:46 CEST
(In reply to comment #0)
> (for extra fun there is also some bug in Ubuntu that pulls in cups-filters-lsb
> when you ask for "lsb")

This bug has now been fixed in Ubuntu. They've also done even more cleanup of LSB stuff so install_initd is no longer being shipped.
Comment 6 Peter Åstrand cendio 2016-08-17 16:23:23 CEST
Created attachment 731 [details]
check_lsb_5.0.py

The attached Python program can be used to verify if LSB 5.0 libs are present. The result is that the full LSB 5.0 is too new. Things are missing even on, say, CentOS6:

$ ./check_lsb_5.0.py 
ERROR: ld.so: object 'libcairo-gobject.so.2' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object 'libcairo-script-interpreter.so.2' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object 'libtiff.so.5' from LD_PRELOAD cannot be preloaded: ignored.

Also, LSB 5 "is the first major release to break 100% compatibility with earlier versions." (https://wiki.linuxfoundation.org/en/ReleaseNotes50#LSB_5.0_Release_Notes)

Therefore, I think we should try an earlier version instead, such as 4.1.
Comment 9 Karl Mikaelsson cendio 2016-08-25 18:04:27 CEST
Ubuntu re-added the LSB package to 16.04 on 2016-06-23, moving it into xenial-updates on 2016-07-01 after verification.

https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1536353/comments/69
https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1536353/comments/82

The reason behind re-adding LSB support is printer drivers that has dependencies on LSB.

https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1536353
Comment 12 Peter Åstrand cendio 2016-08-29 13:57:09 CEST
(In reply to comment #6)

> Therefore, I think we should try an earlier version instead, such as 4.1.

LSB 4.1.0 looks like a good candidate. It contains several sections:

LSB 4.1 Core Specification
LSB 4.1 C++ Specification
LSB 4.1 Desktop Specification
LSB 4.1 Languages Specification
LSB 4.1 Printing Specification
(Optional) LSB 4.1 Trial Use Specification

Wrt libs and programs, let's go into the details, backwards:

Trial Use
----------
Empty


Printing
--------
Provides:
libcups.so.2
libcupsimage.so.2

...but we are not using any of these. Also provides "gs". Note that we are currently requiring a ps2pdf binary, and at least on CentOS this is a thin wrapper around "gs". In other words, if we start depending on "gs" instead, we could replace our ps2pdf requirement with "gs" which is in LSB 4.1 Printing. But that's probably another bug.


Languages
---------
No libraries. Provides Python and Perl. A little bit unclear about Python 2 vs Python 3. Probably another bug.


Desktop
--------
This specification contains a long list of Libraries (which sometimes also includes commands), plus xdg-utils. In our case, we can either check for all libraries (maybe except QT), or use a subset, which can even be just "libX11". 


Core
-----
This is the most important specification. I believe we can and should depend on everything except "ld-lsb.so". 


In principle, we could consider LSB 4.0 instead of 4.1. That would better match the common distributions that are certified. For example, RHEL5 and RHEL6 are only certified for LSB 4.0, see: https://www.linuxbase.org/lsb-cert/productdir.php?by_lsb . On the other hand, the changes between 4.0 and 4.1 are small, so I'd say that we should go for 4.1 unless we stumble upon some problems. That means that we will depend on a slightly more modern base.
Comment 13 Peter Åstrand cendio 2016-08-29 14:23:00 CEST
When it comes to extracting the libs and commands from the specifications, I've tried several alternatives. No perfect solution yet - the specifications are not fully consistent. For example, these two solutions produces different results:

awk '/Runtime Name/{f=1;next} /^$/{f=0} f' | grep -v "See arch" | sort | uniq | awk 'BEGIN {printf "["} {printf "\"" $2 "\", "} END {print "]"}'

awk '/SONAME:/{print $2}' | grep -v ^See | sort | uniq | awk 'BEGIN {printf "["} {printf "\"" $1 "\", "} END {print "]"}'

The former solution gives a list without "libssl3.so", since they have forgotten to add libssl to the "overview" table in Table 3-1. On the other hand, with the latter solution, ld-lsb.so.3 is missed, because they have forgotten to add a SONAME: tag for it... 

Another solution would be to use the LSB "SpecDB". It is available via Mercurial, and for example contains:

./ArchLib.init:INSERT INTO `ArchLib` VALUES (278,1,'libssl3.so','4.0',NULL);

But I've not done any more work on that. 

Using the SONAME solution, we get this wrt libraries:

LSB-Core-generic:
["libcrypt.so.1", "libdl.so.2", "libgcc_s.so.1", "libncurses.so.5", "libnspr4.so", "libnss3.so", "libpam.so.0", "libpthread.so.0", "librt.so.1", "libssl3.so", "libutil.so.1", "libz.so.1", ]

LSB-Core-IA32 / LSB-Core-AMD64:
["libcrypt.so.1", "libc.so.6", "libdl.so.2", "libgcc_s.so.1", "libm.so.6", "libncurses.so.5", "libpthread.so.0", "libutil.so.1", "libz.so.1", ]

Combined LSB-Core:

["libcrypt.so.1", "libc.so.6", "libdl.so.2", "libgcc_s.so.1", "libm.so.6", "libncurses.so.5", "libnspr4.so", "libnss3.so", "libpam.so.0", "libpthread.so.0", "librt.so.1", "libssl3.so", "libutil.so.1", "libz.so.1", ]


Wrt "Desktop", this is what we get:

$ cat LSB-Desktop-generic.txt LSB-Desktop-IA32.txt | ./lsblibs-to-pylist
["libasound.so.2", "libatk-1.0.so.0", "libcairo.so.2", "libfontconfig.so.1", "libfreetype.so.6", "libgdk_pixbuf-2.0.so.0", "libgdk_pixbuf_xlib-2.0.so.0", "libgdk-x11-2.0.so.0", "libglib-2.0.so.0", "libGL.so.1", "libGLU.so.1", "libgmodule-2.0.so.0", "libgobject-2.0.so.0", "libgthread-2.0.so.0", "libgtk-x11-2.0.so.0", "libICE.so.6", "libjpeg.so.62", "libpango-1.0.so.0", "libpangocairo-1.0.so.0", "libpangoft2-1.0.so.0", "libpangoxft-1.0.so.0", "libpng12.so.0", "libQtCore.so.4", "libQtGui.so.4", "libqt-mt.so.3", "libQtNetwork.so.4", "libQtOpenGL.so.4", "libQtSql.so.4", "libQtSvg.so.4", "libQtXml.so.4", "libSM.so.6", "libX11.so.6", "libXext.so.6", "libXft.so.2", "libXi.so.6", "libxml2.so.2", "libXrender.so.1", "libXt.so.6", "libXtst.so.6", ]

But my suggestion is that we start with just "libX11". This will give us a combined list of:


["libcrypt.so.1", "libc.so.6", "libdl.so.2", "libgcc_s.so.1", "libm.so.6", "libncurses.so.5", "libnspr4.so", "libnss3.so", "libpam.so.0", "libpthread.so.0", "librt.so.1", "libssl3.so", "libutil.so.1", "libz.so.1", "libX11.so.6"]
Comment 14 Peter Åstrand cendio 2016-08-30 14:09:16 CEST
Created attachment 735 [details]
check_lsb_4.1.py

New script to check for LSB 4.1 libs (Combined Core list plus libX11).
Comment 15 Peter Åstrand cendio 2016-08-30 14:35:25 CEST
Created attachment 736 [details]
libs-to-packages

The attached script generates a mapping between required libraries and the package providing this library. Requires dpkg-query or rpm.
Comment 16 Peter Åstrand cendio 2016-08-30 14:36:26 CEST
(In reply to comment #15)
> Created an attachment (id=736) [details]
> libs-to-packages
> 
> The attached script generates a mapping between required libraries and the
> package providing this library. Requires dpkg-query or rpm.

Results from running this script on different platforms:


RHEL
5:
{'libX11.so.6': 'libX11',
 'libc.so.6': 'glibc',
 'libcrypt.so.1': 'glibc',
 'libdl.so.2': 'glibc',
 'libgcc_s.so.1': 'libgcc',
 'libm.so.6': 'glibc',
 'libncurses.so.5': 'ncurses',
 'libnspr4.so': 'nspr',
 'libnss3.so': 'nss',
 'libpam.so.0': 'pam',
 'libpthread.so.0': 'glibc',
 'librt.so.1': 'glibc',
 'libssl3.so': 'nss',
 'libutil.so.1': 'glibc',
 'libz.so.1': 'zlib'}

6:
{'libX11.so.6': 'libX11',
 'libc.so.6': 'glibc',
 'libcrypt.so.1': 'glibc',
 'libdl.so.2': 'glibc',
 'libgcc_s.so.1': 'libgcc',
 'libm.so.6': 'glibc',
 'libncurses.so.5': 'ncurses-libs',
 'libnspr4.so': 'nspr',
 'libnss3.so': 'nss',
 'libpam.so.0': 'pam',
 'libpthread.so.0': 'glibc',
 'librt.so.1': 'glibc',
 'libssl3.so': 'nss',
 'libutil.so.1': 'glibc',
 'libz.so.1': 'zlib'}

- 'libncurses.so.5': 'ncurses',
+ 'libncurses.so.5': 'ncurses-libs',


7:
{'libX11.so.6': 'libX11',
 'libc.so.6': 'glibc',
 'libcrypt.so.1': 'glibc',
 'libdl.so.2': 'glibc',
 'libgcc_s.so.1': 'libgcc',
 'libm.so.6': 'glibc',
 'libncurses.so.5': 'ncurses-libs',
 'libnspr4.so': 'nspr',
 'libnss3.so': 'nss',
 'libpam.so.0': 'pam',
 'libpthread.so.0': 'glibc',
 'librt.so.1': 'glibc',
 'libssl3.so': 'nss',
 'libutil.so.1': 'glibc',
 'libz.so.1': 'zlib'}

No diff.


SLES12
{'libX11.so.6': 'libX11-6',
 'libc.so.6': 'glibc',
 'libcrypt.so.1': 'glibc',
 'libdl.so.2': 'glibc',
 'libgcc_s.so.1': 'libgcc_s1',
 'libm.so.6': 'glibc',
 'libncurses.so.5': 'libncurses5',
 'libnspr4.so': 'mozilla-nspr',
 'libnss3.so': 'mozilla-nss',
 'libpam.so.0': 'pam',
 'libpthread.so.0': 'glibc',
 'librt.so.1': 'glibc',
 'libssl3.so': 'mozilla-nss',
 'libutil.so.1': 'glibc',
 'libz.so.1': 'libz1'}


Ubuntu
14.04:
{'libX11.so.6': 'libx11-6',
 'libc.so.6': 'libc6',
 'libcrypt.so.1': 'libc6',
 'libdl.so.2': 'libc6',
 'libgcc_s.so.1': 'libgcc1',
 'libm.so.6': 'libc6',
 'libncurses.so.5': 'libncurses5',
 'libnspr4.so': 'libnspr4',
 'libnss3.so': 'libnss3',
 'libpam.so.0': 'libpam0g',
 'libpthread.so.0': 'libc6',
 'librt.so.1': 'libc6',
 'libssl3.so': 'libnss3',
 'libutil.so.1': 'libc6',
 'libz.so.1': 'zlib1g'}


16.04:
{'libX11.so.6': 'libx11-6',
 'libc.so.6': 'libc6',
 'libcrypt.so.1': 'libc6',
 'libdl.so.2': 'libc6',
 'libgcc_s.so.1': 'libgcc1',
 'libm.so.6': 'libc6',
 'libncurses.so.5': 'libncurses5',
 'libnspr4.so': 'libnspr4',
 'libnss3.so': 'libnss3',
 'libpam.so.0': 'libpam0g',
 'libpthread.so.0': 'libc6',
 'librt.so.1': 'libc6',
 'libssl3.so': 'libnss3',
 'libutil.so.1': 'libc6',
 'libz.so.1': 'zlib1g'}

No diff.


Fedora 23:
{'libX11.so.6': 'libX11',
 'libc.so.6': 'glibc',
 'libcrypt.so.1': 'glibc',
 'libdl.so.2': 'glibc',
 'libgcc_s.so.1': 'libgcc',
 'libm.so.6': 'glibc',
 'libncurses.so.5': 'ncurses-libs',
 'libnspr4.so': 'nspr',
 'libnss3.so': 'nss',
 'libpam.so.0': 'pam',
 'libpthread.so.0': 'glibc',
 'librt.so.1': 'glibc',
 'libssl3.so': 'nss',
 'libutil.so.1': 'glibc',
 'libz.so.1': 'zlib'}
Comment 17 Peter Åstrand cendio 2016-08-31 08:57:20 CEST
(In reply to comment #16)

> 
> RHEL
> 5:
> {'libX11.so.6': 'libX11',
>  'libc.so.6': 'glibc',
>  'libcrypt.so.1': 'glibc',
>  'libdl.so.2': 'glibc',
>  'libgcc_s.so.1': 'libgcc',
>  'libm.so.6': 'glibc',
>  'libncurses.so.5': 'ncurses',
>  'libnspr4.so': 'nspr',
>  'libnss3.so': 'nss',
>  'libpam.so.0': 'pam',
>  'libpthread.so.0': 'glibc',
>  'librt.so.1': 'glibc',
>  'libssl3.so': 'nss',
>  'libutil.so.1': 'glibc',
>  'libz.so.1': 'zlib'}
> 
> 6:
> {'libX11.so.6': 'libX11',
>  'libc.so.6': 'glibc',
>  'libcrypt.so.1': 'glibc',
>  'libdl.so.2': 'glibc',
>  'libgcc_s.so.1': 'libgcc',
>  'libm.so.6': 'glibc',
>  'libncurses.so.5': 'ncurses-libs',
>  'libnspr4.so': 'nspr',
>  'libnss3.so': 'nss',
>  'libpam.so.0': 'pam',
>  'libpthread.so.0': 'glibc',
>  'librt.so.1': 'glibc',
>  'libssl3.so': 'nss',
>  'libutil.so.1': 'glibc',
>  'libz.so.1': 'zlib'}
> 
> - 'libncurses.so.5': 'ncurses',
> + 'libncurses.so.5': 'ncurses-libs',

If we want to support RHEL5, we need to handle this difference. The available ncurses packages (not including development/debug packages) on each version are:

5:
ncurses

6,7:
ncurses
ncurses-base
ncurses-libs
ncurses-static
ncurses-term

On 6,7, the ncurses package requires ncurses-libs. In other words, we should depend on the "ncurses" package, ie use the RHEL5 list.
Comment 20 Peter Åstrand cendio 2016-08-31 17:04:54 CEST
(In reply to comment #16)
> (In reply to comment #15)
> > Created an attachment (id=736) [details] [details]
> > libs-to-packages
> > 
> > The attached script generates a mapping between required libraries and the
> > package providing this library. Requires dpkg-query or rpm.
> 
> Results from running this script on different platforms:
> 
> 
> RHEL
> 5:
> {'libX11.so.6': 'libX11',
>  'libc.so.6': 'glibc',
>  'libcrypt.so.1': 'glibc',
>  'libdl.so.2': 'glibc',
>  'libgcc_s.so.1': 'libgcc',
>  'libm.so.6': 'glibc',
>  'libncurses.so.5': 'ncurses',
>  'libnspr4.so': 'nspr',
>  'libnss3.so': 'nss',
>  'libpam.so.0': 'pam',
>  'libpthread.so.0': 'glibc',
>  'librt.so.1': 'glibc',
>  'libssl3.so': 'nss',
>  'libutil.so.1': 'glibc',
>  'libz.so.1': 'zlib'}

Tested that these packages are sufficient for ThinLinc, using the various RHEL versions:

RHEL 5.10 Server Minimal
RHEL 6.5 Server Minimal
RHEL 7.0 Server Minimal

Version 5 worked fine. However, with 6 and 7 the welcome dialog was garbled due to some kind of font problem. On at least RHEL6, the problem goes away after installing the "lsb" package, which installs an additional 83 packages. In other words, the current list is not enough to get a ThinLinc system that works (good).
Comment 21 Karl Mikaelsson cendio 2016-09-01 12:43:50 CEST
See also: Bug 5974.
Comment 22 Peter Åstrand cendio 2016-09-06 14:27:36 CEST
(In reply to comment #20)

> RHEL 5.10 Server Minimal
> RHEL 6.5 Server Minimal
> RHEL 7.0 Server Minimal
> 
> Version 5 worked fine. However, with 6 and 7 the welcome dialog was garbled due
> to some kind of font problem. On at least RHEL6, the problem goes away after
> installing the "lsb" package, which installs an additional 83 packages. In
> other words, the current list is not enough to get a ThinLinc system that works
> (good).

Now investigated. The problem goes away if I'm installing either urw-fonts or xorg-x11-fonts-Type1. By installing lsb, the ghostscript package is also installed, which pulls in urw-fonts. Our options are:

1) do nothing

2) Directly install urw-fonts

3) Install urw-fonts by installing ghostscript - check for "gs" binary, which LSB requires

4) Install ghostscript by checking for libgs.so.9 or similar (not in LSB).

5) Directly install xorg-x11-fonts-Type1. 

6) Modify our PyGTK stuff to not require any additional fonts, perhaps by shipping a fallback font


My preference right now is option 3):

We need ghostscript anyway for a working printer support. As pointer our on comment #12, we could also get rid of our manual check for ps2pdf if we ship the ps2pdf wrapper ourselves instead.

One drawback though is that the LSB module currently has no support for checking LSB commands - only libs. 

Will check other distros before making a decision.
Comment 23 Peter Åstrand cendio 2016-09-07 15:35:02 CEST
(In reply to comment #22)
 7.0 Server Minimal
> > 
> > Version 5 worked fine. However, with 6 and 7 the welcome dialog was garbled due
> > to some kind of font problem. On at least RHEL6, the problem goes away after
> > installing the "lsb" package, which installs an additional 83 packages. In
> > other words, the current list is not enough to get a ThinLinc system that works
> > (good).
> 
> Now investigated. The problem goes away if I'm installing either urw-fonts or
> xorg-x11-fonts-Type1. By installing lsb, the ghostscript package is also
> installed, which pulls in urw-fonts. Our options are:
> 
> 1) do nothing
> 
> 2) Directly install urw-fonts
> 
> 3) Install urw-fonts by installing ghostscript - check for "gs" binary, which
> LSB requires
> 
> 4) Install ghostscript by checking for libgs.so.9 or similar (not in LSB).
> 
> 5) Directly install xorg-x11-fonts-Type1. 
> 
> 6) Modify our PyGTK stuff to not require any additional fonts, perhaps by
> shipping a fallback font
> 
> 
> My preference right now is option 3):
> 
> We need ghostscript anyway for a working printer support. As pointer our on
> comment #12, we could also get rid of our manual check for ps2pdf if we ship
> the ps2pdf wrapper ourselves instead.
> 
> One drawback though is that the LSB module currently has no support for
> checking LSB commands - only libs. 
> 
> Will check other distros before making a decision.

I've tested on minimal SLES12SP1 and Ubuntu 16.04 now. The font problem is not present on those. RHEL needs to be handled anyway though. My suggestion is to use solution 3):

Define the "gs" binary as an essential and required command. As earlier stated, it's in LSB. Patch essentials.py:

--- modules/thinlinc/tlsetup/essential.py       (revision 31673)
+++ modules/thinlinc/tlsetup/essential.py       (arbetskopia)
@@ -24,7 +24,7 @@
 essential_optional = False
 essential_title_msg = "Essential Commands"
 
-essential_commands = ["netstat", "pgrep", "xauth"]
+essential_commands = ["netstat", "pgrep", "xauth", "gs"]
 joined_commands = ", ".join(essential_commands[:-1]) + ", and " + essential_commands[-1]
 
 essential_base_msg = """ThinLinc requires a few essentials commands: \
@@ -61,6 +61,9 @@
         logging.warning("No information about which package provides xauth on this distribution")
         return None
 
+    # gs
+    backend.add_package_by_name("ghostscript")
+


Then, create a new bug for shipping ps2pdf ourselves and remove that check from printer.py; to be fixed later.
Comment 24 Pierre Ossman cendio 2016-09-08 15:09:30 CEST
ncurses is causing some more problems. Fedora is on libncurses.so.6, so libncurses.so.5 is in ncurses-compat-libs.
Comment 25 Pierre Ossman cendio 2016-09-09 11:12:32 CEST
The error message when packages cannot be installed automatically could be more helpful. Right now we dump the entire list of dependencies. However we know which libraries are missing, so we should limit the list to just those.
Comment 27 Peter Åstrand cendio 2016-09-12 10:43:00 CEST
(In reply to comment #24)
> ncurses is causing some more problems. Fedora is on libncurses.so.6, so
> libncurses.so.5 is in ncurses-compat-libs.

Fixed. 

(In reply to comment #25)
> The error message when packages cannot be installed automatically could be more
> helpful. Right now we dump the entire list of dependencies. However we know
> which libraries are missing, so we should limit the list to just those.

Not a new problem; this is how it works for essentials.py also. Not possible to implement due to bug 5985.
Comment 29 Peter Åstrand cendio 2016-09-12 14:15:49 CEST
I've tested r31698 (own build) on minimal installations of:

RHEL 5.10 (did setenfoce 0 after installation due to known bug)
RHEL 6
RHEL 7
Ubuntu 16.04
SLES12SP1

In installer/tl-setup, I've used the default option on every prompt. This resulted in a working ThinLinc installation on all platforms.
Comment 30 Henrik Andersson cendio 2016-09-13 15:33:29 CEST
Installation of postfix "hangs" package installation for ~5 minutes on debian based system, seen on both elementary and ubuntu server.
Comment 32 Henrik Andersson cendio 2016-09-14 13:42:20 CEST
Tested lsb installation for following distributions:

  - debian 8
  - fedora server 24
  - ubuntu server 16.04
  - centos 6.8 minimal
  - elementary os - loki

where those above distributions without graphical console (Xorg), required xlibs / xauth are installed. When installing additional xterm and enabled xterm profile in ThinLinc configuration, a session was created successfully.

debian based distributions which didn't have postfix installed suffered from the interactive installation problem. which will be retested with fix in comment #31.
Comment 34 Henrik Andersson cendio 2016-09-14 17:01:01 CEST
Works as expected.
Comment 35 Karl Mikaelsson cendio 2016-09-16 09:42:15 CEST
tl-setup wants to install postfix even though I have a sendmail in PATH on Fedora 24.

> $ which sendmail
> /usr/sbin/sendmail
Comment 36 Pierre Ossman cendio 2016-09-19 10:48:40 CEST
The current code doesn't look like it will do the correct thing if DISTRIBUTION_FAMILY is set to something unknown. I think we need to have a different layout for the data structures.
Comment 41 Pierre Ossman cendio 2016-09-19 14:53:22 CEST
Should be fixed now. Tester needs to make sure that virtual packages are handled properly. I.e. test both when no package is installed, and when a non-default one is installed (by default we mean the one tl-setup would pick).
Comment 42 Peter Åstrand cendio 2016-09-20 11:17:55 CEST
*** Bug 5994 has been marked as a duplicate of this bug. ***
Comment 45 Samuel Mannehed cendio 2016-09-23 13:12:50 CEST
We have decided to test tl-setup on the following platforms:

* RHEL5
* RHEL7
* Ubuntu 16.04-desktop
* Debian 8
* SLES11 sp3
* SLES12 sp1
* Fedora 24
* One other distribution which falls outside of our "distribution families", for example Gentoo
Comment 46 Samuel Mannehed cendio 2016-09-26 13:31:11 CEST
Successfully tested on:

✓ RHEL5
✓ RHEL7 server
✓ RHEL7 server minimal
✓ Ubuntu 16.04-desktop
Comment 47 Henrik Andersson cendio 2016-09-26 14:07:10 CEST
Verified LSB step installation on SLES11 sp2 and SLES12 sp1, works as expected.
Comment 50 Henrik Andersson cendio 2016-09-26 16:05:59 CEST
(In reply to comment #47)
> Verified LSB step installation on SLES11 sp2 and SLES12 sp1, works as expected.

Also verified on debian 8
Comment 51 Samuel Mannehed cendio 2016-09-26 16:11:18 CEST
Works on Fedora 24 server as well. I have to add though that you have to manually install:

> dnf install libutil.so.1 libncurses.so.5 libnspr4.so libpam.so.0 libnss3.so libssl3.so librt.so.1 libz.so.1 libgcc_s.so.1 libcrypt.so.1 libpthread.so.0 libdl.so.2 libm.so.6 libX11.so.6 libc.so.6 net-tools /usr/sbin/sendmail procps ghostscript xauth 
> dnf install pygtk2 pygtk2-libglade.x86_64 selinux-policy-devel.noarch

The list provided by tl-setup says netstat, gs, and pgrep, while the package names in Fedora is net-tools, ghostscript and procps. However, from my understanding, we can't know the package names in tl-setup here.

Closing.
Comment 52 Samuel Mannehed cendio 2016-09-29 11:25:28 CEST
Ran into a problem with tl-setup on tl-4.7.0 build 5248 on a fully updated Fedora 24:

/var/log/tlsetup.log:

> 2016-09-29 11:06:20,916: Resolving packages...
> 2016-09-29 11:06:23,610: resolving package 'libncurses.so.5()(64bit)' for installation.
> 2016-09-29 11:06:24,674: package 'libncurses.so.5()(64bit)' provides package 'ncurses-compat-libs'
> 2016-09-29 11:06:24,956: package 'ncurses-compat-libs-6.0-5.20160116.fc24.x86_64' flagged for installation
> 2016-09-29 11:06:26,532: Packages to install:
> 2016-09-29 11:06:26,532:  - ncurses-compat-libs-6.0.x86_64
> 2016-09-29 11:06:28,245: Running Transaction Check
> 2016-09-29 11:06:28,254:   failed to install packages with reason: [u'ERROR with transaction check vs depsolve:', 'ncurses-base = 6.0-5.20160116.fc24 is needed by ncurses-compat-libs-6.0-5.20160116.fc24.x86_64']
> 2016-09-29 11:06:47,352: tl-setup aborted by user

> $ rpm -q ncurses-base
> ncurses-base-6.0-6.20160709.fc24.noarch



tl-setup tries to install an old version of ncurses-compat-libs that fails because it has dependencies on an older ncurses-base. tl-setup should install the newest version.
Comment 53 Pierre Ossman cendio 2016-09-29 13:35:14 CEST
(In reply to comment #52)
> Ran into a problem with tl-setup on tl-4.7.0 build 5248 on a fully updated
> Fedora 24:
> 
> /var/log/tlsetup.log:
> 
> > 2016-09-29 11:06:20,916: Resolving packages...

Fedora 24 uses DNF, which we don't support, so how did you manage this?
Comment 55 Pierre Ossman cendio 2016-09-29 14:04:41 CEST
(In reply to comment #53)
> (In reply to comment #52)
> > Ran into a problem with tl-setup on tl-4.7.0 build 5248 on a fully updated
> > Fedora 24:
> > 
> > /var/log/tlsetup.log:
> > 
> > > 2016-09-29 11:06:20,916: Resolving packages...
> 
> Fedora 24 uses DNF, which we don't support, so how did you manage this?

By doing "dnf install yum" apparently.
Comment 57 Samuel Mannehed cendio 2016-10-03 14:17:36 CEST
(In reply to comment #52)
> tl-setup tries to install an old version of ncurses-compat-libs that fails
> because it has dependencies on an older ncurses-base. tl-setup should install
> the newest version.

Verified that the bug exist on 4.7.0beta1 and that it is fixed in build 5252. tl-setup works great now.

Note You need to log in before you can comment on or make changes to this bug.