Opened 2 years ago

Last modified 3 months ago

#30158 new enhancement

Reduce outdated gdb and valgrind packages to dummy script packages

Reported by: Matthias Köppe Owned by:
Priority: minor Milestone: sage-9.8
Component: packages: experimental Keywords:
Cc: Dima Pasechnik, John Palmieri, Michael Orlitzky Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by Matthias Köppe)

These are devtools, not needed for building.

Last update to gdb was made in 2018

Last update to valgrind was made in 2019

Change History (19)

comment:1 Changed 2 years ago by Matthias Köppe

Description: modified (diff)

comment:2 Changed 2 years ago by Dima Pasechnik

indeed, looks like makeinfo is missing;

can we just add makeinfo to the list of reqs on Linux (typically, it's texinfo, at least on debian/ubuntu package)

alternatively modify spkg-install to configure without makeinfo.

comment:3 Changed 2 years ago by Matthias Köppe

Milestone: sage-9.2sage-9.3

comment:4 Changed 21 months ago by Matthias Köppe

Milestone: sage-9.3sage-9.4

Sage development has entered the release candidate phase for 9.3. Setting a new milestone for this ticket based on a cursory review of ticket status, priority, and last modification date.

comment:5 Changed 17 months ago by Matthias Köppe

Milestone: sage-9.4sage-9.5

comment:6 Changed 12 months ago by Matthias Köppe

Milestone: sage-9.5sage-9.6

comment:7 Changed 11 months ago by Matthias Köppe

Description: modified (diff)
Summary: Update gdb packageReduce outdated gdb and valgrind packages to dummy script packages

comment:8 Changed 9 months ago by Matthias Köppe

Cc: Michael Orlitzky added

comment:9 Changed 9 months ago by John Palmieri

Rather than dummy packages, or maybe in addition, would it make sense to put the relevant scripts in their own package? Or just document how to replicate their effects in the Developer's Guide, as I think @mjo suggested on sage-devel?

comment:10 Changed 9 months ago by Matthias Köppe

These packages don't supply the scripts; they are equivalent to any system installation of gdb or valgrind.

One thing that our python3 spkg does do is install some .supp files that come from the Python source distribution. Distribution packaging MIGHT install them too for use with system-packaged valgrind, but I am not sure how widespread that is.

So it could make sense to vendor python3's supp files as part of #33074.

comment:11 Changed 9 months ago by Michael Orlitzky

What benefit would we get from script packages opposed to removal?

I think the scripts can go, but not before we add some docs. There are a few critical tricks one needs to know:

  • Entering a sage-shell
  • Passing -i to sage-ipython
  • The use of both python's and sage's suppression files
  • Setting PYTHONMALLOC=malloc in the environment
  • Ensuring that your glibc has debug symbols available

The python3 suppression rules generally won't be installed, but instead of vendoring them for the zero people that currently use this, we could probably just link to the rules file in the upstream repo. This is a process that's heavy on manual intervention anyway.

comment:12 in reply to:  10 ; Changed 9 months ago by John Palmieri

Replying to mkoeppe:

These packages don't supply the scripts; they are equivalent to any system installation of gdb or valgrind.

Sorry, I wasn't very clear. By "maybe in addition," I was asking if there should be a new package that supplies the scripts, valgrind-sage-support or whatever. The point is to remove those rarely scripts from src/bin unless the user specifically requests them.

One thing that our python3 spkg does do is install some .supp files that come from the Python source distribution. Distribution packaging MIGHT install them too for use with system-packaged valgrind, but I am not sure how widespread that is.

So it could make sense to vendor python3's supp files as part of #33074.

I don't know how any of this works. If someone uses a system Python without .supp files, can they use Sage-distributed .supp files instead? For what it's worth, homebrew doesn't seem to provide these:

% find /usr/local -name "*.supp" -print 
find: /usr/local/mysql-8.0.23-macos10.15-x86_64/keyring: Permission denied
find: /usr/local/mysql-8.0.23-macos10.15-x86_64/data: Permission denied
/usr/local/Cellar/glib/2.70.3/share/glib-2.0/valgrind/glib.supp

find /System/Library/Frameworks/Python.framework -name "*.supp" -print also returns nothing, although I don't know if that's the right place to look for .supp files for the default OS X Python installation.

Anyway, if it is possible to mix .supp files for different versions of Python, or if we can create new ones using whatever Python is being used by Sage, that could be part of the same valgrind support package.

comment:13 Changed 9 months ago by John Palmieri

Regarding this I tend to agree with @mjo. Unlike some aspects of Sage, this is something that will only be used by people who know what they're doing, and they should be able to handle reading some docs to do it. Other parts of Sage must be accessible to math students and math researchers and other computer neophytes, but not valgrind.

comment:14 in reply to:  11 Changed 9 months ago by Matthias Köppe

Replying to mjo:

What benefit would we get from script packages opposed to removal?

Dummy script packages are there for advertising system package information.

comment:15 in reply to:  12 Changed 9 months ago by Matthias Köppe

Replying to jhpalmieri:

If someone uses a system Python without .supp files, can they use Sage-distributed .supp files instead? For what it's worth, homebrew doesn't seem to provide these

Yes, the idea of the sage-valgrind script is that it provides --suppressions options to valgrind.

I like the idea of this script, but the details need updating. I needed valgrind only once in the last 5 years and noticed that it was outdated but didn't have the energy to make the proper update. For such rare uses, an updated script (and a vendored copy of the Python suppressions -- note that they are NOT frequently updated upstream) would be of great value.

comment:16 in reply to:  12 Changed 9 months ago by Matthias Köppe

Replying to jhpalmieri:

I was asking if there should be a new package that supplies the scripts, valgrind-sage-support or whatever. The point is to remove those rarely scripts from src/bin unless the user specifically requests them.

That would of course be possible; but I am not sure if it would be an improvement.

comment:17 Changed 9 months ago by Michael Orlitzky

Replying to mkoeppe:

Replying to mjo:

What benefit would we get from script packages opposed to removal?

Dummy script packages are there for advertising system package information.

Yeah, I know, but... do we really need to suggest installing gdb and valgrind to people? Installing them doesn't improve the normal sage experience. And anyone who's actually going to use them is aware of their existence.

comment:18 Changed 8 months ago by Matthias Köppe

Milestone: sage-9.6sage-9.7

comment:19 Changed 3 months ago by Matthias Köppe

Milestone: sage-9.7sage-9.8
Note: See TracTickets for help on using tickets.