fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<fche2>
yeah AIUI it's just an early bootstrapping concern
<tonyj>
out build team is asking me to rewrite dtrace is something other than python which obviously is work and would need a good reason to be accepted
<fche2>
can the build team build an initial version of python with --without-dtrace ?
<fche2>
then that version can run /usr/bin/dtrace, in order to rebuild that python vm --with-dtrace ?
pwithnall has quit [Quit: pwithnall]
<tonyj>
this was my idea too, I'd been looking at the fedora builds and wasn't really seeing why this wasn't an issue in fedora also
pwithnall has joined #systemtap
pwithnall has quit [Remote host closed the connection]
<fche2>
mass-rebuilds are based on previous generation builds (which have already solved the boostrapping loops)
<tonyj>
the problem is we have to allow users to rebuild packages in the field, using rpmbuild.
<fche2>
that's fine
<fche2>
the python they'll have installed by then should be the boostrap-rebuilt copy
<tonyj>
so we'd have to publish two pythons
<fche2>
nope, just the latter one
<fche2>
ISTM
<fche2>
now, there's another whole approach possible here. you don't really have to run /usr/bin/dtrace all the time. Its output really does not change from version to version
<tonyj>
yes, lots of things are possible with background hcks.
<fche2>
so you could just snapshot all of its output files as auxiliary sources in your python source rpm, and build with them
<tonyj>
I'm talking builds that make use of just the standard rpm buildrequires mechanisms
<fche2>
you could skip the buildrequires: systemtap-devel-sdt parts if you save the generated files in your src.rpm
<fche2>
anyway ... maybe I'm missing an aspect of your build team's problem statement
<fche2>
what is an example of a scenario they worry about ?
<tonyj>
I don't understand the question.
<fche2>
what is the problem they are trying to solve with the 'rewrite /usr/bin/dtrace in language X' solution ?
<tonyj>
the dependancy loop
<tonyj>
X != python
<fche2>
it feels like a problem, but how -is- it a problem?
<fche2>
i.e., how do they do normal dependency loop boostrapping like gcc requiring gcc to build ?
<tonyj>
because it creates an unsolvable loop in our buildsystem
<tonyj>
"can the build team build an initial version of python with --no-dtrace" sure but this would have to be a package that "exists" in the buildsystem
<fche2>
sure, give it a low version number that'll be instantly replaced by the real one from the boostrap-2 phase
<tonyj>
I don't believe our buildsystem works in the same way as the fedora one, this is the issue
<tonyj>
clearly recoding dtrace because of this is a non-starter
<fche2>
how does your build system handle gcc / glibc bootsrapping ?
<tonyj>
Good question. One of the challenges is getting a decent problem statement from the buildsystem people.
<fche2>
heh :)
<tonyj>
we have a ring based buildsystem. previously already have systemtap split into two spec files, one for docs and one for rest. the docs runs much later to avoid massive dependancies.
<fche2>
(we're starting to use --enable-docs=prebuilt to work around that ... the doc toolchains have become fragile)
slowfranklin has left #systemtap [#systemtap]
mjw has quit [Quit: Leaving]
naveen has quit [Ping timeout: 240 seconds]
sanoj has joined #systemtap
sanoj has quit [Ping timeout: 264 seconds]
gromero has quit [Ping timeout: 256 seconds]
gromero has joined #systemtap
mjw has joined #systemtap
scox has quit [Ping timeout: 255 seconds]
brolley has left #systemtap [#systemtap]
wcohen has quit [Ping timeout: 265 seconds]
<irker311>
systemtap: amerey systemtap.git:refs/heads/master * release-3.3-36-gb651272 / tapset/prometheus.stp tapset/prometheus.stpm: tapset: add stap-exporter utility macros and probe alias http://tinyurl.com/y9ujv8ms
tromey has quit [Quit: ERC (IRC client for Emacs 26.1.50)]
wcohen has joined #systemtap
pviktori has quit [Quit: No Ping reply in 180 seconds.]