Hi Bastian, I've uploaded julia_1.0.2-1 to unstable (NEW) yesterday. There are already six uploads being piled up in NEW. These uploads already have been tested by Ubuntu devel extensively, and are suitable for the Buster release.
I totally understand that for traditional C/C++ shared object, stripping debugging information makes sence for our archive, and I'm really stripping my every other C/C++ shared objects in other packages. However I must emphasize that, the unstripped ELF shared object sys.so shipped by libjulia* is *NOT* a usual shared object which people are familiar with. This shared object is called julia's "sysimage" which is compiled from julia's base (core functionality) and standard library (written in pure julia) to speed up julia interpreter initialization by reducing the JIT overhead. Julia is an interpreting language with heavy JIT compilation... while we can even compile pure julia scripts into ELF format... just like sys.so and [1]. To illustrate what sys.so is, here is a random fragment of its symbol table[2]: 3137: 000000000753d918 8 OBJECT LOCAL DEFAULT 23 +LinearAlgebra.Transpose8496 3138: 0000000007544308 8 OBJECT LOCAL DEFAULT 23 +LinearAlgebra.UniformScaling14136 3139: 0000000007536798 8 OBJECT LOCAL DEFAULT 23 +Logging.ConsoleLogger3352 3140: 000000000754b690 8 OBJECT LOCAL DEFAULT 23 +Main.Base.##12#1321680 3141: 0000000007540fe0 8 OBJECT LOCAL DEFAULT 23 +Main.Base.##223#22411153 3142: 000000000753ef58 8 OBJECT LOCAL DEFAULT 23 +Main.Base.##223#2249585 3143: 00000000075496a0 8 OBJECT LOCAL DEFAULT 23 +Main.Base.##227#22819234 Are they ordinary symbols that you are familiar with? They are more likely sort of llvm cache in the native machine code format. The consequence of stripping sys.so has already been stated by Graham. It feels like Julia interpreter cannot trace (via backtrace/stacktrace) into *script* after we did something tricky to the cache generated from the original *script*. Such phenomenon, to my understanding, is ridiculous to an interpreting language. As a julia user and the de-facto julia package maintainer for more than 10 recent uploads, I think making Debian's Julia interpreter behave differently from upstream binary release at this point is not a good idea, and the different behaviour is likely to confuse users in the future. Please consider giving Julia 1.X a chance to enter Buster, thanks. [1] https://github.com/JuliaLang/PackageCompiler.jl [2] readelf -sW sys.so On Fri, Nov 23, 2018 at 04:42:53PM +0200, Graham Inggs wrote: > Hi Bastian > > On 2018/11/21 16:11, Bastian Blank wrote: > > I have not seen a real explanation why it needs to be this and exactly > > this way. This setup was explained as either > > - a workaround for a bug, > > - a way to get stacktraces from users or > > - a way to make autopkgtest run. > > Stripping sys.so breaks one of Julia's language features, which is the > ability to trace into its standard library. An example [1] is found in the > documentation. > > One of Julia's tests checks this, and hence autopkgtests fail if debug > symbols are missing from sys.so, which is compiled from .jl scripts, not > C/CXX source. > > We could strip sys.so and create a manual debug symbols package, but in > order to make the Debian package have the same features as upstream, we > would make the Julia package depend on it. > > We would prefer to ship sys.so unstripped, but if you insist on having an > extra binary package in the archive in order to silence Lintian, we will do > it. > > Regards > Graham > > [1] https://docs.julialang.org/en/v1.0.0/manual/stacktraces/