This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

persist in python-debuginfo-2.7.5-11.fc20.x86_64

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Persist in python-2.7.10-1.fc23

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Hmm, the package owning /usr/src/debug/tmp changed to glib2-debuginfo in Fedora 24. Reassigning.

[root@bonobo ~]# rpm -qf /usr/src/debug/tmp
glib2-debuginfo-2.48.2-1.fc24.x86_64
[root@bonobo ~]# ls -ld /usr/src/debug/tmp
drwxrwxrwt. 2 root root 4096 Aug 18 07:42 /usr/src/debug/tmp
[root@bonobo ~]# rpm -V glib2-debuginfo-2.48.2-1.fc24.x86_64
[root@bonobo ~]#

In case that binary compiled from source generated in /tmp, a
/usr/src/debug/tmp directory will be created with the same mode as
/tmp, a.k.a 777, which should be avoided.

Upstream PR: https://github.com/rpm-software-management/rpm/pull/194

(In reply to Robin Lee from comment #8)
> In case that binary compiled from source generated in /tmp, a
> /usr/src/debug/tmp directory will be created with the same mode as
> /tmp, a.k.a 777, which should be avoided.
> 
> Upstream PR: https://github.com/rpm-software-management/rpm/pull/194

Thanks. Explicitly setting all directories under /usr/debug/src to 0755 instead of using a+rx is a very good idea. It is surprising we didn't catch this earlier.

Besides that fix (which I agree should be included) we should figure out why the (empty) tmp dir is included in the fist place directly under /usr/src/debug/. We are doing something else wrong if we include any file or directory not under /usr/src/debug/<package-nvr>/. I suspect there is some relative path (../../tmp/.. ?) involved that somehow confuses debugedit or find-debuginfo.sh. So please keep this bug open even if the above patch is applied.

(In reply to Mark Wielaard from comment #9)
> (In reply to Robin Lee from comment #8)
> > In case that binary compiled from source generated in /tmp, a
> > /usr/src/debug/tmp directory will be created with the same mode as
> > /tmp, a.k.a 777, which should be avoided.
> > 
> > Upstream PR: https://github.com/rpm-software-management/rpm/pull/194
> 
> Thanks. Explicitly setting all directories under /usr/debug/src to 0755
> instead of using a+rx is a very good idea. It is surprising we didn't catch
> this earlier.
> 
> Besides that fix (which I agree should be included) we should figure out why
> the (empty) tmp dir is included in the fist place directly under
> /usr/src/debug/. We are doing something else wrong if we include any file or
> directory not under /usr/src/debug/<package-nvr>/. I suspect there is some
> relative path (../../tmp/.. ?) involved that somehow confuses debugedit or
> find-debuginfo.sh. So please keep this bug open even if the above patch is
> applied.

In the case of glib2, libgobject-2.0.so actually has a source file named /tmp/tmpXXXX.c. So it seems proper for debugedit to generate a path /tmp/tmpXXXX.c to $SOURCEFILE. Though /tmp/tmpXXXX.c is cleaned at the moment of debuginfo generating.

A simple fix may be just travelling /usr/debug/src, and delete empty directories, in find-debuginfo.sh.

After that, the most proper fix would be for all those packages that compiling binaries from temporary source files, generate the temporary source files within the build directory, and don't clean them after building.

(In reply to Robin Lee from comment #10)
> In the case of glib2, libgobject-2.0.so actually has a source file named
> /tmp/tmpXXXX.c. So it seems proper for debugedit to generate a path
> /tmp/tmpXXXX.c to $SOURCEFILE. Though /tmp/tmpXXXX.c is cleaned at the
> moment of debuginfo generating.

Aha. That does make sense. But it means you cannot really debug such code because we fail to ship that (generated) source file.

> A simple fix may be just travelling /usr/debug/src, and delete empty
> directories, in find-debuginfo.sh.

We keep the empty directories in case there is a relative path through such a directory because some DWARF consumers rely on actual fill path to a source file existing. See this comment in debugedit.c:

  /* Ensure the CU current directory will exist even if only empty.  Source
     filenames possibly located in its parent directories refer relatively to
     it and the debugger (GDB) cannot safely optimize out the missing
     CU current dir subdirectories.  */

> After that, the most proper fix would be for all those packages that
> compiling binaries from temporary source files, generate the temporary
> source files within the build directory, and don't clean them after building.

We used to have problems rewriting source path that would result in a larger path. But most of such issues have been resolved these days. So we could in theory include the actual source file and rewrite /tmp/foobar.c to /usr/debug/src/<package-nvr>/tmp/foobar.c. We just have to figure out when such files/paths make sense. I assume we don't want to do this for any standard include file under /usr/include/ for example.

This can happen in two ways. Either a compile_unit has a comp_dir with a directory outside the RPM_BUILD_DIR or the compile_unit doesn't have a comp_dir, but the name attribute is an absolute path outside the RPM_BUILD_DIR.

The following hello.spec shows the issue (using /var/tmp instead of /tmp/ to show this issue isn't unique to packages building some sources in /tmp).

$ cat hello.spec 
Summary: hello world
Name: hello
Version: 1.0
Release: 1
License: GPL

%description
hello world

%prep
%setup -c -T

%build
echo 'int main (int argc, char **argv) { return 0; }' > /var/tmp/foo.c
cp /var/tmp/foo.c /var/tmp/bar.c

# This will change the comp_dir to /var/tmp.
pushd /var/tmp
gcc -g -o foo foo.c
popd
mv /var/tmp/foo foo

# As long as say.c doesn't include any files no comp_dir will be created.
# But the DW_AT_name will be the full file path. debugedit will use the
# dirname as comp_dir.
gcc -g -o bar /var/tmp/bar.c

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/local/bin
cp foo bar $RPM_BUILD_ROOT/usr/local/bin/

%files
%defattr(-,root,root)
/usr/local/bin/foo
/usr/local/bin/bar

%changelog
* Thu Apr 20 2017 Mark Wielaard <mjw> - 1.0.1
- Hello

$ rpmbuild -ba hello.spec
$ rpm2cpio /home/mark/rpmbuild/RPMS/x86_64/hello-debuginfo-1.0-1.x86_64.rpm | cpio --list --verbose | grep var
63 blocks
drwxr-xr-x   3 root     root            0 Apr 21 11:52 ./usr/src/debug/var
drwxrwxrwt   2 root     root            0 Apr 21 11:52 ./usr/src/debug/var/tmp

On fedora rawhide (with %_unique_debug_srcs set) the var and var/tmp directories end up under ./usr/src/debug/hello-1.0-1.x86_64/ which is slightly better (because then they won't conflict with other debuginfo packages). But still bogus since those locations are still empty and might actually be confused for actual directories with the same name that did exist under the original build root.

With current trunk git rpm the directories are at least all chmod 0755.

We really shouldn't include these directories (and if we do then we should also get the source files included). The cause is the code that makes sure that even if a directory (comp_dir) is empty we still include it (in case a file uses a relative path through it) is too greedy. It should only do that for directories which are actually under the original RPM_BUILD_DIR.

(In reply to Mark Wielaard from comment #12)
> We really shouldn't include these directories (and if we do then we should
> also get the source files included). The cause is the code that makes sure
> that even if a directory (comp_dir) is empty we still include it (in case a
> file uses a relative path through it) is too greedy. It should only do that
> for directories which are actually under the original RPM_BUILD_DIR.

The following patch submitted upstream fixes that:
http://lists.rpm.org/pipermail/rpm-maint/2017-April/005462.html

If it gets accepted I'll add it and the patch from Robin Lee to explicitly set the directory mode to 0755 to the fedora rpm package.

(In reply to Mark Wielaard from comment #13)
> If it gets accepted I'll add it and the patch from Robin Lee to explicitly
> set the directory mode to 0755 to the fedora rpm package.

Accepted upstream and now in rpm-4.13.0.1-4.fc26 and rpm-4.13.0.1-20.fc27.

rpm-4.13.0.1-4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b8a3febd40

rpm-4.13.0.1-4.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-b8a3febd40

rpm-4.13.0.1-4.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

rpm-4.13.0.1-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-e9a1ddb533

rpm-4.13.0.1-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e9a1ddb533

rpm-4.13.0.1-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.