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")
Debian discussion thread: https://lists.debian.org/debian-lsb/2015/07/msg00000.html
https://lwn.net/Articles/658809/
See also Bug 5405. I guess we need to do the same for Debian/Ubuntu?
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?
(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.
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.
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
(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.
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"]
Created attachment 735 [details] check_lsb_4.1.py New script to check for LSB 4.1 libs (Combined Core list plus libX11).
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.
(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'}
(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.
(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).
See also: Bug 5974.
(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.
(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.
ncurses is causing some more problems. Fedora is on libncurses.so.6, so libncurses.so.5 is in ncurses-compat-libs.
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.
(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.
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.
Installation of postfix "hangs" package installation for ~5 minutes on debian based system, seen on both elementary and ubuntu server.
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.
Works as expected.
tl-setup wants to install postfix even though I have a sendmail in PATH on Fedora 24. > $ which sendmail > /usr/sbin/sendmail
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.
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).
*** Bug 5994 has been marked as a duplicate of this bug. ***
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
Successfully tested on: ✓ RHEL5 ✓ RHEL7 server ✓ RHEL7 server minimal ✓ Ubuntu 16.04-desktop
Verified LSB step installation on SLES11 sp2 and SLES12 sp1, works as expected.
(In reply to comment #47) > Verified LSB step installation on SLES11 sp2 and SLES12 sp1, works as expected. Also verified on debian 8
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.
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.
(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?
(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.
(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.
