Fails to run "tlmgr" - Githubissues

mouse07410 commented 4 months ago

Erroneous Behavior

── 21:26:47 - TeX Live package manager ─────────────────────────────────────────
Credentials Required: Before using this Sudo Command, you must first enter your credentials below.
PIN:        
Can't locate TeXLive/TLConfig.pm in @INC (you may need to install the TeXLive::TLConfig module) (@INC contains: /usr/local/texlive/2024/texmf-dist/scripts/texlive/../../texmf-dist/scripts/texlive /usr/local/texlive/2024/texmf-dist/scripts/texlive/../../tlpkg /opt/local/lib/perl5/site_perl/5.34/darwin-thread-multi-2level /opt/local/lib/perl5/site_perl/5.34 /opt/local/lib/perl5/vendor_perl/5.34/darwin-thread-multi-2level /opt/local/lib/perl5/vendor_perl/5.34 /opt/local/lib/perl5/5.34/darwin-thread-multi-2level /opt/local/lib/perl5/5.34) at /usr/local/texlive/2024/texmf-dist/scripts/texlive/tlmgr.pl line 92.
BEGIN failed--compilation aborted at /usr/local/texlive/2024/texmf-dist/scripts/texlive/tlmgr.pl line 92.
tlmgr failed: 
   0: Command failed: `/usr/bin/sudo /Library/TeX/texbin/tlmgr update --self --all`
   1: `/usr/bin/sudo` failed: exit status: 2

Location:
   /Users/ur20980/.cargo/registry/src/index.crates.io-6f17d22bba15001f/topgrade-15.0.0/src/steps/generic.rs:661

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                ⋮ 2 frames hidden ⋮                               
   3: <E as eyre::context::ext::StdError>::ext_report::h4b9c08eedce2c5d4
      at <unknown source file>:<unknown line>
   4: <topgrade::executor::Executor as topgrade::command::CommandExt>::status_checked_with::h16fbce4fc064cd64
      at <unknown source file>:<unknown line>
   5: topgrade::runner::Runner::execute::h87dcc7f11e67e85e
      at <unknown source file>:<unknown line>
   6: topgrade::run::h3aaace4dc21b37ae
      at <unknown source file>:<unknown line>
   7: topgrade::main::hb379565bea8b4bbb
      at <unknown source file>:<unknown line>
   8: std::sys_common::backtrace::__rust_begin_short_backtrace::h55f9edf509b19736
      at <unknown source file>:<unknown line>
   9: _main<unknown>
      at <unknown source file>:<unknown line>
Retry? (y)es/(N)o/(s)hell/(q)uit

Expected Behavior

$ sudo -EH tlmgr update --self --all 
Credentials Required: Before using this Sudo Command, you must first enter your credentials below.
PIN:        
tlmgr: package repository https://mirrors.mit.edu/CTAN/systems/texlive/tlnet (verified)
tlmgr: saving backups to /usr/local/texlive/2024/tlpkg/backups
tlmgr: no self-updates for tlmgr available
tlmgr: skipping forcibly removed package: arara
tlmgr: skipping forcibly removed package: arara.universal-darwin
[1/9, ??:??/??:??] update: cjs-rcs-article [450k] (69006 -> 71799) ... done
[2/9, 00:03/01:09] update: latexindent [1393k] (71532 -> 71804) ... done
[3/9, 00:04/00:22] update: luamplib [297k] (71745 -> 71801) ... done
[4/9, 00:06/00:29] update: luatexja [3435k] (71306 -> 71802) ... done
[5/9, 00:09/00:16] update: luaxml [173k] (70112 -> 71803) ... done
[6/9, 00:10/00:18] update: markdown [1450k] (71572 -> 71798) ... done
[7/9, 00:13/00:18] update: responsive [85k] (69147 -> 71800) ... done
[8/9, 00:15/00:21] update: texlive-scripts [539k] (71794 -> 71806) ... done
[9/9, 00:17/00:22] update: tkz-grapheur [2540k] (71590 -> 71805) ... done
running mktexlsr ...
done running mktexlsr.
running updmap-sys ...
done running updmap-sys.
tlmgr: package log updated: /usr/local/texlive/2024/texmf-var/web2c/tlmgr.log
tlmgr: command log updated: /usr/local/texlive/2024/texmf-var/web2c/tlmgr-commands.log
$

Steps to reproduce

A bit hard, as this system is now running Privileged Access Module (doesn't just allow sudo based on /etc/sudoers file).

Possible Cause (Optional)

Two problems/differences between successful and unsuccessful invocations that I see is that the successful one (which I ran standalone, not via topgrade) did not specify the full path for the apps.

Can you make an option to not specify full path? I think I understand the implications.

Problem persists without calling from topgrade

[ ] Yes
[X] No

Did you run topgrade through `Remote Execution`

[ ] Yes
[X] No

I don't even know what that means.

Configuration file (Optional)

[misc]
# Don't ask for confirmations
#assume_yes = true

# Disable specific steps - same options as the command line flag
#disable = ["system", "emacs"]
disable = ["system", "node", "containers", "bin", "vcpkg", "firmware"]

# Ignore failures for these steps
#ignore_failures = ["powershell"]

# Don't display preamble message about possible hang-ups
#display_preamble = false

# Don't send notification at the end to avoid hangup
#skip_notify = true

# Run specific steps - same options as the command line flag
#only = ["system", "emacs"]

# Do not ask to retry failed steps (default: false)
#no_retry = true

# Run inside tmux
#run_in_tmux = true

# Run `sudo -v` to cache credentials at the start of the run; this avoids a
# blocking password prompt in the middle of a possibly-unattended run.
#pre_sudo = false

# List of remote machines with Topgrade installed on them
#remote_topgrades = ["toothless", "pi", "parnas"]

# Arguments to pass SSH when upgrading remote systems
#ssh_arguments = "-o ConnectTimeout=2"

# Path to Topgrade executable on remote machines
#remote_topgrade_path = ".cargo/bin/topgrade"

# Arguments to pass tmux when pulling Repositories
#tmux_arguments = "-S /var/tmux.sock"

# Do not set the terminal title
#set_title = false

# Display the time in step titles
# display_time = true

# Cleanup temporary or old files
#cleanup = true

[git]
#max_concurrency = 5
# Additional git repositories to pull
#repos = [
#    "~/src/*/",
#    "~/.config/something"
#]

# Don't pull the predefined git repos
#pull_predefined = false

# Arguments to pass Git when pulling Repositories
#arguments = "--rebase --autostash"

[composer]
#self_update = true

# Commands to run before anything
[pre_commands]
#"Emacs Snapshot" = "rm -rf ~/.emacs.d/elpa.bak && cp -rl ~/.emacs.d/elpa ~/.emacs.d/elpa.bak"

# Custom commands
[commands]
#"Python Environment" = "~/dev/.env/bin/pip install -i https://pypi.python.org/simple -U --upgrade-strategy eager jupyter"
"Haskell" = "stack update && cabal update && hoogle generate"

[brew]
#greedy_cask = true

[linux]
# Arch Package Manager to use. Allowed values: autodetect, trizen, paru, yay, pikaur, pacman.
#arch_package_manager = "pacman"
# Arguments to pass yay (or paru) when updating packages
#yay_arguments = "--nodevel"
#show_arch_news = true
#trizen_arguments = "--devel"
#pikaur_arguments = ""
enable_tlmgr = true
#emerge_sync_flags = "-q"
#emerge_update_flags = "-uDNa --with-bdeps=y world"
#redhat_distro_sync = false
#rpm_ostree = false

[windows]
# Manually select Windows updates
#accept_all_updates = false
#open_remotes_in_new_terminal = true

# Causes Topgrade to rename itself during the run to allow package managers
# to upgrade it. Use this only if you installed Topgrade by using a package
# manager such as Scoop to Cargo
#self_rename = true

[npm]
# Use sudo if the NPM directory isn't owned by the current user
#use_sudo = true

[firmware]
# Offer to update firmware; if false just check for and display available updates
upgrade = false

[flatpak]
# Use sudo for updating the system-wide installation
#use_sudo = true

Additional Details

Operation System/Version: MacOS Sonoma 14.5 with Xcode-15.4 and stable Rust-1.79.
Installation: via cargo install topgrade
Topgrade version: Topgrade 15.0.0

Verbose Output (`topgrade -v`)

Too verbose to paste (unless you want to go through a 3704 lines in a post), so here it is: topgr.out.txt

mouse07410 commented 1 month ago

Any progress, workaround, or feedback?

SteveLauC commented 1 month ago

Hi, sorry for the late reply!

Two problems/differences between successful and unsuccessful invocations that I see is that the successful one (which I ran standalone, not via topgrade) did not specify the full path for the apps.

Topgrade does not specify the full path, it always searches commands in $PATH.

What will happen if you simply do:

$ sudo tlmgr update --self --all

Does it also error out?

I saw that with the successful one, you were using sudo -EH, why did you do this? I am aware that the sudo on many Linux distros will modify $PATH, but for macOS, this does not seem to be true from my test(I am on macOS 13, Sudo version 1.9.5p2).

Also, can you do:

$ which tlmgr
$ sudo zsh # replace zsh with your shell
$ which tlmgr

mouse07410 commented 3 weeks ago

What will happen if you simply do:
$ sudo tlmgr update --self --all
Does it also error out?

No it doesn't - works correctly.

I saw that with the successful one, you were using sudo -EH, why did you do this?

To ensure the local env vars are set properly (as per my user profile, rather than root).

for macOS, this does not seem to be true from my test(I am on macOS 13, Sudo version 1.9.5p2).

Don't know what to tell you - my Macs are on macOS 14 and 15, and -EH works as expected (i.e., works - as opposed to being silently ignored).

SteveLauC commented 2 weeks ago

No it doesn't - works correctly.

Ok then, -EH is not needed.

Don't know what to tell you

I was trying to figure out if -EH is needed.

SteveLauC commented 2 weeks ago

Same as #903, I need a way to check if sudo is needed.

mouse07410 commented 2 weeks ago

No it doesn't - works correctly.

Ok then, -EH is not needed.

Don't know what to tell you

I was trying to figure out if -EH is needed.

I think it is needed - but it's been quite a while ago, so I don't recall all the details. One thing for sure - sudo is needed.

mouse07410 commented 2 weeks ago

Same as #903, I need a way to check if sudo is needed.

In some cases it may not be needed. In my car it is necessary. The best would be showing the user to tell topgrade whether to employ sudo here or not.

SteveLauC commented 2 weeks ago

I just recalled that there are some 'use_sudo' confug entries in Topgrade that allows you to opt-in to sudo, maybe we can use this if it is just tedious and complicated to check if sudo is necessary.

mouse07410 commented 2 weeks ago

That sounds good. My only other concern is that use_sudo seems to be "global" rather than on per-command basis. I.e., I can't tell topgrade to use it for poetry but not for cargo. IMHO, we need that option selected individually for several, off but for all.

Also, in another comment you mentioned Windows. Sorry, I've no clue about Win - only MacOS and Linux.

SteveLauC commented 2 weeks ago

My only other concern is that use_sudo seems to be "global"

The existing use_sudos are per-step config entries, so no need to worry about this.

mouse07410 commented 2 weeks ago

I don't seem to recall how to add use_sudo to individual steps. And in the actual code that invokes, e.g., tlmgr, I did not see anything resembling sudo - which is why I added my patch.

Could you please show how to add use_sudoto a step? And whether they're a way to tell to use -EH or not?

SteveLauC commented 2 weeks ago

I guess you are talking about pre_sudo, which is indeed a global one. For pre-step configuration, check out this example: https://github.com/topgrade-rs/topgrade/blob/main/src%2Fsteps%2Fnode.rs#L95

topgrade-rs / topgrade

Fails to run "tlmgr" #865

Erroneous Behavior

Expected Behavior

Steps to reproduce

Possible Cause (Optional)

Problem persists without calling from topgrade

Did you run topgrade through `Remote Execution`

Configuration file (Optional)

Additional Details

Verbose Output (`topgrade -v`)

topgrade-rs / topgrade

Fails to run "tlmgr" #865

Erroneous Behavior

Expected Behavior

Steps to reproduce

Possible Cause (Optional)

Problem persists without calling from topgrade

Did you run topgrade through Remote Execution

Configuration file (Optional)

Additional Details

Verbose Output (topgrade -v)

Did you run topgrade through `Remote Execution`

Verbose Output (`topgrade -v`)