tools and systemtap containers are available in Fedora

[Tomas Tomecek]

Hello,

we managed to move tools container from Fedora Dockerfiles github repo to
Fedora infra [1]. As a side effects, we put systemtap in a dedicated
container.

We would very much appreciate your feedback here: so if you have some time
to take a look at these containers and try them out, it would mean a lot to
us.

Repos:
https://src.fedoraproject.org/container/systemtap
https://src.fedoraproject.org/container/tools

The way to access the images:
docker pull candidate-registry.fedoraproject.org/f26/tools
docker pull candidate-registry.fedoraproject.org/f26/systemtap

Both images have help files, so please read them prior using the containers:
https://src.fedoraproject.org/container/tools/blob/master/f/root/README.md
https://github.com/container-images/systemtap/blob/master/help/help.md

(or `atomic help $the_container_image`)

[1] https://pagure.io/atomic-wg/issue/214

[atomic-devel] tools and systemtap containers are available in Fedora

[Dusty Mabe]

On 09/18/2017 10:48 AM, Tomas Tomecek wrote:
>  Hello,
>  
>  we managed to move tools container from Fedora Dockerfiles github repo to Fedora infra
> [1]. As a side effects, we put systemtap in a dedicated container.
>  
>  We would very much appreciate your feedback here: so if you have some time to take a look
> at these containers and try them out, it would mean a lot to us.
>  
>  Repos:
>  https://src.fedoraproject.org/container/systemtap
>  https://src.fedoraproject.org/container/tools
>  
>  The way to access the images:
>  docker pull candidate-registry.fedoraproject.org/f26/tools
> <http://candidate-registry.fedoraproject.org/f26/tools> 
just tested out the tools container. can we get this into the official registry?

> docker pull candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>
> 
> Both images have help files, so please read them prior using the containers:
> https://src.fedoraproject.org/container/tools/blob/master/f/root/README.md
> https://github.com/container-images/systemtap/blob/master/help/help.md
> 
> (or `atomic help $the_container_image`)
> 
> [1] https://pagure.io/atomic-wg/issue/214

[atomic-devel] tools and systemtap containers are available in Fedora

[Tomas Tomecek]

Not sure if the question is for me -- I literally have no idea how to do
that.


Let me know how I can help,

Tomas


On Thu, Oct 5, 2017 at 5:04 AM, Dusty Mabe <dusty(a)dustymabe.com&gt; wrote:

>  On 09/18/2017 10:48 AM, Tomas Tomecek wrote:
>  > Hello,
>  >
>  > we managed to move tools container from Fedora Dockerfiles github repo
>  to Fedora infra [1]. As a side effects, we put systemtap in a dedicated
>  container.
>  >
>  > We would very much appreciate your feedback here: so if you have some
>  time to take a look at these containers and try them out, it would mean a
>  lot to us.
>  >
>  > Repos:
>  > https://src.fedoraproject.org/container/systemtap
>  > https://src.fedoraproject.org/container/tools
>  >
>  > The way to access the images:
>  > docker pull candidate-registry.fedoraproject.org/f26/tools <
>  http://candidate-registry.fedoraproject.org/f26/tools>
>
>  just tested out the tools container. can we get this into the official
>  registry?
>
>  > docker pull candidate-registry.fedoraproject.org/f26/systemtap <
>  http://candidate-registry.fedoraproject.org/f26/systemtap>
>  >
>  > Both images have help files, so please read them prior using the
>  containers:
>  > https://src.fedoraproject.org/container/tools/blob/master/f/
>  root/README.md
>  > https://github.com/container-images/systemtap/blob/master/help/help.md
>  >
>  > (or `atomic help $the_container_image`)
>  >
>  > [1] https://pagure.io/atomic-wg/issue/214
>

[Mark Wielaard]

On Mon, 2017-09-18 at 16:48 +0200, Tomas Tomecek wrote:
>  we managed to move tools container from Fedora Dockerfiles github
>  repo to Fedora infra [1]. As a side effects, we put systemtap in a
>  dedicated container.
>  
>  We would very much appreciate your feedback here 
What determines what goes into tools and what in a separate container
(like systemtap). I see the tools container has strace, gcc, gdb, perf,
etc. But not other development tools like binutils, elfutils and
valgrind. Will those be added or will they come in some separate
container?

Thanks,

Mark

[atomic-devel] tools and systemtap containers are available in Fedora

[Daniel Walsh]

On 10/06/2017 10:14 AM, Mark Wielaard wrote:
>  On Mon, 2017-09-18 at 16:48 +0200, Tomas Tomecek wrote:
> > we managed to move tools container from Fedora Dockerfiles github
> > repo to Fedora infra [1]. As a side effects, we put systemtap in a
> > dedicated container.
> >
> > We would very much appreciate your feedback here
>  What determines what goes into tools and what in a separate container
>  (like systemtap). I see the tools container has strace, gcc, gdb, perf,
>  etc. But not other development tools like binutils, elfutils and
>  valgrind. Will those be added or will they come in some separate
>  container?
>
>  Thanks,
>
>  Mark
>  
Right now there is a an effort going on to shrink the tools container, 
it has grown huge.

I would prefer you create a debug container and put all of these tools 
in there.

[atomic-devel] tools and systemtap containers are available in Fedora

Hi,

BTW since we are talking about debug and future tech, what is the correct way (as of
rawhide and EPEL 7) to handle 

extracting debug info from
/builddir/build/BUILDROOT/golang-github-performancecopilot-speed-2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
*** ERROR: No build ID note found in
/builddir/build/BUILDROOT/golang-github-performancecopilot-speed-2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump

(I have those in all Go packages that build something)

I can sprinkle %global debug_package   %{nil} everywhere, but that's not overly
satisfying.

Regards,

-- 
Nicolas Mailhot

[atomic-devel] tools and systemtap containers are available in Fedora

[Frank Ch. Eigler]

nicolas.mailhot wrote:

>  [...]
>  extracting debug info from
>
> /builddir/build/BUILDROOT/golang-github-performancecopilot-speed-2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
>  *** ERROR: No build ID note found in
>
> /builddir/build/BUILDROOT/golang-github-performancecopilot-speed-2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
See https://fedoraproject.org/wiki/PackagingDrafts/Go#Build_ID

- FChE

[atomic-devel] tools and systemtap containers are available in Fedora

De: "Frank Ch. Eigler" 

|nicolas.mailhot wrote:
|
|> [...]
|> extracting debug info from
|>
/builddir/build/BUILDROOT/golang-github-performancecopilot-speed-2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
|> *** ERROR: No build ID note found in
|>
/builddir/build/BUILDROOT/golang-github-performancecopilot-speed-2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
|
|See https://fedoraproject.org/wiki/PackagingDrafts/Go#Build_ID

Thanks, I somewhat missed it in all the not-really current EL6-oriented stuff in this
document

Regards,

-- 
Nicolas Mailhot

[atomic-devel] tools and systemtap containers are available in Fedora

[Mark Wielaard]

On Wed, 2017-10-11 at 20:36 +0200, nicolas.mailhot(a)laposte.net wrote:
>  De: "Frank Ch. Eigler" 
>  
>  > nicolas.mailhot wrote:
>  > 
>  > > [...]
>  > > extracting debug info from
>  > > /builddir/build/BUILDROOT/golang-github-performancecopilot-speed-
>  > > 2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
>  > > *** ERROR: No build ID note found in
>  > > /builddir/build/BUILDROOT/golang-github-performancecopilot-speed-
>  > > 2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
>  > 
>  > See https://fedoraproject.org/wiki/PackagingDrafts/Go#Build_ID
>  
>  Thanks, I somewhat missed it in all the not-really current EL6-
>  oriented stuff in this document 
I CCed Jakub, who maintains the go package. He might have some update
to this. We did recently discuss adding the support directly to the go
linker, but I believe that isn't yet there.

The problem indeed is that the golang linker doesn't insert a build-id
note in the executable. In theory this can also be worked around by
using %undefine _missing_build_ids_terminate_build in your spec file.
But the workaround in the wiki is better. Once there is a build-id note
 rpm debugedit can update it (making it unique, but stable).
Unfortunately rpm debugedit cannot insert it itself. The ELF note needs
to be in an allocated section, meaning that to add it the runtime
program headers also need to be update. And rpm debugedit cannot do
that easily. Only a real linker can.

Please let me know if there are any other issues with debuginfo
packages for go programs that you cannot work around with the hints in
the wiki page.

Thanks,

Mark

[atomic-devel] tools and systemtap containers are available in Fedora

De: "Mark Wielaard" 

> On Wed, 2017-10-11 at 20:36 +0200, nicolas.mailhot(a)laposte.net wrote:
> > De: "Frank Ch. Eigler" 
>  
> > > nicolas.mailhot wrote:
> > > 
> > > > [...]
> > > > extracting debug info from
> > > > /builddir/build/BUILDROOT/golang-github-performancecopilot-speed-
> > > > 2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
> > > > *** ERROR: No build ID note found in
> > > > /builddir/build/BUILDROOT/golang-github-performancecopilot-speed-
> > > > 2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
> > > 
> > > See https://fedoraproject.org/wiki/PackagingDrafts/Go#Build_ID
> > 
> > Thanks, I somewhat missed it in all the not-really current EL6-
> > oriented stuff in this document 
> I CCed Jakub, who maintains the go package. He might have some update
> to this. We did recently discuss adding the support directly to the go
> linker, but I believe that isn't yet there. 
> The problem indeed is that the golang linker doesn't insert a
> build-id
> note in the executable. In theory this can also be worked around by
> using %undefine _missing_build_ids_terminate_build in your spec file.
> But the workaround in the wiki is better.  
> Please let me know if there are any other issues with debuginfo
> packages for go programs that you cannot work around with the hints in
> the wiki page. 
Thanks for the proposal, I will indeed try to report issues rather than workarounding them
silently and forgetting about long-term fixing. Even if the best intentions tend to erode
around the 20th Go spec ;)

Regards,

-- 
Nicolas Mailhot

[Tomas Tomecek]

Mark, thanks for feedback!

I'll be honest that I left gcc and gdb in there by accident. As Dan said,
we are trying to reduce size of that container so it's easier to use. Who
decides what's in it? This was an internal collaboration with multiple
people -- in the end, everyone can express themselves and provide feedback
or suggestions.

Would you be able to come up with a complete list of packages you have in
mind? Creating a new issue in Atomic WG issue tracker would be really
helpful to us: https://pagure.io/atomic-wg/issues

I agree with Dan that this could be a good candidate for a debugging
container -- tools container could contain sysadmin tools and the debugging
container could be used for debugging applications and maybe even
C-development.


Tomas

On Fri, Oct 6, 2017 at 4:14 PM, Mark Wielaard <mjw(a)fedoraproject.org&gt; wrote:

>  On Mon, 2017-09-18 at 16:48 +0200, Tomas Tomecek wrote:
>  > we managed to move tools container from Fedora Dockerfiles github
>  > repo to Fedora infra [1]. As a side effects, we put systemtap in a
>  > dedicated container.
>  >
>  > We would very much appreciate your feedback here
>
>  What determines what goes into tools and what in a separate container
>  (like systemtap). I see the tools container has strace, gcc, gdb, perf,
>  etc. But not other development tools like binutils, elfutils and
>  valgrind. Will those be added or will they come in some separate
>  container?
>
>  Thanks,
>
>  Mark
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>

[Mark Wielaard]

Hi Tomas,

On Fri, 2017-10-06 at 20:09 +0200, Tomas Tomecek wrote:
>  Mark, thanks for feedback!
>  
>  I'll be honest that I left gcc and gdb in there by accident. As Dan
>  said, we are trying to reduce size of that container so it's easier
>  to use. Who decides what's in it? 
>  This was an internal collaboration with multiple
>  people -- in the end, everyone can express themselves and provide
>  feedback or suggestions.
>  
>  Would you be able to come up with a complete list of packages you
>  have in mind? Creating a new issue in Atomic WG issue tracker would
>  be really helpful to us: https://pagure.io/atomic-wg/issues
>  
>  I agree with Dan that this could be a good candidate for a debugging
>  container -- tools container could contain sysadmin tools and the
>  debugging container could be used for debugging applications and
>  maybe even C-development. 
Aha. Interesting. I think the name "tools" is a little misleading.
Seeing some of the "tools" in there I assumed it was actually the
development tools container. The name tools might be a bit overloaded
:)

I am not sure debugging container on itself is that useful, it probably
should be a developer tools container, containing everything you would
use for your normal edit-compile-debug cycle. Or maybe a group of
"stacked" containers might be nice, one for the core native toolchain,
one for development debug tools and one for production monitoring,
tracing and profiling?

Maybe the packages from the Developer Toolset software collection (for
CentOS, but then for current Fedora) might be a good starting point:
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-6/
Those come with a toolchain and perftools collection, also available as
docker image. But designed to be parallel installable, something which
you might not care for for the atomic containers. But the package lists
might be a good starting point.
http://mirror.centos.org/centos/7/sclo/x86_64/rh/devtoolset-7/

Cheers,

Mark