| View previous topic :: View next topic |
| Author |
Message |
TADAitsnick
n00b
Joined: 03 Jan 2025
Posts: 10
Location: Indiana, USA
|
 Posted: Fri Jan 03, 2025 6:11 am Post subject: dev-lang/julia freezing on emerge |
 |
|
Hello everyone. New to gentoo and loving it so far. This is my first post.
I am studying computational physics and I'm familiar with C++ and Fortran but I've just recently learned about Julia. I thought that it would be a good idea to give it a try and see just how useful it can be in my career later on or in grad school.
Unfortunately, I'm having issues emerging dev-lang/julia-1.8.5-r1. The dependencies were emerged successfully and the build seemed to be going fine, although it took a very long time. Since it took so long to build, I let it run while I was sleeping and I'm not sure what happened, but it was frozen on this message when I woke up:
| Code: | | Generating REPL precompile statements... 25/40 |
I thought that my cat had just stepped on my laptop while I was sleeping, so I tried again several times. It always stops at 25/40 and stays there for hours. Last time I tried, I let it run for 18 hours uninterrupted.
I saw this bug. The solution for that different version of julia was to kill busybox and I have no such process running, nor do I even think I have it installed. Also, that issue was supposed to be resolved.
To emphasize, I have never installed julia before. I prefer to install things through portage as I really like it so far but I do have a directory of other apps that I have cloned from git such as 'st'. I believe I have plenty of RAM/SWAP to handle this task to get ahead of that question as you can see in 'emerge --info' below. I have also compressed build.log to upload it, but there isn't a way to upload files to forums? Only for bugs? I would be happy to provide that, as well, if anyone can point me towards the right way to include it here. I did not make a post in bugs.gentoo.org because I am not sure that this is a bug and not user error of some kind.
Any help would be greatly appreciated!
| Code: | | emerge --info dev-lang/julia |
| Code: | ortage 3.0.66.1 (python 3.12.8-final-0, default/linux/amd64/23.0/hardened, gcc-14, glibc-2.40-r7, 6.12.3-gentoo x86_64)
=================================================================
System Settings
=================================================================
System uname: Linux-6.12.3-gentoo-x86_64-Intel-R-_Core-TM-_i7-6600U_CPU_@_2.60GHz-with-glibc2.40
KiB Mem: 16253936 total, 6371496 free
KiB Swap: 22020092 total, 22020092 free
Timestamp of repository gentoo: Mon, 30 Dec 2024 07:00:00 +0000
Head commit of repository gentoo: 174d902ba36ac55e0860bdd2620a5be24462380e
Timestamp of repository guru: Sun, 29 Dec 2024 18:03:14 +0000
Head commit of repository guru: 76952bd4abea2a7f305b9012f9a8599fcb6deee1
Timestamp of repository x11: Tue, 17 Dec 2024 22:21:06 +0000
Head commit of repository x11: 65e5ca74f923881451af9f311333b77691446b4b
sh bash 5.2_p37
ld GNU ld (Gentoo 2.43 p3) 2.43.1
app-misc/pax-utils: 1.3.8::gentoo
app-shells/bash: 5.2_p37::gentoo
dev-build/autoconf: 2.72-r1::gentoo
dev-build/automake: 1.17-r1::gentoo
dev-build/cmake: 3.31.3::gentoo
dev-build/libtool: 2.5.4::gentoo
dev-build/make: 4.4.1-r100::gentoo
dev-build/meson: 1.6.1::gentoo
dev-java/java-config: 2.3.4::gentoo
dev-lang/perl: 5.40.0-r1::gentoo
dev-lang/python: 3.10.16_p1::gentoo, 3.12.8::gentoo, 3.13.1::gentoo
dev-lang/rust-bin: 1.83.0::gentoo
llvm-core/clang: 18.1.8-r6::gentoo, 19.1.6::gentoo
llvm-core/llvm: 18.1.8-r6::gentoo, 19.1.6::gentoo
sys-apps/baselayout: 2.17::gentoo
sys-apps/openrc: 0.55.1::gentoo
sys-apps/sandbox: 2.42::gentoo
sys-devel/binutils: 2.43-r2::gentoo
sys-devel/binutils-config: 5.5.2::gentoo
sys-devel/gcc: 14.2.1_p20241221::gentoo
sys-devel/gcc-config: 2.12.1::gentoo
sys-kernel/linux-headers: 6.12::gentoo (virtual/os-headers)
sys-libs/glibc: 2.40-r7::gentoo
Repositories:
gentoo
location: /var/db/repos/gentoo
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
volatile: False
sync-rsync-extra-opts:
sync-rsync-verify-metamanifest: yes
sync-rsync-verify-max-age: 3
sync-rsync-verify-jobs: 1
guru
location: /var/db/repos/guru
sync-type: git
sync-uri: https://github.com/gentoo-mirror/guru.git
masters: gentoo
volatile: False
x11
location: /var/db/repos/x11
sync-type: git
sync-uri: https://github.com/gentoo-mirror/x11.git
masters: gentoo
volatile: False
Binary Repositories:
gentoobinhost
priority: 1
sync-uri: https://distfiles.gentoo.org/releases/amd64/binpackages/23.0/x86-64_hardened
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=skylake -O2 -pipe -fno-semantic-interposition"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d"
CXXFLAGS="-march=skylake -O2 -pipe -fno-semantic-interposition"
DISTDIR="/var/cache/distfiles"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME"
FCFLAGS="-march=skylake -O2 -pipe -fno-semantic-interposition"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync merge-wait multilib-strict network-sandbox news parallel-fetch pid-sandbox pkgdir-index-trusted preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-march=skylake -O2 -pipe -fno-semantic-interposition"
GENTOO_MIRRORS="http://www.gtlib.gatech.edu/pub/gentoo https://mirrors.mit.edu/gentoo-distfiles/ https://gentoo.osuosl.org/ https://mirrors.rit.edu/gentoo/ http://gentoo-mirror.flux.utah.edu/"
LANG="C.UTF8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs"
LEX="flex"
MAKEOPTS="-j4"
PKGDIR="/var/cache/binpkgs"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
SHELL="/bin/bash"
USE="X acl alsa amd64 bzip2 cet crypt cxx debug elogind fortran gdbm hardened iconv ipv6 jpeg lapack libtirpc man multilib native-extensions ncurses nls opengl openmp pam pcre pdf pic pie pulseaudio python readline seccomp ssl ssp test-rust unicode vim wifi xattr xscreensaver xtpax zlib" ABI_X86="64 32" ADA_TARGET="gcc_13" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_anon authn_dbm authn_file authz_dbm authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir env expires ext_filter file_cache filter headers include info log_config logio mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2 aes avx avx2 f16c fma3 pclmul popcnt rdrand sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax navcom oceanserver oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 tsip tripmate tnt ublox" GRUB_PLATFORMS="efi-64" GUILE_SINGLE_TARGET="3-0" GUILE_TARGETS="3-0" INPUT_DEVICES="libinput synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz glk hd44780 lb216 lcdm001 mtxorb text" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php8-2" POSTGRES_TARGETS="postgres16" PYTHON_SINGLE_TARGET="python3_12" PYTHON_TARGETS="python3_12 python3_10" RUBY_TARGETS="ruby32" VIDEO_CARDS="intel" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipp2p iface geoip fuzzy condition tarpit sysrq proto logmark ipmark dhcpmac delude chaos account"
Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PYTHONPATH, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS
|
Last edited by TADAitsnick on Sun Jan 05, 2025 4:29 pm; edited 2 times in total |
|
| Back to top |
|
 |
Banana
Moderator
Joined: 21 May 2004
Posts: 1825
Location: Germany
|
|
| Back to top |
|
|
TADAitsnick
n00b
Joined: 03 Jan 2025
Posts: 10
Location: Indiana, USA
|
| Posted: Fri Jan 03, 2025 11:20 am Post subject: |
|
|
That's a useful package. Thanks.
Here is my build.log. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2067
|
| Posted: Fri Jan 03, 2025 11:21 am Post subject: |
|
|
| Could you show us ps faux output when it's been stuck for a little bit? |
|
| Back to top |
|
|
TADAitsnick
n00b
Joined: 03 Jan 2025
Posts: 10
Location: Indiana, USA
|
| Posted: Fri Jan 03, 2025 1:51 pm Post subject: |
|
|
| sam_ wrote: | | Could you show us ps faux output when it's been stuck for a little bit? |
Sure. Here you go. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2067
|
| Posted: Fri Jan 03, 2025 1:59 pm Post subject: |
|
|
OK, nothing obvious.
Try: a) dropping -fno-semantic-interposition from *FLAGS, or b) dropping -march as well. Of course, that's just a workaround, but let's try it.
If that doesn't help (or even if it does), please attach gdb to 2486 (or the equivalent on another run) and get a backtrace. |
|
| Back to top |
|
|
TADAitsnick
n00b
Joined: 03 Jan 2025
Posts: 10
Location: Indiana, USA
|
| Posted: Fri Jan 03, 2025 2:02 pm Post subject: |
|
|
| sam_ wrote: |
Try: a) dropping -fno-semantic-interposition from *FLAGS, or b) dropping -march as well. |
Either of these options would require a full rebuild of my system would they not? And they aren't guaranteed solutions. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2067
|
| Posted: Fri Jan 03, 2025 2:11 pm Post subject: |
|
|
| TADAitsnick wrote: | | sam_ wrote: |
Try: a) dropping -fno-semantic-interposition from *FLAGS, or b) dropping -march as well. |
Either of these options would require a full rebuild of my system would they not? And they aren't guaranteed solutions. |
No, I was suggesting just dropping them for julia (either by temporarily modifying make.conf or using a package.env just for julia). |
|
| Back to top |
|
|
Banana
Moderator
Joined: 21 May 2004
Posts: 1825
Location: Germany
|
|
| Back to top |
|
|
TADAitsnick
n00b
Joined: 03 Jan 2025
Posts: 10
Location: Indiana, USA
|
| Posted: Fri Jan 03, 2025 9:40 pm Post subject: |
|
|
| sam_ wrote: |
No, I was suggesting just dropping them for julia (either by temporarily modifying make.conf or using a package.env just for julia). |
Oh yes that was pretty silly of me. I temporarily changed make.conf to try both of those. I get the exact same behavior. I suppose it's looking more likely that it is a bug than something I did wrong? |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2067
|
| Posted: Fri Jan 03, 2025 11:15 pm Post subject: |
|
|
| Yeah, I think so. Can you grab a backtrace? |
|
| Back to top |
|
|
TADAitsnick
n00b
Joined: 03 Jan 2025
Posts: 10
Location: Indiana, USA
|
|
| Back to top |
|
|
TADAitsnick
n00b
Joined: 03 Jan 2025
Posts: 10
Location: Indiana, USA
|
| Posted: Sun Jan 05, 2025 4:45 am Post subject: |
|
|
Okay, so here's an update. I'm marking this as solved. I have not fixed the issue with emerging the gentoo package for julia.
I worked on trying to get a backtrace for a while but I have not been able to. Instead, I went to the julia github page.
Note that it says this in the readme:
| Code: | | Note: Although some OS package managers provide Julia, such installations are neither maintained nor endorsed by the Julia project. They may be outdated, broken and/or unmaintained. We recommend you use the official Julia binaries instead. |
Indeed, it seems like the julia package in dev-lang is an older version: v1.8.5
The most recent stable version is v1.11.1 and that is what the developers recommend most people install.
Like I said in my original post, I prefer to use portage to maintain packages but I followed the advice of the julia devs and cloned the github and compiled v1.11.1
So, Julia is now installed and I have been using it for abstract algebra problems today. It works perfectly.
On the other hand, I still want to try and help improve the gentoo package by providing any diagnostics I can. Should I open a bug instead?
Thanks for the help folks!
~~~~~~~~~~~~~~~~~~~~~~
Nick |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22938
|
| Posted: Sun Jan 05, 2025 3:53 pm Post subject: |
|
|
| TADAitsnick wrote: | | I'm marking this as solved. I have not fixed the issue with emerging the gentoo package for julia. |
It's your thread, but personally, I would not consider the thread solved until emerge dev-lang/julia works correctly for you. The problem might or might not be unique to your system, but until we understand it better, we cannot rule out that a change to the ebuild is needed to prevent problems for other users. If you call the thread solved, some people who would otherwise help may not read it anymore. | TADAitsnick wrote: | | I worked on trying to get a backtrace for a while but I have not been able to. |
Do you require assistance with this? If yes, please describe what you did and how it failed. | TADAitsnick wrote: | Instead, I went to the julia github page.
Note that it says this in the readme: | Code: | | Note: Although some OS package managers provide Julia, such installations are neither maintained nor endorsed by the Julia project. They may be outdated, broken and/or unmaintained. We recommend you use the official Julia binaries instead. |
|
This advice is likely made with good intentions, but I discourage it on principle. We have seen far too many cases of people going outside the package manager and running (often with root privilege) an upstream build system that makes a mess of the host system, which then falls on us to understand and debug when, months or years later, that mess causes problems that get reported in a new forum thread, usually without any initial clues that the system has been polluted by the bad build system. As such, I strongly encourage people not to run upstream build systems from a root shell, and instead either confine the upstream build to a user's home directory or, if at all possible, use at least a skeletal ebuild so that Portage can track what files were written and where. | TADAitsnick wrote: | | Indeed, it seems like the julia package in dev-lang is an older version: v1.8.5 |
This appears to be partly accurate (the v1.9.x series is present, but not keyworded), and is unfortunate. Not every package will be popular enough to have a maintainer who provides timely updates. I don't see any open Gentoo bug reports even requesting a bump to newer versions.
I see that dev-lang/julia-bin is available and offers 1.10.0 and a live version. I cannot comment on the suitability of those packages. | TADAitsnick wrote: | | The most recent stable version is v1.11.1 and that is what the developers recommend most people install. |
As I read the Julia downloads page, they are already up to v1.11.2 as stable, as of December 1, 2024.
| TADAitsnick wrote: | Like I said in my original post, I prefer to use portage to maintain packages but I followed the advice of the julia devs and cloned the github and compiled v1.11.1
So, Julia is now installed |
I hope you installed it under your home directory, and not system-wide. Note that the way you built it almost certainly differs from how Portage builds it, so success building v1.11.1 outside Portage's sandbox does not guarantee that v1.11.1 will build correctly inside the sandbox. We may yet need an ebuild change in addition to bumping up to a newer version of Julia.
| TADAitsnick wrote: | | On the other hand, I still want to try and help improve the gentoo package by providing any diagnostics I can. Should I open a bug instead? |
I cannot speak for sam_, but I will observe that a bug report will likely be appropriate to change the ebuild. We may be able to do some additional diagnosis in the forum before turning to a bug report. It's also possible sam_ will ask you to go to a bug report now. I suggest working on the issue here until sam_ directs otherwise. |
|
| Back to top |
|
|
TADAitsnick
n00b
Joined: 03 Jan 2025
Posts: 10
Location: Indiana, USA
|
| Posted: Sun Jan 05, 2025 5:10 pm Post subject: |
|
|
| Hu wrote: | | The problem might or might not be unique to your system, but until we understand it better, we cannot rule out that a change to the ebuild is needed to prevent problems for other users. If you call the thread solved, some people who would otherwise help may not read it anymore. |
Ok heard that. Good point. My intention in marking it solved was that julia works for me now. I see how that's a bit short-sighted. Changed it back.
| Hu wrote: | | Do you require assistance with this? If yes, please describe what you did and how it failed. |
I could use some help. So there's a variety of software that one could use to get a backtrace so it was a lot of research to do on the spot. The method I chose from the wiki link I posted previously was to use gdb because I've already used that software before. Unfortunately, what I discovered is that /usr/bin/emerge and /usr/sbin/emerge are not binaries. They seem to be python scripts. So, the idea that I had of starting the build again but with gdb -q could not proceed as that command only works on binaries. I'm sure there's a similar way of debugging python scripts, as well, but I don't know enough about the internals of portage.
| Hu wrote: | | This advice is likely made with good intentions, but I discourage it on principle. We have seen far too many cases of people going outside the package manager and running (often with root privilege) an upstream build system that makes a mess of the host system, which then falls on us to understand and debug when, months or years later, that mess causes problems that get reported in a new forum thread, usually without any initial clues that the system has been polluted by the bad build system. |
That makes sense to be worried especially about a noob. I actually agree with you, though. I have a subdirectory within my home directory where I clone all software from github so that I can track it more effectively. It is mostly software that I'm writing though. Like I said, I prefer to use portage. The only production software that I've installed this way are st, dmenu, and julia. st and dmenu are because I patch those and I do not want to run into issues with suckless patching system and portage's ebuild system. And the julia clone I personally see as a temporary solution until I can get portage to work with julia. I could be wrong but I think I've been careful so far. The julia developers explicitly say that their build system does not install any files outside of the build directory and ~/.julia
| Hu wrote: | | Not every package will be popular enough to have a maintainer who provides timely updates. I don't see any open Gentoo bug reports even requesting a bump to newer versions. |
That part. I saw that the gentoo team was looking to fill several positions for maintain packages in sci-mathematics, sci-chemistry, sci-physics, etc. Since scientific computing is likely going to be my focus in graduate school in a year or so, this software interests me. I'm new to julia, so I don't know how many use it outside of computational science and computational mathematics so I'm not sure if it's a related gap in package maintainers with package users as seen in sci-*
As far as why no one has requested newer versions, I'm not sure. Obviously, I have no analytics but my first guess would be that it isn't a popular package for gentoo users. Could be my own bias, though.
| Hu wrote: | | I cannot speak for sam_, but I will observe that a bug report will likely be appropriate to change the ebuild. We may be able to do some additional diagnosis in the forum before turning to a bug report. It's also possible sam_ will ask you to go to a bug report now. I suggest working on the issue here until sam_ directs otherwise. |
That makes sense. I would still like in any way I can to help you more experienced folks understand whether the problem is something in my configuration or the ebuild. Since julia does not install any files outside of the build directory in my home directory and ~/.julia, I should be safe to continue testing dev-lang/julia and dev-lang/julia-bin, right? Or do you recommend additional precautions?
Thanks for taking the time. Your insights were helpful.
~~~~~~~~~~~~~~~~~~~~~~~~~~
Nick |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22938
|
| Posted: Sun Jan 05, 2025 7:43 pm Post subject: |
|
|
| TADAitsnick wrote: | | So, the idea that I had of starting the build again but with gdb -q could not proceed as that command only works on binaries. I'm sure there's a similar way of debugging python scripts, as well, but I don't know enough about the internals of portage. |
I don't think we need to debug a Python script though. sam_ wanted you to attach gdb to the julia process that was built by the install, and run during it: | Code: | | portage 2486 2.2 2.0 424992 332952 pts/3 Sl+ 08:37 0:15 | \_ /var/tmp/portage/dev-lang/julia-1.8.5-r1/work/julia-1.8.5/usr/bin/julia -O3 -C native --output-o /var/tmp/portage/dev-lang/julia-1.8.5-r1/work/julia-1.8.5/usr/lib/julia/sys-o.a.tmp --startup-file=no --warn-overwrite=yes --sysimage /var/tmp/portage/dev-lang/julia-1.8.5-r1/work/julia-1.8.5/usr/lib/julia/sys.ji /var/tmp/portage/dev-lang/julia-1.8.5-r1/work/julia-1.8.5/contrib/generate_precompile.jl 1 |
I think what you need to do then is to run emerge --ask dev-lang/julia, wait for it to hang, then in a separate terminal, run gdb -p "$(pidof julia)". That should put you in the state where you can run the backtrace that sam_ requested. | TADAitsnick wrote: | | I could be wrong but I think I've been careful so far. The julia developers explicitly say that their build system does not install any files outside of the build directory and ~/.julia |
I would be a bit surprised if they even mean that make install will not write outside those areas though. I suspect they mean that, like most packages, they do not write to the system until you use make install to tell them to do that. Even so, I find their explicit assurance to be a good sign. | TADAitsnick wrote: | | As far as why no one has requested newer versions, I'm not sure. Obviously, I have no analytics but my first guess would be that it isn't a popular package for gentoo users. Could be my own bias, though. |
Some packages are maintained by Gentoo developers that have a personal reason to track upstream actively, and those usually get fast bumps even without prompting. Some packages are maintained as a courtesy by a developer who has no reason to monitor upstream closely, but who will still bump promptly when aware of the need. Some may have fallen into neglect because their maintainer retired from Gentoo, and no one remained who cared to look at it.
I think if a Julia version has been released upstream more than a month in the past, and there is no evidence that the Gentoo maintainer is aware of the release, then filing a bump request bug to politely inform the maintainer would be acceptable. If the maintainer is aware and simply has not had time to work on it, a bump request is less useful. For some packages, processing a bump request can involve notable work, requiring hours to review what has changed, test the new version, and so on. Thus, sometimes a maintainer can go days between becoming aware that a bump is needed and getting the bump published. I don't know if Julia is in this category, or if bump requests are dominated by the time spent typing the relevant commands. | TADAitsnick wrote: | | Since julia does not install any files outside of the build directory in my home directory and ~/.julia, I should be safe to continue testing dev-lang/julia and dev-lang/julia-bin, right? Or do you recommend additional precautions? |
I think as long as you do not run make install as root from the checkout, you should be fine. The Julia project is not actively trying to break anything, so basic filesystem permissions that confine all non-root users should be sufficient to prevent it from making a mess. If we were discussing software with a history of causing problems, I would be considerably more cautious about using kernel mechanisms to tightly constrain it. As is, the worst it can do is delete your home directory.  |
|
| Back to top |
|
|
TADAitsnick
n00b
Joined: 03 Jan 2025
Posts: 10
Location: Indiana, USA
|
| Posted: Tue Jan 07, 2025 4:24 am Post subject: |
|
|
| Hu wrote: | | I think what you need to do then is to run emerge --ask dev-lang/julia, wait for it to hang, then in a separate terminal, run gdb -p "$(pidof julia)". That should put you in the state where you can run the backtrace that sam_ requested. |
Okay that makes sense. Somehow, I didn't realize that that was what happened when it was freezing. I will get back to you on that.
| Hu wrote: | | I would be a bit surprised if they even mean that make install will not write outside those areas though. I suspect they mean that, like most packages, they do not write to the system until you use make install to tell them to do that. Even so, I find their explicit assurance to be a good sign. |
Makes sense for you to be skeptical, but they said it in the context of a complete uninstall. So I thought they really mean it when they say it. Re-reading it now after your advice:
| Code: | Uninstalling Julia
By default, Julia does not install anything outside the directory it was cloned into and ~/.julia. Julia and the vast majority of Julia packages can be completely uninstalled by deleting these two directories. |
So they actually say the vast majority of Julia packages. So it sounds reassuring, but in fact is worded pretty ambiguously if you keep a skeptical eye, like you did. I'm thinking I should be okay, though.
| Hu wrote: | | think as long as you do not run make install as root from the checkout, you should be fine. The Julia project is not actively trying to break anything, so basic filesystem permissions that confine all non-root users should be sufficient to prevent it from making a mess. |
Ummm I may or may not have did exactly that. But in my defense that's the only way that I could do it. I tried not running sudo first. I'm considering switching from sudo to doas anyway, but that's besides the point. Thanks for pointing that out.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nick |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
