-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
update README.md to indicate which texlive gets installed? #39
Comments
You're right, it would be nice to have this info on README.md. Does the following output from
|
close to, although it would be nice if the |
That's a good idea. Let's leave this issue open as a reminder to do that whenever I work on this again. |
Taking a ride on the thread: Could it be possible to have the version of TeX Live effectively installed in the deb package created? Right now on my Ubuntu 20.04 the package manager says "A full "vanilla" TeX Live 2016" whereas the report from install-tl-ubuntu and versions from /opt/texbin are positive about being 2022! |
Welcome!
Just to make sure I understand, what command do you run that shows 2016? If you are using a GUI, can you post a screenshot? |
Here's a screenshot: This the result of an inquiry in my recent installation:
Also, if I issue:
My understanding of the line : This situation may arise as the 22.04 upgrade be installed. IIUC Canonical decided to do a match of package versions to their distributions and for Focal Fossa no upgrades for TeX Live 2016 are being offered. As a further argument please see this result:
|
Thanks for that info!
I don't think |
I agree about the "fake" part, and think the idea is to have a documentation the least in need of "interpretation". If we find automating this too complicated (sometimes the knitting of sed, awk, etc., may not bring ROI for the effort) we can have the string changed to "to check your TeX Live version issue 'tex --version' in the command line". HTH & pls accept my kudos for this nice script and giving it to the community! |
+1
Good idea! I embarrassingly didn't even think of that alternative.
It's quite hackish by nature ("tricking" Ubuntu's package manager) but strangely has held up pretty well. I still have no idea when I will make another round of changes and comprehensive tests for this repository. But I think I have enough information logged here that whenever I get to it I'll know what to do. |
I see. If no reason happens to me avoid it, in the next months my 20.04 will be offered to 'upgrade' to 22.04. If by that time you came with some thing, I can check "test" Probably the updater will get stuck but let's see what will happen. Regards. |
Thanks for the offer! I prefer to test on "virtual machines" so that way if anything goes wrong, it doesn't cause any problems. |
Might be useful to have a minimal docker file that bootstraps a slim ubuntu with your script. |
@Pomax I think that would be useful. And it would be faster for testing things. I've previously only relied on virtual boxes. Do you by chance have the time and interest to set one up? I have not used docker before. |
putting one together for you right now. |
Looks like the need for |
These are not needed and cause problems with a docker file [1]. [1] #39 (comment)
@Pomax Ah dang. I've been wanting to change the script to limit sudo for a while to only the parts where it's needed. Ideally we would do a user installation so that sudo isn't even needed for the TeX Live installation. We would still need it for apt-get stuff, but it would be nice to limit it to that. It seems this is coming back to bite. Indeed, I don't think sudo has any effect in the following two lines:
From what I understand, we can just remove those without changing anything else. I just pushed this change at 6bda341. If the sudo in the BAD_VARS check is causing problems, perhaps we could do that check conditionally (e.g., on an environment variable). Would that help? That's not ideal but not sure how else to fix it without invasive changes. Any other |
Hiya, got pulled away for a few days, picking this back up =) |
That leaves the |
So I'm seeing some interesting wget fails while trying to run the docker file now: #9 0.903 install-tl-ubuntu: running apt and dpkg commands...
#9 199.7 install-tl-ubuntu: determining the fastest repository...
#9 202.7 install-tl-ubuntu: trying automatic detection with a longer timeout and smaller file...
#9 202.8 install-tl-ubuntu: WARNING: automatic repo detection failed. We will use the default repo:
#9 202.8 http://mirror.utexas.edu/ctan/
#9 202.8 install-tl-ubuntu: downloading and extracting install-tl for time number 1...
#9 202.9 install-tl-ubuntu: WARNING: wget failed
#9 202.9 tar: This does not look like a tar archive Which makes sense: if I try to load http://mirror.utexas.edu/ctan/ in the browser that's a hard nope. |
Please bear with me as it may look anal retentive, but I think that the installations scripts if they fail to find a mirror should always be directed to CTAN main repo. My 0.019999.... |
That does seem logical, but I remember reading a plea from someone knowledgeable that we don't use that repository and really try to use a mirror. If you ask CTAN for permission to use the main repo as the default and forward their response to me, I'll be happy to do that since indeed it is probably the most robust. |
The previous one does not seem to be valid anymore, at least not for the past week. Thanks to @Pomax [1]. [1] #39 (comment)
Thanks for reporting this. It still doesn't work. It's also not listed in the CTAN mirrors anymore. I changed this fallback at c306305. However, I wonder why the automatic detection failed. |
@Pomax Would it be sufficient if I put in an argument (e.g., --no-safety-checks) that would skip that part of the code? |
that would certainly be enough to see if we can get docker to complete a run! |
Sounds good, I'll do that next week. Sorry for my slow responses and fixes. Thanks for sticking with me on this! |
No worries, unless someone pays you to do the work, your time is your always your own ;) |
By using this new option, the 'sudo -u' call is not used. This is a step towards trying to get docker working. See: #39 (comment)
By using this new option, the 'sudo -u' call is not used. This is a step towards trying to get docker working. See: #39 (comment)
@Pomax sorry again it took me so long. No problem if you don't have time anymore to take a look. I just pushed a branch called "docker" where I made the commit. Now if you use the option "--no-safety-checks", the "sudo -u" will not be used. |
I need the base
texlive
andtexlive-xetex
for a github action, which definitely should not install the 5GBtexlive-full
, so: is that possible? The README.md does not indicate which version of texlive gets installed, making it impossible to tell whether additional components need to be installed withtlmgr
or not, and whether this script is even a viable option (because if it can only grabtexlive-full
that makes it unsuitable for github actions)The text was updated successfully, but these errors were encountered: