Discussion:
Porter roll call for Debian Stretch
(too old to reply)
Niels Thykier
2016-08-17 21:00:01 UTC
Permalink
2020), please respond with a signed email containing the following
Can you please specify where to respond to? I don't think dozens of
emails to -ports and -devel make any sense.
Ah, sorry I had indeed forgotten to set Reply-To. :)
Maybe debian-release with CC debian-<ARCH> or to you personally and
you'll collect the info?
Please send the replies to debian-release. :)

Thanks,
~Niels
Niels Thykier
2016-08-21 06:30:01 UTC
Permalink
* If we were to enable -fPIE/-pie by default in GCC-6, should that change
also apply to this port? [0]
If -fPIE is the default will -fPIC override it?
It will also default to tell the linker to use -pie, but then
don't do it when you want to create a shared library?
I believe so. At least, Ubuntu made PIE default in their compiler
without having to change all SO packages to still build.

Admittedly, it could also be that GCC uses some built "compiler spec"
files for this case (a la an implicit "-specs=$FILE"), which are similar
to those Redhat uses for this purposes (see [1] for an example of such
files).

Regardless, it seems to "just work(TM)" if you pass the proper flags
when compiling your SOs.
From what I understand, depending on what the .o file is going to
- shared library: -fPIC
- executable: -fPIC or -fPIE both work, but prefer -fPIE
- static library: Same as executables
For static libraries we now have a policy to not use -fPIC,
should that then get replaced by using -fPIE?
Kurt
Honestly, I had not thought about that. From the looks of it, de facto
we will end up with -fPIE being the default for static libraries as well.
I would be supporting that change on the assumption that it requires
less work from individual maintainers (and presumably has no notable
downsides in the final result).

Thanks,
~Niels

[1] Example spec files for this case seems to be something like:

pie-compile.specs
"""
*cc1_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}}
"""

pie-link.specs:
"""
*self_spec:
+ %{!shared:%{!r:-pie}}
"""

NB: I manually carved them out of a diff without testing them.
Guillem Jover
2016-08-21 12:00:01 UTC
Permalink
Hi!
Post by Niels Thykier
* If we were to enable -fPIE/-pie by default in GCC-6, should that change
also apply to this port? [0]
If -fPIE is the default will -fPIC override it?
It will also default to tell the linker to use -pie, but then
don't do it when you want to create a shared library?
I believe so. At least, Ubuntu made PIE default in their compiler
without having to change all SO packages to still build.
As I mentioned on IRC, the Gentoo people seems to have done so as well
in their Gentoo Hardened Toolchain project
<https://wiki.gentoo.org/wiki/Project:Hardened/Toolchain>.
Post by Niels Thykier
Admittedly, it could also be that GCC uses some built "compiler spec"
files for this case (a la an implicit "-specs=$FILE"), which are similar
to those Redhat uses for this purposes (see [1] for an example of such
files).
I think there are some bugs tracked in Fedora about this
<https://fedoraproject.org/wiki/Changes/Harden_All_Packages>, And this
is what I based the dpkg patch on as a potential alternative instead
of modifying our toolchain, which I think would be preferable. But see
below.
Post by Niels Thykier
From what I understand, depending on what the .o file is going to
- shared library: -fPIC
- executable: -fPIC or -fPIE both work, but prefer -fPIE
- static library: Same as executables
For static libraries we now have a policy to not use -fPIC,
should that then get replaced by using -fPIE?
Honestly, I had not thought about that. From the looks of it, de facto
we will end up with -fPIE being the default for static libraries as well.
I would be supporting that change on the assumption that it requires
less work from individual maintainers (and presumably has no notable
downsides in the final result).
I think that's what we are getting right now for any package enabling
the "pie" build flags feature anyway.
Post by Niels Thykier
pie-compile.specs
"""
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}}
"""
"""
+ %{!shared:%{!r:-pie}}
"""
NB: I manually carved them out of a diff without testing them.
That would be
<https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/dpkg-buildflags-pie-gcc-specs&id=ad4854b4b4711dd49e39371280f0609f8b81c2a6>,
which neither I tested. Testing should first be done for gcc, g++, gcj,
gobjc, gobjc++, gccgo (although I've not managed to use shared libraries
with latest releases, but used to be able to) and gfortran. If someone
wants to test these first to see if it works and then later on do an
archive rebuild, that would also be appreciated.

At that point I could then at least switch the current implementation
so that we can just enable the "pie" feature per package regardless of
it building prorgrams or shared libraries. Enabling it by default
globally would require the usual process described in the dpkg FAQ.

Thanks,
Guillem
Aurelien Jarno
2016-09-05 07:10:01 UTC
Permalink
Hi,
Hi,
Like last release, we are doing a roll call for porters of all release
architectures. If you are an active porter behind one of the [release
architectures] for the entire lifetime of Debian Stretch (est. end of
2020), please respond with a signed email containing the following
Just a short reminder about that, given the deadline is approaching. If
I am not mistaken, I am the only one who answered. We need at least 3
porters to have a chance for the s390x port to be released with Stretch.

Thanks,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
***@aurel32.net http://www.aurel32.net
Mathieu Malaterre
2016-10-01 11:40:01 UTC
Permalink
On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
[...]
On the other hand, some packages dropped support for PowerPC32 like Mono
but this isn't a concern for most users, I would say.
[...]
However I need to mention that the specific ppc/mono issue is in fact
short version is that this issue only happen because we build the
ppc32 mono version on a ppc64 kernel, I know that since I did debug
this issue.
Which, if I read the bug correctly, is a yet another case of a bogus
build system looking at characteristics of the machine it's compiled on
rather than baseline of the arch.
Well the bug is really upstream: one cannot assume page size at
compilation time. But that is a different story.
And, per your own work, it's +patch +fixed-upstream.
Wow ! In fact I just realize my patch was against git/master at the
time, and was never backported. Need to get this fixed ASAP.
I have not heard from the ppc64el porters, but I suspect ppc64 will
not be a release arch. So you need to take into consideration that for
powerpc to remain a release arch, one need minimal working ppc64 port.
Could we solve the situation of ppc64 for Stretch, could it be moved
to official release arch ?
What would you need ppc64 for? Unlike i386, powerpc includes 64-bit
linux-image-4.7.0-1-powerpc - Linux 4.7 for uniprocessor 32-bit PowerPC (signed)
linux-image-4.7.0-1-powerpc-smp - Linux 4.7 for multiprocessor 32-bit PowerPC (signed)
linux-image-4.7.0-1-powerpc64 - Linux 4.7 for 64-bit PowerPC (signed)
linux-image-4.7.0-1-686-pae-unsigned - Linux 4.7 for modern PCs
linux-image-4.7.0-1-686-unsigned - Linux 4.7 for older PCs
linux-image-4.7.0-1-grsec-686-pae - Linux 4.7 for modern PCs, Grsecurity protection
linux-image-4.7.0-1-686 - Linux 4.7 for older PCs (signed)
linux-image-4.7.0-1-686-pae - Linux 4.7 for modern PCs (signed)
Note the joke: "for modern PCs". Unless you do embedded it takes some
serious dumpster diving to find a machine not better served by an -amd64
kernel (and thus multiarch). The i386 architecture is not self-contained,
powerpc is.
Thus, there is no need for ppc64 (userland), as long as powerpc has the
toolchain to build 64-bit kernels. And that's a primary target for gcc
upstream.
Great ! That's all I wanted to check. I was worried we would need
buildd(s) running on ppc64el.

Loading...