Re: debian-installer now available in Ports

[Steven Chamberlain]

I've set up some additional jobs at
http://jenkins.kfreebsd.eu/jenkins/view/cd/

and after much trial-and-error, there are now (untested) sid netinst
images built for:
hurd-i386 kfreebsd-amd64 kfreebsd-i386 powerpc

You can find the .iso images within each job's workspace e.g.:
http://jenkins.kfreebsd.eu/jenkins/view/cd/job/debian-cd_sid_hurd-i386/ws/build/

It's building on a kfreebsd-amd64 host, in a jessie-kfreebsd chroot,
with current Git master of debian-cd, my patches for #860187 and
#860204 applied, and the attached diff against CONF.sh.  I started each
build like this:

$ export CODENAME=sid
$ export ARCHES=hurd-i386
$ CONF.sh && ./build.sh

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/CONF.sh b/CONF.sh
index 99e58ad..08ffbd7 100644
--- a/CONF.sh
+++ b/CONF.sh
@@ -62,11 +62,15 @@ export BASEDIR=`pwd`
 # export CDNAME=debian
 
 # Building $codename cd set ...
-export CODENAME=stretch
+#export CODENAME=stretch
 
 # By default use Debian installer packages from $CODENAME
 if [ -z "$DI_CODENAME" ]; then
-	export DI_CODENAME=$CODENAME
+	if [ "${CODENAME}" = "jessie-kfreebsd" ]; then
+		export DI_CODENAME=${CODENAME}-proposed-updates
+	else
+		export DI_CODENAME=${CODENAME}
+	fi
 fi
 # If you want backported d-i (e.g. by setting
 # DI_CODENAME=jessie-backports, then you'll almost definitely also
@@ -86,7 +90,7 @@ fi
 #export DI_WWW_HOME=default
 
 # Version number, "2.2 r0", "2.2 r1" etc.
-export DEBVERSION="9.0"
+export DEBVERSION="unofficial"
 
 # Official or non-official set.
 # NOTE: THE "OFFICIAL" DESIGNATION IS ONLY ALLOWED FOR IMAGES AVAILABLE
@@ -119,17 +123,17 @@ fi
 #	  images, however. Also, if you are using an NFS partition for
 #	  some part of this, you must use this option.
 # Paths to the mirrors
-export MIRROR=/srv/mirror/debian
+export MIRROR=/srv/ftp.debian.org
 
 # Path of the temporary directory
-export TDIR=/srv/mirror/tmp
+export TDIR=/home/cd/tmp
 
 # Path where the images will be written
-export OUT=/srv/mirror/debian-cd-test
+export OUT=/home/cd/out
 
 # Where we keep the temporary apt stuff.
 # This cannot reside on an NFS mount.
-export APTTMP=/srv/mirror/tmp/apt
+export APTTMP=$TDIR/apt
 
 # Do I want to have NONFREE merged in the CD set
 # export NONFREE=1
@@ -164,7 +168,9 @@ export CONTRIB=1
 # Note that on the CDs it will not be visible where packages came from:
 # from the released archive or from proposed updates archive.
 # NOTE: intended to be used for pre-release testing, not for publication!
-#export PROPOSED_UPDATES=$CODENAME-proposed-updates
+if [ "${CODENAME}" = "jessie-kfreebsd" ]; then
+	export PROPOSED_UPDATES=$CODENAME-proposed-updates
+fi
 
 # Sparc only : bootdir (location of cd.b and second.b)
 # export BOOTDIR=/boot
@@ -175,7 +181,7 @@ export CONTRIB=1
 # Use this to force copying the files instead of symlinking or hardlinking
 # them. This is useful if your destination directories are on a different
 # partition than your source files.
-# export COPYLINK=1
+export COPYLINK=1
 
 # Options
 # export MKISOFS=mkisofs
@@ -190,6 +196,12 @@ export CONTRIB=1
 #export i386_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso md5,sha1"
 #export amd64_MKISOFS="xorriso"
 #export amd64_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso md5,sha1"
+export hurd_i386_MKISOFS="xorriso"
+export hurd_i386_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso sha256"
+export kfreebsd_i386_MKISOFS="xorriso"
+export kfreebsd_i386_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso sha256"
+export kfreebsd_amd64_MKISOFS="xorriso"
+export kfreebsd_amd64_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso sha256"
 
 # Keyring (defaults):
 #ARCHIVE_KEYRING_PACKAGE=debian-archive-keyring
@@ -233,7 +245,7 @@ ATTEMPT_FALLBACK=yes
 # STICK4GB:  4GB USB stick or similar
 # STICK8GB:  8GB USB stick or similar
 # CUSTOM:up to you - specify a size to go with it (in 2K blocks)
-export DISKTYPE=CD
+export DISKTYPE=NETINST
 #export DISKTYPE=CUSTOM
 #export CUSTOMSIZE=
 # If you want to over-ride this choice (e.g. to make a larger version of a given disk),
@@ -242,7 +254,7 @@ export DISKTYPE=CD
 # export FORCE_CD_SIZE1= to change the size of disk 1 (only)
 
 # Extra variants to enable. See docs/README.variants for more information.
-export VARIANTS=
+export VARIANTS=light
 
 # We don't want certain packages to take up space on CD1...
 #export EXCLUDE1=exclude
@@ -375,8 +387,8 @@ export SNAPURL=Debian=http://snapshot.debian.org/archive/debian/SNAPDATETIME/
 # INSTALLER_CD=0: nothing special (default)
 # INSTALLER_CD=1: just add debian-installer (use TASK=debian-installer)
 # INSTALLER_CD=2: add d-i and base (use TASK=debian-installer+kernel)
-#export INSTALLER_CD=2
-#export TASK=debian-installer+kernel
+export INSTALLER_CD=2
+export TASK=debian-installer+kernel
 
 # Parameters to pass to kernel (or d-i) when the CD boots. Not currently
 # supported for all architectures.
@@ -387,7 +399,7 @@ export 

Re: debian-installer now available in Ports

[Steve McIntyre]

On Wed, Apr 12, 2017 at 01:55:08PM +0100, Steven Chamberlain wrote:
>John Paul Adrian Glaubitz wrote:
>> Thus, I was wondering whether any volunteers would be willing to help 
>> building
>> ISO images for the various architectures.
>
>I'm already doing this for kfreebsd-amd64, but only the jessie-kfreebsd
>suite:
>http://jenkins.kfreebsd.eu/jenkins/view/cd/job/debian-cd_jessie-kfreebsd/lastBuild/console
>and I had to patch debian-cd before it worked.  (Didn't yet find time to
>file bugs or submit those patches).

Please post them!

>I could probably set up similar jobs for kfreebsd-* sid now.
>
>> It's not necessary to run debian-cd on the same architecture as the
>> target architecture of the ISO images.

Exactly. There are sometimes difficulties with the tools needed to set
up boot files etc., but they tend to be portable.

>I did not even realise that.  So I will add kfreebsd-i386 next.
>
>I expect there might be problems trying to build linux arches from a
>kfreebsd host.  But we should try to find out, and then maybe fix it.

We were happily building kfreebsd-* images from a Linux host, so I'd
expect it to work OK.

I've offered before: I don't have the time personally to work on
building ports images, but I'm more than happy to help other people
getting them building on our official infrastructure...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?

Re: debian-installer now available in Ports

[Samuel Thibault]

Steven Chamberlain, on mer. 12 avril 2017 13:55:08 +0100, wrote:
> I expect there might be problems trying to build linux arches from a
> kfreebsd host.  But we should try to find out, and then maybe fix it.

FWIW, I have been building hurd-i386 images from a linux box for a long
time without problems.

Samuel

Re: debian-installer now available in Ports

[Steven Chamberlain]

Hello,

John Paul Adrian Glaubitz wrote:
> Thus, I was wondering whether any volunteers would be willing to help building
> ISO images for the various architectures.

I'm already doing this for kfreebsd-amd64, but only the jessie-kfreebsd
suite:
http://jenkins.kfreebsd.eu/jenkins/view/cd/job/debian-cd_jessie-kfreebsd/lastBuild/console
and I had to patch debian-cd before it worked.  (Didn't yet find time to
file bugs or submit those patches).

I could probably set up similar jobs for kfreebsd-* sid now.

> It's not necessary to run debian-cd on the same architecture as the
> target architecture of the ISO images.

I did not even realise that.  So I will add kfreebsd-i386 next.

I expect there might be problems trying to build linux arches from a
kfreebsd host.  But we should try to find out, and then maybe fix it.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Bug#845193: dpkg: recent -specs PIE changes break openssl

[Adrian Bunk]

On Thu, Nov 24, 2016 at 04:35:28PM +0100, Guillem Jover wrote:
>...
> On Thu, 2016-11-24 at 14:52:33 +, Thorsten Glaser wrote:
>...
> > Worse, they break *differently* on whether…
> > 
> > >Precisely to make the behavior consistent on all architectures, dpkg
> > >enables PIE (conditionally if no other flags marks it as to be
> > >disabled) on all architectures were gcc has not enabled this by
> > >default.
> > 
> > … that. And that is just plain wrong. Either dpkg should inject
> > -specs= stuff on all architectures or on none. Differing like this
> > just invites hidden and hard to track down bugs.
> 
> As long as gcc enables PIE on a subset, there will be need to inject
> some form of specs on either subset of those arches, either on
> hardening=+pie or on hardening=-pie, pick yout poison. :(
>...

Both gcc and dpkg playing with PIE just increased the number of bugs
without bringing any benefit.

I fixed many PIE related issues in packages when the gcc change was.

And now we got a new batch of FTBFS bugs for cases where the
dpkg specs change broke packages using "hardening=+all,-pie".

Please do the following:
1. discuss with porters whether PIE is working on their architecture
2. gcc and dpkg maintainers have to agree which package enables PIE

> Thanks,
> Guillem

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#845193: dpkg: recent -specs PIE changes break openssl

[Thorsten Glaser]

Guillem Jover dixit:

>> Yes, but they *do* break anything that
>> - acts on the CFLAGS (and LDFLAGS) variables
>> - uses klcc or other compiler wrappers that don't understand -specs
>> - uses clang or pcc or whatever other compilers
>
>The default dpkg build flags have always been tied to the specific
>language compiler version currently marked as the default (for C that
>would currently be gcc-6).

Sure, but we do have other compilers and compiler wrappers in the
archive, and packages are using them.

>As long as gcc enables PIE on a subset, there will be need to inject
>some form of specs on either subset of those arches, either on
>hardening=+pie or on hardening=-pie, pick yout poison. :(

[…]
>> Either are *much* better than the current way.
>
>Well you and me both, I'm just adapting the dpkg-buildflags to the
>current gcc situation. :/

This sounds to me like we should reassign this to GCC (and remove
all the… well, “offending”, no offence intended, code from dpkg).

>Having a subset of architectures is a pain for maintainers as they

True, so GCC should just enable it on all architectures where it
at all works.

>Well I think we should be enabling all hardening flags directly in
>gcc, but now that we have the specs files I guess it would not be
>too bad to enable them just in dpkg, but I agree either would be
>preferable. :/

OK, thank you.

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Re: Bug#845193: dpkg: recent -specs PIE changes break openssl

[Guillem Jover]

Hi!

On Thu, 2016-11-24 at 14:52:33 +, Thorsten Glaser wrote:
> clone 845193 -1
> reassign -1 dpkg
> retitle -1 dpkg: please do not add -specs= flags only on some architectures
> thanks

I'm afraid I'll have to wontfix this because it is not really
implementable. See below… :/

> Guillem Jover dixit:
> >Those specs files should make it possible to build stuff with PIE
> 
> Yes, but they *do* break anything that
> - acts on the CFLAGS (and LDFLAGS) variables
> - uses klcc or other compiler wrappers that don't understand -specs
> - uses clang or pcc or whatever other compilers

The default dpkg build flags have always been tied to the specific
language compiler version currently marked as the default (for C that
would currently be gcc-6).

> Worse, they break *differently* on whether…
> 
> >Precisely to make the behavior consistent on all architectures, dpkg
> >enables PIE (conditionally if no other flags marks it as to be
> >disabled) on all architectures were gcc has not enabled this by
> >default.
> 
> … that. And that is just plain wrong. Either dpkg should inject
> -specs= stuff on all architectures or on none. Differing like this
> just invites hidden and hard to track down bugs.

As long as gcc enables PIE on a subset, there will be need to inject
some form of specs on either subset of those arches, either on
hardening=+pie or on hardening=-pie, pick yout poison. :(

Injecting just the raw -fno-PIE and -no-pie does not work, so when you
need to disable those we need to pass via specs files.

> Please get an agreement with the GCC maintainer on how to proceed
> from here.
>
> Personally, I’d still prefer for GCC to behave as on other systems,
> i.e. not to enable PIE by default, and to have it done completely
> within dpkg, but I can *also* live with it being done exclusively
> in GCC.
> 
> Either are *much* better than the current way.

Well you and me both, I'm just adapting the dpkg-buildflags to the
current gcc situation. :/

> >Also BTW the gcc maintainer asked that porters
> >interested could request PIE to be enabled by default in gcc.
> 
> What difference does it make on whether GCC or dpkg enables PIE?

It means it should at least get the same behavior from gcc as all
official ports, it is more transparent and should not suffer from
unbalanced passing of CFLAGS w/o LDFLAGS or the other way around,
for example. Of course that does not mean that package might still
not fail, in case they try to link PIE code into a shared library
or similar.

> The two last quote sections make it clear that any architecture
> that currently has PIE enabled in dpkg should have it enabled in
> GCC in the first place.

Enabling new build flags in dpkg has always been done globally,
except for specific blacklists on things that were completely broken
in the toolchain, which have then been enabled eventually when they
got fixed.

Having a subset of architectures is a pain for maintainers as they
get different resulting objects depending on the architectures, it
also changes the semantics from before the gcc default change, as
previously explicitly enabling PIE was global, and now would be for
a subset.

Or worse, the new semantics would need to be that by default you get
PIE on a subset but if you pass hardening=+pie on each package you get
it enabled globally? Pretty unintuitive IMO.

> (Did dpkg enable that on porters’ requests?
> It does not look like that to me. This smells like overstepping
> boundaries.)

If porters are unhappy about this, I'll revert PIE for those ports in
dpkg, but this will not make the situation less of a mess, hardening=-pie
will still need the specs files on ports were gcc enables it by default,
and hardening=+pie might need them on the ones that do not…

> tl;dr: I don’t care as much _which_ of GCC xor dpkg does it,
> as long as only one does it. FFS, just enable it on all of them
> unless known to absolutely not work; that’d still be better than
> the current mess.

Well I think we should be enabling all hardening flags directly in
gcc, but now that we have the specs files I guess it would not be
too bad to enable them just in dpkg, but I agree either would be
preferable. :/

Thanks,
Guillem

Re: Booting in text mode

[Darac Marjal]

On Thu, Nov 24, 2016 at 03:58:51PM +0100, Francesco Pietra wrote:

Hallo
Having upgraded amd64/gnome to jessie, booting occurs graphically while I want
graphics to come only when absolutely needed. Also, nautilus of gnome3 is
absolutely hostile to scientific use as a quick replacement of shell commands.
Too "intelligent". All that toward mass use, ok, but where is a recipe to boot
in text mode? My old, simple .Xsession and killing gdm do not work anymore and
I am short of time for such issues .


The preferred method for this, under systemd is to run:

# systemctl set-default multi-user.target

This should set the default boot mode to non-graphical, multi-user mode.

When you're ready to start graphical mode, run:

# systemctl isolate graphical.target

(You could, of course, try simply running the x-display-manager of your 
choice, but by switching target, any other units that are required for 
graphical mode are also run).




Or give an alternative to replace gnome3 with xfce. The latter on my work
station allows booting in text mode and its file manager is not too
intelligent, just useful for scientific use.

Thanks.

francesco pietra




--
For more information, please reread.

Re: Bug#845193: dpkg: recent -specs PIE changes break openssl

[Thorsten Glaser]

clone 845193 -1
reassign -1 dpkg
retitle -1 dpkg: please do not add -specs= flags only on some architectures
thanks

Guillem Jover dixit:

>> I cannot build openssl1.0 any longer. Downgrading all binary
>> packages from src:dpkg to 1.18.10 makes the build succeed.

Interestingly enough, src:openssl (1.1) works, so…

>So, I think I'll reassign this to openssl1.0, if no other feedback

… this is probably legit. But I would *still* like to raise
another point.

>Those specs files should make it possible to build stuff with PIE

Yes, but they *do* break anything that
- acts on the CFLAGS (and LDFLAGS) variables
- uses klcc or other compiler wrappers that don't understand -specs
- uses clang or pcc or whatever other compilers

Worse, they break *differently* on whether…

>Precisely to make the behavior consistent on all architectures, dpkg
>enables PIE (conditionally if no other flags marks it as to be
>disabled) on all architectures were gcc has not enabled this by
>default.

… that. And that is just plain wrong. Either dpkg should inject
-specs= stuff on all architectures or on none. Differing like this
just invites hidden and hard to track down bugs.

Please get an agreement with the GCC maintainer on how to proceed
from here.

Personally, I’d still prefer for GCC to behave as on other systems,
i.e. not to enable PIE by default, and to have it done completely
within dpkg, but I can *also* live with it being done exclusively
in GCC.

Either are *much* better than the current way.

>if no other feedback is provided showing that this is a problem in
>dpkg itself, such as PIE not working at all there, and a request to
>disable it for x32 in dpkg as non-functional.

This can be done just as well on the GCC side.

>Also BTW the gcc maintainer asked that porters
>interested could request PIE to be enabled by default in gcc.

What difference does it make on whether GCC or dpkg enables PIE?

The two last quote sections make it clear that any architecture
that currently has PIE enabled in dpkg should have it enabled in
GCC in the first place. (Did dpkg enable that on porters’ requests?
It does not look like that to me. This smells like overstepping
boundaries.)


tl;dr: I don’t care as much _which_ of GCC xor dpkg does it,
as long as only one does it. FFS, just enable it on all of them
unless known to absolutely not work; that’d still be better than
the current mess.

Thanks,
//mirabilos
-- 
[00:02]  gecko: benutzt du emacs ?
[00:03]  nö  [00:03]  nur n normalen mac
[00:04]  argl   [00:04]  ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)

Re: Samba version in armhf?

[Julie Montoya]

On Tuesday 22 Nov 2016, Jo L wrote:
> I was trying bananian 16.04 which is based on Debian Jessie armhf on my
> Banana Pro, and it turned out that the Samba version 4.2.10 I got is pretty
> much outdated.
> Looking at https://packages.debian.org/search?arch=armhf=samba I
> guess this Is because there is no newer version available for Debian armhf
> in general. Is there any reason to stick to this version? How can I get a
> newer one (not compiling  it myself)?
> Thanks & Best regards, Joachim

Ask someone else to compile it for you :)

Debian Jessie has only 4.2.10  (plus security fixes)  on all architectures, not 
just armhf.  Debian Stretch has 4.4.7 on all architectures including armhf, so 
it probably isn't anything intrinsically to do with the ARM architecture.  So 
you *might* be able to install the Stretch version.

If it depends on something else newer than Jessie, though, you probably are 
going to end up having to compile it yourself anyway .  

-- 
JKLM
delta echo bravo six four at earthshod dot co dot uk

Re: Release Architectures for Debian 9 'Stretch'

[Jonathan Wiltshire]

On 2016-10-31 13:31, Jonathan Wiltshire wrote:

The only change from Jessie is the removal of powerpc as a release
architecture.


...and adding of mips64el. Oops.


--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits

Re: Enabling PIE by default for Stretch

[Bálint Réczey]

Hi Maximiliano,

2016-10-10 14:21 GMT+02:00 Maximiliano Curia :
> ¡Hola Niels!
>
> El 2016-10-10 a las 05:44 +, Niels Thykier escribió:
>>
>> Niels Thykier:
>>>
>>> As brought up on the meeting last night, I think we should try to go for
>>> PIE by default in Stretch on all release architectures!  * It is a
>>> substantial hardening feature  * Upstream has vastly reduced the performance
>>> penalty for x86  * The majority of all porters believe their release
>>> architecture isready for it.  * We have sufficient time to solve any
>>> issues or revert if it turns outto be too problematic.
>
>
>>> [...]
>
>
>>>  * Deadline for major concerns:  Fri, 7th of October 2016.
>
>
>> It appears that there were no major concerns.  I will follow up #835148
>> and request PIE by default for the following architectures.
>
>
>> * amd64 * arm64 * armel * armhf * i386 * mips * mips64el * mipsel *
>> ppc64el * s390x
>
>
> Such a change will produce unneeded FTBFS's in libraries using -fPIC (such
> as qt5 and all it's dependencies).
>
> Afaik, -fPIC is stronger than -fPIE, at the same time, -fPIE is incompatible
> with -fPIC and -fPIE makes little sense in shared libraries.
>
> And while a single patch should be trivial, I fear they would be many
> specific ones.

Have you seen the results of the test-rebuild performed with the
changed defaults?

I have put together a page with related links and information where
you can find the rebuild results, too:

 https://wiki.debian.org/Hardening/PIEByDefaultTransition

Cheers,
Balint

Re: Enabling PIE by default for Stretch

[Maximiliano Curia]

¡Hola Niels!

El 2016-10-10 a las 05:44 +, Niels Thykier escribió:

Niels Thykier:
As brought up on the meeting last night, I think we should try to go for 
PIE by default in Stretch on all release architectures! 
 * It is a substantial hardening feature 
 * Upstream has vastly reduced the performance penalty for x86 
 * The majority of all porters believe their release architecture is 
   ready for it. 
 * We have sufficient time to solve any issues or revert if it turns out 
   to be too problematic.



[...]



 * Deadline for major concerns:  Fri, 7th of October 2016.


It appears that there were no major concerns.  I will follow up #835148 
and request PIE by default for the following architectures.


* amd64 
* arm64 
* armel 
* armhf 
* i386 
* mips 
* mips64el 
* mipsel 
* ppc64el 
* s390x


Such a change will produce unneeded FTBFS's in libraries using -fPIC (such as 
qt5 and all it's dependencies).


Afaik, -fPIC is stronger than -fPIE, at the same time, -fPIE is incompatible 
with -fPIC and -fPIE makes little sense in shared libraries.


And while a single patch should be trivial, I fear they would be many specific 
ones.


Happy hacking,
--
"If a thing is done wrong often enough, it becomes right" -- Leahy's Law
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Re: Enabling PIE by default for Stretch

[Niels Thykier]

Niels Thykier:
> Hi,
> 
> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
>  * It is a substantial hardening feature
>  * Upstream has vastly reduced the performance penalty for x86
>  * The majority of all porters believe their release architecture is
>ready for it.
>  * We have sufficient time to solve any issues or revert if it turns out
>to be too problematic.
> 
> [...]
> 
>  * Deadline for major concerns:  Fri, 7th of October 2016.
> 
> [...]
> 
> Thanks,
> ~Niels
> 
> [...]

It appears that there were no major concerns.  I will follow up #835148
and request PIE by default for the following architectures.

 * amd64
 * arm64
 * armel
 * armhf
 * i386
 * mips
 * mips64el
 * mipsel
 * ppc64el
 * s390x

Should you be a porter for an architecture not listed above and want PIE
by default on your architecture, please follow up on #835148 as well (or
a file a new wishlist bug if #835148 is closed when you do it)

NB: The omission of powerpc was intentional as there were no porters
supporting it during the roll-call.

Thanks,
~Niels

Re: Architecture qualification meeting, scheduling

[Niels Thykier]

Adrian Bunk:
> [ fullquote adding -ports, for people not following -release or -devel ]
> 
> [...]
> 
> Is https://release.debian.org/stretch/arch_qualify.html the up-to-date 
> information available to you, and the "candidate" line how a decision
> would look like based on the current information?
> 
> cu
> Adrian
> 

It reflects all the issues we are aware of at the present time (except
for archive-{coverage,uptodate}, which can be seen from
https://buildd.debian.org/stats/).

If you believe we have overlooked an issue or an update, please do not
hesitate to let us know. :)

Thanks,
~Niels

Re: Architecture qualification meeting, scheduling

[Adrian Bunk]

[ fullquote adding -ports, for people not following -release or -devel ]

On Fri, Oct 07, 2016 at 06:35:07PM +0100, Jonathan Wiltshire wrote:
> Hi,
> 
> I am arranging the final architecture qualification meeting for Stretch.
> This is primarily of interest to the release team, but I will also take
> input from porters.
> 
> As the schedule is currently wide open, please express your availability in
> the linked Doodle poll. There are 56 slots available, mostly in the European
> evening but a handful are daytime coinciding with the Cambridge
> mini-Debconf.
> 
> Porters, please note your architecture in your response ("name (arch)").
> 
> About the format of the meeting:
> Much like the Jessie meeting, it will be held via IRC in
> oftc.net/#debian-release and will be primarily a discussion amongst the
> release team. We will evaluate each port on the most up-to-date information
> available to us, and determine if it will be a release architecture for
> Stretch. We may ask for clarification from porters who are present if there
> are points at issue, but we ask that you are read-only otherwise.
> 
> http://doodle.com/poll/362qvb89cvu43d4z

Is https://release.debian.org/stretch/arch_qualify.html the up-to-date 
information available to you, and the "candidate" line how a decision
would look like based on the current information?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Porter roll call for Debian Stretch

[Ben Hutchings]

On Sat, 2016-10-01 at 15:48 +0200, John Paul Adrian Glaubitz wrote:
> On 10/01/2016 02:17 PM, Ben Hutchings wrote:
> > 
> > > 
> > > This isn't the case for PowerPC32 where upstream development is still very
> > > active because it's part of the PowerPC kernel which is maintained by
> > > IBM.
> > 
> > This is not at all true.  My experience is that IBM doesn't even build-
> > test 32-bit configurations, as evidenced by several stable updates
> > causing FTBFS in Debian.
> 
> They care enough that they are fixing bugs. Just recently, a bug in the
> PowerPC kernel was fixed that affected 32-bit embedded PowerPCs only.

$ git log --author=ibm --grep='ppc-?32|powerpc-?32|32-bit' -i -E arch/powerpc

finds me fewer than ten commits per year.

> > 
> > > 
> > > As for SPARC, Oracle is actually now heavily investing in Linux SPARC
> > > support, so even SPARC is getting back into shape which is why I hope
> > > we can add sparc64 as an official port soon.
> > [...]
> > 
> > Oracle cares about Solaris on SPARC, not Linux on SPARC.
> 
> Well, then you know more than the people at Oracle that I am talking to.
[... much evidence of Oracle supporting Linux on SPARC ...]

OK, I accept this has changed, but I'm quite surprised - Oracle is
ruthlessly commercial, and I'm mystified as to who they expect to buy
it.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.

signature.asc
Description: This is a digitally signed message part

Re: Porter roll call for Debian Stretch

[Ben Hutchings]

On Fri, 2016-09-30 at 22:34 +0200, John Paul Adrian Glaubitz wrote:
> On 09/30/2016 09:04 PM, Niels Thykier wrote:
> > 
> > As for "porter qualification"
> > =
> > 
> > We got burned during the Jessie release, where a person answered the
> > roll call for sparc and we kept sparc as a release architecture for
> > Jessie.  However, we ended up with a completely broken and unbootable
> > sparc kernel.
> 
> To be fair, this happened because the upstream kernel development for
> SPARC came to an almost complete stop. There was basically only David
> Miller working on the port which turned out not to be enough.
> 
> This isn't the case for PowerPC32 where upstream development is still very
> active because it's part of the PowerPC kernel which is maintained by
> IBM.

This is not at all true.  My experience is that IBM doesn't even build-
test 32-bit configurations, as evidenced by several stable updates
causing FTBFS in Debian.

> PowerPC32 is also still quite popular which is why it still sees
> quite some testing in the wild. There are still new PowerPC32 designs
> based on embedded CPUs (FreeScale and the like).

Which are very different from the Power Macs and similar platforms that
most Debian powerpc users care about.

> As for SPARC, Oracle is actually now heavily investing in Linux SPARC
> support, so even SPARC is getting back into shape which is why I hope
> we can add sparc64 as an official port soon.
[...]

Oracle cares about Solaris on SPARC, not Linux on SPARC.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.


signature.asc
Description: This is a digitally signed message part

Re: Porter roll call for Debian Stretch

[Ben Hutchings]

On Sat, 2016-10-01 at 02:28 +0200, Adam Borowski wrote:
> On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote:
[...]
> > 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
> kernels so users don't need multiarch:
[...]

This is only the case because ppc64 has a lower level of support
(unofficial port) than powerpc (release architecture).  The 64-bit
kernel package should be dropped once powerpc is at the same or lower
level of support than ppc64 - just as we've done for i386, s390 and
sparc.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.


signature.asc
Description: This is a digitally signed message part

Re: Porter roll call for Debian Stretch

[Mathieu Malaterre]

On Sat, Oct 1, 2016 at 2:28 AM, Adam Borowski  wrote:
> On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote:
>> On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
>>  wrote:
>> [...]
>> > 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
>> pretty interesting. The long thread is on debian-powerpc@l.d.o but the
>> 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
> kernels so users don't need multiarch:
>
> powerpc has:
> 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)
> i386 has:
> 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.

Re: Porter roll call for Debian Stretch

[Adam Borowski]

On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote:
> On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
>  wrote:
> [...]
> > 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
> pretty interesting. The long thread is on debian-powerpc@l.d.o but the
> 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.

And, per your own work, it's +patch +fixed-upstream.

> 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
kernels so users don't need multiarch:

powerpc has:
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)
i386 has:
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.

-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Re: Porter roll call for Debian Stretch

[Milan Kupcevic]

On 09/20/2016 05:46 PM, John Paul Adrian Glaubitz wrote:
> On 09/20/2016 11:16 PM, Niels Thykier wrote:
>>- powerpc: No porter (RM blocker)
> 
> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
> maintaining powerpcspe which is very similar to powerpc.
> 


Thank you Adrian for stepping up. You will have my support in this
endeavor for the Stretch release.

Milan




signature.asc
Description: OpenPGP digital signature

Re: Porter roll call for Debian Stretch

[Mathieu Malaterre]

Adrian,

On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
 wrote:
[...]
> On the other hand, some packages dropped support for PowerPC32 like Mono
> but this isn't a concern for most users, I would say.
[...]

Thanks very much for stepping up as porter, you have my vote !

However I need to mention that the specific ppc/mono issue is in fact
pretty interesting. The long thread is on debian-powerpc@l.d.o but the
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.

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 ?

-M

Re: Porter roll call for Debian Stretch

[John Paul Adrian Glaubitz]

On 09/30/2016 09:04 PM, Niels Thykier wrote:
> As for "porter qualification"
> =
> 
> We got burned during the Jessie release, where a person answered the
> roll call for sparc and we kept sparc as a release architecture for
> Jessie.  However, we ended up with a completely broken and unbootable
> sparc kernel.

To be fair, this happened because the upstream kernel development for
SPARC came to an almost complete stop. There was basically only David
Miller working on the port which turned out not to be enough.

This isn't the case for PowerPC32 where upstream development is still very
active because it's part of the PowerPC kernel which is maintained by
IBM. PowerPC32 is also still quite popular which is why it still sees
quite some testing in the wild. There are still new PowerPC32 designs
based on embedded CPUs (FreeScale and the like).

As for SPARC, Oracle is actually now heavily investing in Linux SPARC
support, so even SPARC is getting back into shape which is why I hope
we can add sparc64 as an official port soon.

>   That was an embarrassment to the Debian stability and quality
>   reputation that I never - ever - want to repeat.

Well, mistakes happen and while I think it's good and important to learn
from mistakes, we should not dramatize such issues. We have had worse
issues like the OpenSSL entropy bug, for example, and we still managed
to cope with the fallout in a very professional manner.

> (For avoidance of doubt: I want to ensure that release architectures
> "just work(tm)" and I have no desire to blame that volunteer).

I don't think there is any concern regarding the powerpc port in this
regard. wanna-build shows almost 11800 packages that are up-to-date
which is a good indicator that the port is in good shape, both regarding
the toolchain and various source packages which need architecture-specific
adaptations like LibreOffice or JavaScript packages.

On the other hand, some packages dropped support for PowerPC32 like Mono
but this isn't a concern for most users, I would say.

> If I am to support powerpc as a realease architecture for Stretch, I
> need to know that there are *active* porters behind it committed to
> keeping it in the working.  People who would definitely catch such
> issues long before the release.  People who file bugs / submit patches etc.

I agree and I'm actually doing that all the time. I always run unstable
on my machines and constantly check wanna-build for build issues and
report them upstream whenever they occur. I have helped dozens of such
issues on "sh4" and "sparc64", for example.

> If you need inspiration: Have a look at the [automatic testing of
> ppc64el images].  Or the [arm64 machines on ci.debian.net] with
> comparable results to amd64.  This is the sort of thing that inspires
> confidence in the ports for me and I think we should have vastly more of.

I agree that would be nice to have. However, to be fair, we don't have
that type of testing for all release architectures and to my current
knowledge, automated testing of installation images is not a criteria
for an architecture to maintain release status.

My main argument for why we should keep the powerpc port is its
popularity. If we look at the numbers from popcon [1], powerpc
is still the fourth-most-popular port and I think we would disappoint
many users if we were to drop the port for Stretch. Note that while
ports like "arm64" or "ppc64el" receive lots of support, especially
from companies, they still haven't reached the same popularity as the
powerpc port for example. Heck, there are even more users for "hppa"
and "sparc64" which both are just unofficial ports architectures.

Thanks,
Adrian

> [1] http://popcon.debian.org/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Porter roll call for Debian Stretch

[Niels Thykier]

Niels Thykier:
> [...]
> 
> As for "porter qualification"
> =
> 
> We got burned during the Jessie release, where a person answered the
> roll call for sparc and we kept sparc as a release architecture for
> Jessie.  However, we ended up with a completely broken and unbootable
> sparc kernel.
> 
>   That was an embarrassment to the Debian stability and quality
>   reputation that I never - ever - want to repeat.
> 
> (For avoidance of doubt: I want to ensure that release architectures
> "just work(tm)" and I have no desire to blame that volunteer).
> 
> 
> [...]
> 

I have been reminded of my inaccurate memory.  The broken sparc kernel
was released in Wheezy (and discovered during Jessie).  The roll call
for Jessie happened shortly after Wheezy release but before DSA
discovered the broken kernel.

Nonetheless, the core argument still stands.

Thanks,
~Niels

Re: Porter roll call for Debian Stretch

[Adam D. Barratt]

On Fri, 2016-09-30 at 19:04 +, Niels Thykier wrote:
> As for "porter qualification"
> =
> 
> We got burned during the Jessie release, where a person answered the
> roll call for sparc and we kept sparc as a release architecture for
> Jessie.  However, we ended up with a completely broken and unbootable
> sparc kernel.

fwiw, you mean wheezy.

Regards,

Adam

Re: Porter roll call for Debian Stretch

[Niels Thykier]

John Paul Adrian Glaubitz:
> On 09/30/2016 06:08 PM, Niels Thykier wrote:
>> I strongly /suspect/ that "no porters" for powerpc will imply the
>> removal of powerpc for Stretch.  It may or may not be moved to ports
>> (assuming someone is willing to support it there).
> 
> So, I take this as a "no" for the offer from me and Christoph Biedel to take
> over the powerpc port for Stretch?
> 
> [...]
> 
> Thanks,
> Adrian
> 

My statement above was made based on the assumption stated in the first
line of Mathieu's mail, which was "Assume there are no powerpc porters
for Stretch".

As for "porter qualification"
=

We got burned during the Jessie release, where a person answered the
roll call for sparc and we kept sparc as a release architecture for
Jessie.  However, we ended up with a completely broken and unbootable
sparc kernel.

  That was an embarrassment to the Debian stability and quality
  reputation that I never - ever - want to repeat.

(For avoidance of doubt: I want to ensure that release architectures
"just work(tm)" and I have no desire to blame that volunteer).


If I am to support powerpc as a realease architecture for Stretch, I
need to know that there are *active* porters behind it committed to
keeping it in the working.  People who would definitely catch such
issues long before the release.  People who file bugs / submit patches etc.


If you need inspiration: Have a look at the [automatic testing of
ppc64el images].  Or the [arm64 machines on ci.debian.net] with
comparable results to amd64.  This is the sort of thing that inspires
confidence in the ports for me and I think we should have vastly more of.


Thanks,
~Niels

[automatic testing of ppc64el images]:
 https://lists.debian.org/debian-powerpc/2016/06/msg2.html

[arm64 machines on ci.debian.net]:
 https://ci.debian.net/status/

Re: Porter roll call for Debian Stretch

[Adam Borowski]

On Fri, Sep 30, 2016 at 10:03:47AM +0200, Mathieu Malaterre wrote:
> [Let's assume that we can't find a powerpc porter in time for Stretch.]

Two potential porters stepped up, who might or might not be accepted.

> 1. Will `powperpc` automatically be downgraded to simple port ? Or is
> this also not automated and the port may simply be removed (eg. sparc)
> ?

Removal from the main archive isn't automatic, and assuming no serious
kernel or toolchain breakage, I guess there's no reason for such removal
to be hasty.

On the other hand, place in -ports (aka second-class architectures) isn't
automatic either, and relies on someone doing the work.

> 2. Apart from loosing the automatic debian-installer stuff, what else
> are we going to loose in that scenario ?

Security support and stable release.

-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Re: Enabling PIE by default for Stretch

[Matthias Klose]

[CCing porters, please also leave feedback in #835148 for non-release 
architectures]

On 29.09.2016 21:39, Niels Thykier wrote:
> Hi,
> 
> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
>  * It is a substantial hardening feature
>  * Upstream has vastly reduced the performance penalty for x86
>  * The majority of all porters believe their release architecture is
>ready for it.
>  * We have sufficient time to solve any issues or revert if it turns out
>to be too problematic.
> 
> As agreed on during the [meeting], if there are no major concerns to
> this proposal in general within a week, I shall file a bug against GCC
> requesting PIE by default on all release architectures (with backing
> porters).

please re-use #835148

>   If there are only major concerns with individual architectures, I will
> simply exclude said architectures in the "PIE by default" request.
> 
>  * Deadline for major concerns:  Fri, 7th of October 2016.
> 
> Fall-out
> 
> 
> There will be some possible fall-out from this change:
> 
>  * There will be some FTBFS caused by some packages needing a rebuild
>before reverse dependencies can enable PIE.  These are a subset of
>the bugs filed in the [pie+bindnow] build tests.
> 
>  * Some packages may not be ready for PIE.  These will have to disable
>it per package.  A notable case being ghc (#712228), where we can
>reuse the patch from Ubuntu to work around the issue.
> 
>  * A possible issue from Matthias was that no one has done a large scale
>"PIE by default" on "arm* mips*".
> 
>  * There was concern about whether the 32bit arm architectures would be
>notably affected by the PIE slow down (like x86 used to be).
>It is not measured, but two arm porters did mention a possible
>slowdown
> 
>  * It was questioned whether it made sense to invest time and effort in
>enabling PIE for architectures which would not be included in Buster
>(armel?). Personally, I do not see an issue, if the porters are
>ready to put in the effort required.
> 
> Thanks,
> ~Niels
> 
> [meeting]:
> http://meetbot.debian.net/debian-release/2016/debian-release.2016-09-28-19.00.html
> 
> [pie+bindnow]:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pie-bindnow-20160906=balint%40balintreczey.hu;dist=unstable
> 
> 
> 
> 

Re: Porter roll call for Debian Stretch

[John Paul Adrian Glaubitz]

On 09/30/2016 06:08 PM, Niels Thykier wrote:
> I strongly /suspect/ that "no porters" for powerpc will imply the
> removal of powerpc for Stretch.  It may or may not be moved to ports
> (assuming someone is willing to support it there).

So, I take this as a "no" for the offer from me and Christoph Biedel to take
over the powerpc port for Stretch?

I have quite some experience with working on ports and unlike what Matthias 
claimed,
I'm not just maintaining a few buildds but also getting architecture-specific 
bugs
fixed and so on.

Is there any specific qualification I am missing?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Porter roll call for Debian Stretch

[Christian Zigotzky]

You have a porter for PowerPC. See email from Adrian. ;-)

-- Christian

Sent from my iPhone

> On 30 Sep 2016, at 10:03, Mathieu Malaterre  wrote:
> 
> Hi all,
> 
>> On Fri, Sep 23, 2016 at 3:54 PM, Matthias Klose  wrote:
>>> On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote:
 On 09/20/2016 11:16 PM, Niels Thykier wrote:
   - powerpc: No porter (RM blocker)
>>> 
>>> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
>>> maintaining powerpcspe which is very similar to powerpc.
>> 
>> No, you are not maintaining powerpcspe as a release architecture, and that's
>> something different than building packages for some of the ports 
>> architectures.
>> If you can get powerpcspe accepted as a release architecture, then maybe you
>> gain some credibility to maintain another release architecture ;)
> 
> [Let's assume that we can't find a powerpc porter in time for Stretch.]
> 
> 1. Will `powperpc` automatically be downgraded to simple port ? Or is
> this also not automated and the port may simply be removed (eg. sparc)
> ?
> 2. Apart from loosing the automatic debian-installer stuff, what else
> are we going to loose in that scenario ?
> 
> Thanks much for pointers !
> 
> -M
> 

Re: Porter roll call for Debian Stretch

[Christoph Biedl]

John Paul Adrian Glaubitz wrote...

> On 09/20/2016 11:16 PM, Niels Thykier wrote:
> >- powerpc: No porter (RM blocker)
> 
> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
> maintaining powerpcspe which is very similar to powerpc.

For somewhat personal reasons I'm interested in keeping powerpc in
stretch as well. I certainly cannot take the entire role as a porter,
especially since I don't know what amount of work this implies. But I
am willing to help.

There are two powerpc boxes in my collection, used regulary. One runs
on stable, the other on testing. I haven't done d-i tests but
certainly could do.

Christoph



signature.asc
Description: Digital signature

Re: Porter roll call for Debian Stretch

[John Paul Adrian Glaubitz]

On 09/23/2016 03:54 PM, Matthias Klose wrote:
> No, you are not maintaining powerpcspe as a release architecture, and that's
> something different than building packages for some of the ports 
> architectures.
> If you can get powerpcspe accepted as a release architecture, then maybe you
> gain some credibility to maintain another release architecture ;)

So, what are the criteria to be knighted to become a maintainer of powerpc?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Porter roll call for Debian Stretch

[Matthias Klose]

On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote:
> On 09/20/2016 11:16 PM, Niels Thykier wrote:
>>- powerpc: No porter (RM blocker)
> 
> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
> maintaining powerpcspe which is very similar to powerpc.

No, you are not maintaining powerpcspe as a release architecture, and that's
something different than building packages for some of the ports architectures.
If you can get powerpcspe accepted as a release architecture, then maybe you
gain some credibility to maintain another release architecture ;)

Matthias

Re: Porter roll call for Debian Stretch

[Riku Voipio]

On Tue, Sep 20, 2016 at 09:16:00PM +, Niels Thykier wrote:
> Over all, most people (who answered it) was positive towards the switch.
>  Based on this, I suspect that if we make PIE default in Stretch, then
> we will do it for all architectures.  That said, you will be notified if
> that default changes for Stretch.

Is this just for ASLR, or is ther another motivating factor for PIE?

AFAIK Address space randomizing is not really helpful on 32 bit 
architectures - there is just not that many places to randomize to[1].
At least previously, PIE added ~10% to binary size, which can have a major
performance impact on the 32-bit arm core's that don't have much cache to
begin with.

Riku
[1] https://cseweb.ucsd.edu/~hovav/dist/asrandom.pdf

Re: Porter roll call for Debian Stretch

[John Paul Adrian Glaubitz]

On 09/20/2016 11:16 PM, Niels Thykier wrote:
>- powerpc: No porter (RM blocker)

I'd be happy to pick up powerpc to keep it for Stretch. I'm already
maintaining powerpcspe which is very similar to powerpc.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



signature.asc
Description: OpenPGP digital signature

Re: Porter roll call for Debian Stretch

[Niels Thykier]

ni...@thykier.net:
> 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
> before Friday, the 9th of September:
> 
>  [...]
> 

Thanks to all that replied to the roll call.

We got replies from all architectures except amd64 (Waived), i386
(Waived) and powerpc (problematic).  For the ports that replied, all had
at least 2 or more porters.
  We also got a parallel update from Matthias Klose on the toolchain
state[1].  Based on these we have updated the current state of the
architecture qualification for Stretch[2].

 * Please check that your name is listed as a porter on [2] (see [3]
   for how).  If I missed you, please do not hesitate to let me know.

 * For powerpc, mips and mipsel: Please note that we have added a
   (potentially) blocking issues for your architecture.
   - powerpc: No porter (RM blocker)
   - mips+mipsel: #834147 (RM concern, possibly blocker)


As for the piggy backed question about PIE by default:

 * arm64: 2 OK, 1 did not mention it
 * armel: 3 OK, 1 OK if tested first, 1 was neutral and 1 did not
   mention it
 * armhf: 4 OK, 1 OK if tested first, 1 was neutral and 2 did not
   mention it
 * mips+mipsel+mips64el: 3 OK, 1 OK later, 4 did not mention it.
 * ppc64el: 3 OK, 1 recommended further testing/research
 * s390x: 2 OK

Over all, most people (who answered it) was positive towards the switch.
 Based on this, I suspect that if we make PIE default in Stretch, then
we will do it for all architectures.  That said, you will be notified if
that default changes for Stretch.

Thanks,
~Niels

[1] https://lists.debian.org/debian-release/2016/09/msg00263.html

[2] https://release.debian.org/stretch/arch_qualify.html

[3] Hover your mouse over the number of porters for your architecture
or download the underlying data file from:
  https://release.debian.org/stretch/arch_spec.yaml




signature.asc
Description: OpenPGP digital signature

Re: The (uncalled for) toolchain maintainers roll call for stretch

[Helge Deller]

Hi Matthias,

On 10.09.2016 00:48, Matthias Klose wrote:
> While the Debian Release team has some citation about the quality of the
> toolchain on their status page, it is not one of the release criteria 
> documented
> by the release team.  I'd like to document the status how I do understand it 
> for
> some of the toolchains available in Debian.

> Java/OpenJDK
> 
> 
> For the stretch release openjdk-8 will be fine as the default java
> implementation.  For buster, gcj (to be removed in GCC 7) won't be available
> anymore, and we'll end up with architectures without a java implementation.  
> At
> the same time I'd like to consider to stop providing OpenJDK zero builds,
> leaving powerpc and mips* without a java implementation as well (currently not
> building for openjdk-9).  armhf (not armel) and s390x have Hotspot ports 
> underway.

Can you explain the reason why you consider stopping OpenJDK zero builds?

I'm asking, because on hppa we currently use gcj and we don't have any OpenJDK 
port yet.
My hope was to fix at some point in future the old existing OpenJDK zero port 
patches to get some newer
JDK even if it's slower. With your intention to stop zero builds, we probably 
won't have any
JDK at all...

Thanks,
Helge

Re: The (uncalled for) toolchain maintainers roll call for stretch

[John Paul Adrian Glaubitz]

On 09/10/2016 12:48 AM, Matthias Klose wrote:
> Uncovered by the upstream primary and secondary platforms are the mips*
> architectures and powerpc.  For the uncovered archs I would expect somehow 
> more
> and pro-active Debian maintenance, however I fail to see this happen.
> 
>  - see the history of ftbfs on the buildd page of the gcc-snapshot package
>  - see the status of the gcc-6 package for the pre-release uploads
>  - see the number of RC issues for binutils which came up with 2.27,
>some still open.
>  - Toolchain packages are not watched by porters, and I can't track
>every regression myself, however this is not done well by porters.
> 
> On the recent Porter's call I didn't see any toolchain support for the powerpc
> architecture.

I would actually be happy to take over the powerpc port as its official porter.
I'm already taking care of powerpcspe, so I think it would be a perfect fit.

Let me know what needs to be done to make this happen! I don't want to see
powerpc go too soon.

Cheers,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: The (uncalled for) toolchain maintainers roll call for stretch

[Paul Gevers]

Hi,

On 10-09-16 00:48, Matthias Klose wrote:
>  - fpc not available on powerpc anymore (may have changed recently)

For whatever it is worth, this was finally fixed this week. It is
missing on mips*, ppc64el and s390x though, while at least some form of
MIPS is supported upstream.

Paul



signature.asc
Description: OpenPGP digital signature

Re: Porter roll call for Debian Stretch

[Roger Shimizu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 17 Aug 2016 22:05:06 +0200
ni...@thykier.net wrote:

> 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
> before Friday, the 9th of September:
> 

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretch release (est. end
of 2020):

For armel, I
 - submit device-tree patch to upstream (linux kernel), and backport to debian 
kernel to get more devices supported
 - support new device for d-i and flash-kernel package
 - test most packages on this architecture
 - run Debian stable / testing / unstable system on port that I use regularly
 - triage arch-specific bugs
 - fix arch-related bugs
 - triage d-i bugs
 - test d-i regularly
 - fix d-i bugs/issues

I am a DM.

Altough I enabled -fPIE/-pie for most of my maintaining packages, I'm not sure 
/ I don't have enough knowledge whether it's able to be applied to all packages.
Since all other ARM porters seem agree on this, I believe it definitely 
deserves a try to enable this hardening on stretch.

Cheers,
- -- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXzEFiAAoJEKR4aw2nAzSoAekP/j4eNf0jKvmArPlPbhA7XkBk
/5u9Un4qOHBNcSMAU5YVLHkpnT1CX/C08W+/ctGbB9AnnRwyn8X0uailjedZ13jK
oZYW/kUSwWiPmOkRTeNgFepzuKL+TNsAGgjHOY4ZbzYKC+h9C0UNWwyA77L3GUep
3HA9eTrtxMAAvJPNN4AhOjMeCI3qXIZ+wLKjhT+u/OUETWly8MolBw8PUjjwW6yy
Va7ciRMQf8KL149+Pa/tYFaENoAOV6//3M2QkJyaGbfxJp3xiFFcrlw+kw6J4RyH
vNIewz78nZwN88Y7JWa2EdBVcJr0897REXpDPXK/OpzlWw0R0xqB86jtmHfc+rQJ
IiNGt5Uc4Y3mD04O6AEDDJFJnEQ/QLi8OR8/TuxHiBJ6JTv0m67KsJVgdFqeRnlz
wJqcIQAzTF1iixVXjreVqW6P/+pGNHDbh9APfUz+UV97sZ4tD2BV1K1Rgk7cPDCn
zcpVhkQRy5PzLmK315vb8h9juFDDS/18yzmXwGMnmIhv4+8GBJIQLm5gvk9NuEbw
V/hBC42+fqX6RzGCoV3M8V+A6aLSpG/BcIAQOx8ewVfzMHIFSJmYParCHKXdiX+z
WB8UBt2xCHuzg98jxU80UwR492X9WvKeb6xA8dKqOW22XzsLxaQTe+SLSaGQ7er2
cpuhCpYFDKj/TL6UE2f9
=Vckg
-END PGP SIGNATURE-

Re: Porter roll call for Debian Stretch

[Guillem Jover]

Hi!

On Sun, 2016-08-21 at 08:22:09 +0200, Niels Thykier wrote:
> Kurt Roeckx:
> > On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
> >>  * 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
.

> 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
, 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.

> >>From what I understand, depending on what the .o file is going to
> > be used for you want different things:
> > - 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.

> [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.

That would be
,
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

Re: Porter roll call for Debian Stretch

[Bálint Réczey]

Hi,

2016-08-21 8:22 GMT+02:00 Niels Thykier :
> Kurt Roeckx:
>> On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
>>>  * 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
>> be used for you want different things:
>> - 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).

I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for all
arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.

My assumption was that this set of architectures need the least amount of
additional work since they are tested already in Ubuntu, but I would be happy
if more ports would opt in for PIE.

I plan filing wishlist bugs against dpkg and gcc with the patches
after I rebuilt a
few packages with the defaults.

Cheers,
Balint

[2] https://people.debian.org/~rbalint/ppa/pie-bindnow/


>
> 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.
>

Re: Porter roll call for Debian Stretch

[Niels Thykier]

Kurt Roeckx:
> On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
>>  * 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
> be used for you want different things:
> - 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.

Re: Porter roll call for Debian Stretch

[Niels Thykier]

Martin Michlmayr:
> * ni...@thykier.net  [2016-08-17 22:05]:
>> 2020), please respond with a signed email containing the following
>> before Friday, the 9th of September:
> 
> 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- or to you personally and
> you'll collect the info?
> 

Please send the replies to debian-release. :)

Thanks,
~Niels

Re: Porter roll call for Debian Stretch

[Martin Michlmayr]

* ni...@thykier.net  [2016-08-17 22:05]:
> 2020), please respond with a signed email containing the following
> before Friday, the 9th of September:

Can you please specify where to respond to?  I don't think dozens of
emails to -ports and -devel make any sense.

Maybe debian-release with CC debian- or to you personally and
you'll collect the info?

-- 
Martin Michlmayr
http://www.cyrius.com/

Re: Failure lauching application since iceweasel -> Firefox

[Francesco Pietra]

Following dist-upgrade wheezy->jessie, linux prompt could only be reached
from 3.2.0-4 sysinit and no screen

startx

mdprobe error /libkmod/libkmod-module.c:816 kmod_module_insert_module()
could not find module by name 'nvidia-current'

Then, I adjusted the sources.list as for my GPU work station, where
wheezy->jessie had been carried out long ago:

deb http://debian.netcologne.de/debian/ jessie main contrib non-free
deb-src http://debian.netcologne.de/debian/ jessie main contrib non-free

deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free

deb http://www.deb-multimedia.org wheezy main non-free

deb http://debian.netcologne.de/debian/ jessie-proposed-updates main
contrib non-free
deb-src http://debian.netcologne.de/debian/ jessie-proposed-updates main
contrib non-free


i.e., testing -> jessie for proposed updates
   jessie -> wheezy for multimedia

Following #aptitude update/upgrade

startx
gnome-session

performed perfectly.

uname -r
3.2.0-4

i.e., 3.16-0-4 was not used in combination with nvidia. Is my procedure
correct or should jessie be used for also multimedia?

thanks

francesco pietra


On Fri, Jul 15, 2016 at 7:56 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:

> On Fri, Jul 15, 2016 at 06:57:28PM +0200, Francesco Pietra wrote:
> > I fear that on the amd64-gnome box my sources list should be amended:
> >
> > deb http://debian.netcologne.de/debian/ wheezy main contrib non-free
>
> Wheezy is long gone, given jessie was release well over a year ago now.
> Might be worth an upgrade.
>
> --
> Len Sorensen
>

Re: Failure lauching application since iceweasel -> Firefox

[Lennart Sorensen]

On Fri, Jul 15, 2016 at 06:57:28PM +0200, Francesco Pietra wrote:
> I fear that on the amd64-gnome box my sources list should be amended:
> 
> deb http://debian.netcologne.de/debian/ wheezy main contrib non-free

Wheezy is long gone, given jessie was release well over a year ago now.
Might be worth an upgrade.

-- 
Len Sorensen

Re: Failure lauching application since iceweasel -> Firefox

[Francesco Pietra]

I fear that on the amd64-gnome box my sources list should be amended:

deb http://debian.netcologne.de/debian/ wheezy main contrib non-free
> deb-src http://debian.netcologne.de/debian/ wheezy main contrib non-free
>
> deb http://security.debian.org/ wheezy/updates main contrib non-free
> deb-src http://security.debian.org/ wheezy/updates main contrib non-free
>
> deb http://www.deb-multimedia.org wheezy main non-free
>
> deb http://mozilla.debian.net/ wheezy-backports iceweasel-release
>
> deb http://debian.netcologne.de/debian/ testing-proposed-updates main
> contrib non-free
> deb-src http://debian.netcologne.de/debian/ testing-proposed-updates main
> contrib non-free
>


root@tya64:/home/francesco# aptitude update
reports

> W: There is no public key available for the following key IDs:
> 1397BC53640DB551
> W: Failed to fetch
> http://mozilla.debian.net/dists/wheezy-backports/Release: Unable to find
> expected entry 'iceweasel-release/binary-amd64/Packages' in Release file
> (Wrong sources.list entry or malformed file)
> E: Some index files failed to download. They have been ignored, or old
> ones used instead.
> E: Couldn't rebuild package cache
>


thanks for advice

francesco pietra



On Thu, Jul 14, 2016 at 9:47 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:

> On Thu, Jul 14, 2016 at 08:17:04AM +0200, Francesco Pietra wrote:
> > Here the reply by the developer of Vuescan, who had already let me know
> > that he never heard of iceweasel:
> >
> > This isn’t being started from VueScan code – it’s probably
> > > something in a shared library.
> > >
> > > Regards,
> > > Ed Hamrick
> > >
> >
> >
> > so, it seems to be an issue to be resolved within amd64 (Vuescan code
> works
> > perfectly, it is only the updating that failed)
>
> Well I would think something in your gnome settings is doing it.
>
> Did you ever manually answer a question about how to open something and
> select iceweasel that way?
>
> --
> Len Sorensen
>

Re: Failure lauching application since iceweasel -> Firefox

[Francesco Pietra]

Here the reply by the developer of Vuescan, who had already let me know
that he never heard of iceweasel:

This isn’t being started from VueScan code – it’s probably
> something in a shared library.
>
> Regards,
> Ed Hamrick
>


so, it seems to be an issue to be resolved within amd64 (Vuescan code works
perfectly, it is only the updating that failed)

thanks

francesco pietra

On Tue, Jul 12, 2016 at 10:40 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:

> On Tue, Jul 12, 2016 at 04:08:36PM +0200, Francesco Pietra wrote:
> > On last "upgrade" of amd64 wheezy I found Firefox in place of iceweasel.
> > OK, except that the single commercial application in my box (Vuescan) now
> > fails to upgrade
> >
> >
> > francesco@tya64:~/Vuescan$ ./vuescan
> > gvfs-open: http://www.hamrick.com/upgrade-l64.html: error launching
> > application: Failed to execute child process
> "/usr/lib/iceweasel/iceweasel"
> > (No such file or directory)
> > francesco@tya64:~/Vuescan$
> >
> >
> > I was unable to remedy with a softlink. What to do? Thanks
>
> Why would some application be poking at another package's private
> internals?  It should not be poking in /usr/lib/iceweasel.  If it wants
> to do anything with iceweasel (or firefox) it should use the binary in
> /usr/bin to do so.
>
> I don't know who is responsible for gvfs-open trying to do that.
>
> --
> Len Sorensen
>

Re: Failure lauching application since iceweasel -> Firefox

[Michael]

Why don't you try http://www.palemoon.org installed as a portable (like 
/opt/palemoon) you don't need the installer, just unzip the package in place.

Re: Failure lauching application since iceweasel -> Firefox

[Lennart Sorensen]

On Tue, Jul 12, 2016 at 04:08:36PM +0200, Francesco Pietra wrote:
> On last "upgrade" of amd64 wheezy I found Firefox in place of iceweasel.
> OK, except that the single commercial application in my box (Vuescan) now
> fails to upgrade
> 
> 
> francesco@tya64:~/Vuescan$ ./vuescan
> gvfs-open: http://www.hamrick.com/upgrade-l64.html: error launching
> application: Failed to execute child process "/usr/lib/iceweasel/iceweasel"
> (No such file or directory)
> francesco@tya64:~/Vuescan$
> 
> 
> I was unable to remedy with a softlink. What to do? Thanks

Why would some application be poking at another package's private
internals?  It should not be poking in /usr/lib/iceweasel.  If it wants
to do anything with iceweasel (or firefox) it should use the binary in
/usr/bin to do so.

I don't know who is responsible for gvfs-open trying to do that.

-- 
Len Sorensen

Re: [Stretch] Status for architecture qualification

[Emilio Pozuelo Monfort]

On 16/06/16 02:12, Hector Oron wrote:
> I have put up the classical wiki page for Stretch at:
>   https://wiki.debian.org/ArchiveQualification/Stretch
> 
> Please review and comment if required.

That page is now outdated wrt mips concerns (see below). Do we need to duplicate
the information that we already have on r.d.o/stretch/arch_qualify.html ?

>>- s390, ppc64el and all arm ports have DSA concerns.
> 
> I understand s390x and ppc64el DSA concerns have been clarified
> in-list and those concerns are due to nature of the architecture.

Sure, that's fine.

> For the ARM ports, which have also been clarified, let me re-confirm:
>  * arm64 port has remote power and remote console available, plus
> geo-redundancy, hardware is available and there is more hardware
> coming in the pipeline. I am unsure why it is listed with multiple DSA
> concerns, that surprises me (with DSA and ARM porter hats). The port
> currently has 4 machines up, one down waiting to be replaced, in total
> 5 and more coming.

OK. I have removed the DSA concerns for arm64 from arch_qualify due to this.

>  * armhf/armel ports share hardware, we currently have 6 machines up
> with remote power and remote console (of course that being development
> boards is not so nice as server remote management goodies). Some
> machines require a button press but local admins are great and always
> happy to help.
> 
> If none steps up explaining what are DSA concerns on the ARM
> architectures, please update status requalification page dropping
> those concerns. [DSA hat on]

AIUI armhf/armel needing local admins should still be a concern, even if mild.
Ideally that wouldn't be necessary. I have updated arch_qualify to reflect that.

> I see armel has one porter listed, if more are needed, please add
> myself and Riku Voipio (armel buildd maints). [ARM hat on]
> I see arm64/armhf are covered porterwise however there should be more
> porters available if needed.

I have added you two as armel porters.

>>  * mips64el (NEW)
>>- No DSA buildd (RT blocker)
> 
> As far as I can see mips64el is using shared builds with mipsel port
> hardware, those machines are DSA.

We now got more hardware. This is no longer a concern.

>>- Rebuild after import not complete (RT Blocker)
> 
> Is there a list of packages that should be rebuilt?

There's just one package missing, which is being worked on. See Aurelien's mail.

>>- Not yet in testing (due to the above).
> 
> Please let's work on getting it in testing ASAP I think the above
> blockers can be worked out quite reasonably.

Once db5.3 is rebuilt, we can enable mips64el in testing.

> While working out ArchitectureQualification/Stretch wiki page I
> believe everything is mostly fine for release, however I got a
> personal concern on powerpc architecture. Is it well maintained? Does
> it have porters? Does it have users? Does it still make sense to carry
> along?

Not sure about this one... I don't think anybody has stepped up as a porter.

> Another concern (DSA) which I have added and explained in the wiki
> page is the lack of georedundancy for the 'mips' port. Verbatim copy
> from wiki follows:
> "mips: It has 5 buildds in the same datacenter, current hardware are
> routers or development boards which makes it very difficult to ship to
> other places. The host providing redundancy (lucatelli) at UBC-ECE
> must be decomissioned ASAP, leaving the port in a situation of not
> geographic redundancy. However advanced plans exists to deploy mips
> hardware in other data centers RSN."
> 
> I'll keep you posted whenever there is progress on that area. I do not
> believe it should be a blocker for release, but we must ensure geo
> redundancy first.

That's sorted out now.

Cheers,
Emilio

Re: [Stretch] Status for architecture qualification

[Wouter Verhelst]

(sorry for jumping in late here)

On Wed, Jun 15, 2016 at 07:51:55AM +0800, Paul Wise wrote:
> On Wed, 2016-06-15 at 01:37 +0300, Dimitri John Ledkov wrote:
> 
> > At the openmainframeproject EU meetup, it was indicated that SUSE
> > joined with indication that Open Build Service might be able to use
> > resources hosted by Marist.
> > 
> > I wonder if it makes sense to reach out, and see if there are
> > resources available to use as porter boxes & build boxes. That way
> > Debian might be able to get such donated resource available on ongoing
> > basis and hopefully with some hw support.
> 
> Marist already support Debian with an s390x buildd:
> 
> ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
> "(sponsor=*marist*)"
> https://db.debian.org/machines.cgi?host=zani
> 
> Our other sponsors for s390 are www.iic.kit.edu and www.zivit.de:
> 
> ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
> "(architecture=s390*)" sponsor

Given that we already seem to have three hardware sponsors for the s390x
port, is this really a concern?

If we were to lose one sponsor, we'd still have two (and it would be
reasonable to try to ensure that we get a new sponsor to replace the one
lost).

How about making it a requirement that there is some level of redundancy
in sponsors for ports where hardware cannot be easily bought with Debian
money? That would cover the s390x port as well as any potential other
insanely-expensive-hardware port[1] that we might support now or in the
future.

If push comes to shove, we could also talk to IBM. Pretty much all POWER
hardware we have was sponsored by IBM; it's not unreasonable to assume
they might be willing to also sponsor s390x time or hardware.

[1] not that I know of any, but hey, you never know.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Re: [Stretch] Status for architecture qualification

[Lennart Sorensen]

On Mon, Jun 20, 2016 at 10:35:20PM +0200, Geert Uytterhoeven wrote:
> Yeah, apparently it's cheaper to bootstrap a complete new little endian
> platform than to fix portability issues in existing software...

I believe a big reason is that Nvidia cards expect little endian data,
and the overhead of converting between the host and the nvidia cards is
big enough to matter.

power8+ and power9 will have nvlink connections on the CPU for a reason
after all.

-- 
Len Sorensen

Re: [Stretch] Status for architecture qualification

[Geert Uytterhoeven]

On Mon, Jun 20, 2016 at 8:32 PM, Nelson H. F. Beebe  wrote:
> Recent traffic on this list has discussed Debian on PowerPC and
> big-endian vs little-endian.
>
> The next-generation US national laboratory facilities are to be based
> on PowerPC, and one source that I read mentioned little-endian, likely
> for binary file compatibility with files produced on Intel x86 and
> x86-64 CPUs: see

Yeah, apparently it's cheaper to bootstrap a complete new little endian
platform than to fix portability issues in existing software...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [Stretch] Status for architecture qualification

[Nelson H. F. Beebe]

Recent traffic on this list has discussed Debian on PowerPC and
big-endian vs little-endian.

The next-generation US national laboratory facilities are to be based
on PowerPC, and one source that I read mentioned little-endian, likely
for binary file compatibility with files produced on Intel x86 and
x86-64 CPUs: see

CORAL/Sierra
https://asc.llnl.gov/coral-info

The size, and budget, for such facilities suggests that there may be
financial support for Linux operating-system work on them.


---
- Nelson H. F. BeebeTel: +1 801 581 5254  -
- University of UtahFAX: +1 801 581 4148  -
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu  -
- 155 S 1400 E RM 233   be...@acm.org  be...@computer.org -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---

Re: [Stretch] Status for architecture qualification

[alexmcwhirter]

On 2016-06-20 10:29, John Paul Adrian Glaubitz wrote:

On 06/20/2016 04:15 PM, Lennart Sorensen wrote:
On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz 
wrote:

Well, we just did a full archive rebuild of "ppc64" to be able to
support ppc64 on the e5500 cores by disabling AltiVec, didn't we?


Well it is getting there.


The archive rebuild is done and around 11200 packages are up-to-date. 
It's
just the installer that needs work and someone needs to convince the 
release

team that ppc64 is something we want as a release architecture.

Adrian


Just out of curiosity, what's the stipulation with ppc64? Access to 
hardware shouldn't be a problem if ppc64el is a release arch. Maybe i'm 
just weird, but i would pick ppc64 over ppc64el any day. Other than my 
personal affinity for big endian cpu's, ppc64el only has support for one 
generation of cpu's whereas ppc64 should be able to run on everything 
from power4 / ppc970 and up without too much trouble.

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/20/2016 04:15 PM, Lennart Sorensen wrote:
> On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz wrote:
>> Well, we just did a full archive rebuild of "ppc64" to be able to
>> support ppc64 on the e5500 cores by disabling AltiVec, didn't we?
> 
> Well it is getting there.

The archive rebuild is done and around 11200 packages are up-to-date. It's
just the installer that needs work and someone needs to convince the release
team that ppc64 is something we want as a release architecture.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

[Lennart Sorensen]

On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz wrote:
> Well, we just did a full archive rebuild of "ppc64" to be able to
> support ppc64 on the e5500 cores by disabling AltiVec, didn't we?

Well it is getting there.

-- 
Len Sorensen

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/20/2016 04:05 PM, Lennart Sorensen wrote:
> Also I suspect many users of 64 bit capable freescale chips
> (e5500 and e6500 cores) are running 32 bit powerpc since they
> don't have enough ram to actually really gain anything
> from going to 64 bit, and the ppc64 port isn't done yet.

Well, we just did a full archive rebuild of "ppc64" to be able to
support ppc64 on the e5500 cores by disabling AltiVec, didn't we?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

[Lennart Sorensen]

On Sun, Jun 19, 2016 at 08:35:02PM +0200, Florian Weimer wrote:
> Do they implement the ISA required by the existing Debian port?

Yes.

The only ones that don't are the Freescale 85xx and P10[12]x chips,
which are powerpcspe due to using the e500 core.

All the 83xx and 82xx chips which are still shipping in many current
products are plain old 32bit powerpc.  Also I suspect many users of 64
bit capable freescale chips (e5500 and e6500 cores) are running 32 bit
powerpc since they don't have enough ram to actually really gain anything
from going to 64 bit, and the ppc64 port isn't done yet.  But those
would be a case of running 32 bit on 64 bit.

-- 
Len Sorensen

Re: [Stretch] Status for architecture qualification

[Florian Weimer]

* Lennart Sorensen:

> There are a lot of 32bit powerpc chips still going into embedded systems
> being built today.  They are not going away anytime soon.

Do they implement the ISA required by the existing Debian port?

Re: [Stretch] Status for architecture qualification

[Florian Weimer]

> In other words, i don't think a s390x box will ever just die.

I'm sure “death” encompasses all events which might lead Debian to
lose access to relevant hardware.  It's not just about faults with a
piece of equipment.

Re: [Stretch] Status for architecture qualification

[William ML Leslie]

On 19 June 2016 at 02:25, William ML Leslie
 wrote:
>
> In case it isn't clear, the number of users of the architecture is not part 
> of the qualification, it is the amount of maintenance pressure involved. 
> Package maintainers have to put more effort into ensuring builds succeed for 
> release architectures, which detracts from other work that needs to be done. 
> Not being a release architecture is perfectly fine.
>
> And just to bring the topic full circle now, ppc is a release architecture, 
> nobody is suggesting its removal afaict.


Whoops, I just realised that Hector *did* ask if powerpc had active
users.  Sorry for the misguided response to what seemed like off-topic
chatter.

-- 
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/18/2016 06:25 PM, William ML Leslie wrote:
> In case it isn't clear, the number of users of the architecture is not part 
> of the qualification, it is the amount of maintenance pressure involved. 
> Package
> maintainers have to put more effort into ensuring builds succeed for release 
> architectures, which detracts from other work that needs to be done. Not 
> being a
> release architecture is perfectly fine.

I maintain multiple architectures in Debian Ports, including m68k, powerpcspe, 
sh4, sparc64 and x32 and actually, it's not so much of a burden to maintain an
architecture in Debian. Most of the packages don't need special attention and 
if they do, it's usually just poorly written code like people doing weird 
pointer
arithmetics which provoke unaligned access or abuse C/C++ in other ways.

If upstream developers in these cases cared more about code quality and 
adhering to the C/C++ standards, we would hardly ever have issues with any 
ports. Heck,
even on m68k, most packages still build fine and they actually work. As long as 
an architecture is maintained upstream both in the kernel and the toolchain,
there is absolutely no reason to not keep it in Debian unless there is no 
hardware available that can be used for buildds and porterboxes. Ports like
Debian/GNU Hurd or Debian/kFreeBSD are a different story though as they need 
way more work to be able to make all sorts of packages work there.

In the case of PowerPC, both the kernel and the toolchain are very well 
maintained, many packages like GHC have native support for the architecture and 
even
rather problematic packages like Firefox/Thunderbird are supported. Plus, 
PowerPC packages can be built on the POWER8 virtual machines that IBM provides
for Debian Developers in the cloud for free. We have one such machine set up 
for ppc64, for example.

In any case, if PowerPC should ever be dropped as a release architecture, I 
will be more than happy to adopt it in Debian Ports.

PS: If you see your package failing to build on any of the ports architectures 
and you want to fix it and need help, just let me know :).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

[William ML Leslie]

In case it isn't clear, the number of users of the architecture is not part
of the qualification, it is the amount of maintenance pressure involved.
Package maintainers have to put more effort into ensuring builds succeed
for release architectures, which detracts from other work that needs to be
done. Not being a release architecture is perfectly fine.

And just to bring the topic full circle now, ppc is a release architecture,
nobody is suggesting its removal afaict.
On 18/06/2016 2:54 am, "Brock Wittrock"  wrote:

I run all sorts of PowerPC machines with various versions of Debian and I
don't see that coming to end anytime soon.  These are excellent and
reliable machines.  Biggest issues/hurdles are just graphics at the moment
for both ATI/AMD and Nvidia cards, but even if that is never resolved/fixed
or performance dwindles to nothing, I will continue to use these machines
in text/console only mode if I have to.  Please do not drop this
architecture!


Brock

On Fri, Jun 17, 2016 at 3:24 AM, Riccardo Mottola <
riccardo.mott...@libero.it> wrote:

> Hi,
>
> Dan DeVoto wrote:
>
>> In addition to the debian powerpc mailing list, powerpc users are active
>> on the Ubuntu forums.  I'm running Debian Sid on a Powerbook and everything
>> works except 3D acceleration.  I don't see a need to drop it.
>>
>
> I hope that my iBook G3 will serve me for years to come! Low power
> consumption fanless with a SSD disk make superquiet and quite nice!
>
> Riccardo
>
>

Re: [Stretch] Status for architecture qualification

[Brock Wittrock]

I run all sorts of PowerPC machines with various versions of Debian and I
don't see that coming to end anytime soon.  These are excellent and
reliable machines.  Biggest issues/hurdles are just graphics at the moment
for both ATI/AMD and Nvidia cards, but even if that is never resolved/fixed
or performance dwindles to nothing, I will continue to use these machines
in text/console only mode if I have to.  Please do not drop this
architecture!


Brock

On Fri, Jun 17, 2016 at 3:24 AM, Riccardo Mottola <
riccardo.mott...@libero.it> wrote:

> Hi,
>
> Dan DeVoto wrote:
>
>> In addition to the debian powerpc mailing list, powerpc users are active
>> on the Ubuntu forums.  I'm running Debian Sid on a Powerbook and everything
>> works except 3D acceleration.  I don't see a need to drop it.
>>
>
> I hope that my iBook G3 will serve me for years to come! Low power
> consumption fanless with a SSD disk make superquiet and quite nice!
>
> Riccardo
>
>

Re: [Stretch] Status for architecture qualification

[Riccardo Mottola]

Hi,

Dan DeVoto wrote:

In addition to the debian powerpc mailing list, powerpc users are active on the 
Ubuntu forums.  I'm running Debian Sid on a Powerbook and everything works 
except 3D acceleration.  I don't see a need to drop it.


I hope that my iBook G3 will serve me for years to come! Low power 
consumption fanless with a SSD disk make superquiet and quite nice!


Riccardo

Re: [Stretch] Status for architecture qualification

[Lennart Sorensen]

On Thu, Jun 16, 2016 at 09:04:12AM +0200, Mathieu Malaterre wrote:
> The debian-powerpc@l.d.o mailing list is active so I would say it
> still has some users. I have been using partch.d.o for doing some work
> on PowerPC. I posted a summary of work people have been doing on this
> port lately:
> 
> https://lists.debian.org/debian-powerpc/2016/06/msg00046.html
> 
> However I do agree that true PowerPC hardware is actually
> disappearing, and it is alive mostly thanks to being an ABI using
> 32bits integer for PPC64 CPU(s).

There are a lot of 32bit powerpc chips still going into embedded systems
being built today.  They are not going away anytime soon.

-- 
Len Sorensen

Re: [Stretch] Status for architecture qualification

[Philipp Kern]

On 2016-06-15 00:37, Dimitri John Ledkov wrote:

There is openmainframe project https://www.openmainframeproject.org/ ,
which I believe offers access to z/VM instances hosted by Marist
colledge.

At the openmainframeproject EU meetup, it was indicated that SUSE
joined with indication that Open Build Service might be able to use
resources hosted by Marist.

I wonder if it makes sense to reach out, and see if there are
resources available to use as porter boxes & build boxes. That way
Debian might be able to get such donated resource available on ongoing
basis and hopefully with some hw support.


Debian already makes use of Marist's resources. The challenge was/is to 
get redundancy as DSA very sensibly insists on.


Kind regards
Philipp Kern

RE: [Stretch] Status for architecture qualification

[luigi burdo]

Here too all new amiga Ng are PPC  with last generations of gpu pcie Amd boards 
and we are using linux  expecially Debian.
Luigi

From: herminio.hernande...@gmail.com
Date: Wed, 15 Jun 2016 22:02:29 -0700
Subject: Re: [Stretch] Status for architecture qualification
To: hector.o...@gmail.com
CC: ni...@thykier.net; debian-ad...@lists.debian.org; t...@security.debian.org; 
debian-rele...@lists.debian.org; debian-po...@lists.debian.org; 
debian-wb-t...@lists.debian.org; r...@debian.org

I know there are still powerpc users who run Debian. I am one of them and love 
to see it continue. How can I help?
Thanks!
On Wed, Jun 15, 2016 at 5:12 PM, Hector Oron <hector.o...@gmail.com> wrote:
[Add to CC debian-wb-team@ and r...@debian.org]



Hello,



2016-06-05 12:01 GMT+02:00 Niels Thykier <ni...@thykier.net>:

> Hi members of DSA, Security, RT and all porters.

>

> While the freeze still seem far away, I think it is time to start with

> the architecture qualifications.



Excellent! Thanks



I tried to follow the follow-up thread, ended up watching an hour

video which was quite fun and forgot all details. :-)



I have put up the classical wiki page for Stretch at:

  https://wiki.debian.org/ArchiveQualification/Stretch



Please review and comment if required.



> For starters, here are the architectures we are aware of:

>

>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,

>s390x

>- *No* blockers at this time from RT, DSA nor security.

>- s390, ppc64el and all arm ports have DSA concerns.



I understand s390x and ppc64el DSA concerns have been clarified

in-list and those concerns are due to nature of the architecture.



For the ARM ports, which have also been clarified, let me re-confirm:

 * arm64 port has remote power and remote console available, plus

geo-redundancy, hardware is available and there is more hardware

coming in the pipeline. I am unsure why it is listed with multiple DSA

concerns, that surprises me (with DSA and ARM porter hats). The port

currently has 4 machines up, one down waiting to be replaced, in total

5 and more coming.

 * armhf/armel ports share hardware, we currently have 6 machines up

with remote power and remote console (of course that being development

boards is not so nice as server remote management goodies). Some

machines require a button press but local admins are great and always

happy to help.



If none steps up explaining what are DSA concerns on the ARM

architectures, please update status requalification page dropping

those concerns. [DSA hat on]



I see armel has one porter listed, if more are needed, please add

myself and Riku Voipio (armel buildd maints). [ARM hat on]

I see arm64/armhf are covered porterwise however there should be more

porters available if needed.



>- armel has a RT concern about lack of buildds (only 2)



>From the above comment: "armhf/armel ports share hardware, we

currently have 6 machines up"



>  * mips64el (NEW)

>- No DSA buildd (RT blocker)



As far as I can see mips64el is using shared builds with mipsel port

hardware, those machines are DSA.



>- Rebuild after import not complete (RT Blocker)



Is there a list of packages that should be rebuilt?



>- Not yet in testing (due to the above).



Please let's work on getting it in testing ASAP I think the above

blockers can be worked out quite reasonably.



>  * kfreebsd-i386, kfreebsd-amd64

>- Not included in Jessie due to lack of sustainable man-power (RT

>  blocker)

>- No news of the situation having changed

>- If there is no news on the situation after DebConf16, I will

>  assume kfreebsd-* will not target Stretch.



Who has been keeping it up for stretch? (As a side note Stephen

Chamberlain, Christoph Egger and many other people keep working on it)

Not sure if those arches have more or less manpower than powerpc (in

example). I think it would be great to make a call here, we either

move kfreebsd ports to debian-ports infrastructure or go for the

release with it.



While working out ArchitectureQualification/Stretch wiki page I

believe everything is mostly fine for release, however I got a

personal concern on powerpc architecture. Is it well maintained? Does

it have porters? Does it have users? Does it still make sense to carry

along?



Another concern (DSA) which I have added and explained in the wiki

page is the lack of georedundancy for the 'mips' port. Verbatim copy

from wiki follows:

"mips: It has 5 buildds in the same datacenter, current hardware are

routers or development boards which makes it very difficult to ship to

other places. The host providing redundancy (lucatelli) at UBC-ECE

must be decomissioned ASAP, leaving the port in a situation of not

geographic redundancy. However advanced plans exists to deploy mips

hardware in other data centers RSN."



I'll

Re: unsubsribe

[Jeffrey Walton]

On Thu, Jun 16, 2016 at 2:00 AM, simoon  wrote:
> unsubsribe

Try https://www.debian.org/MailingLists/subscribe.

(Its not the easiest to find; and the top search result hides it
rather than stating it clearly).

Re: [Stretch] Status for architecture qualification

[Herminio Hernandez, Jr.]

I know there are still powerpc users who run Debian. I am one of them and
love to see it continue. How can I help?

Thanks!

On Wed, Jun 15, 2016 at 5:12 PM, Hector Oron <hector.o...@gmail.com> wrote:

> [Add to CC debian-wb-team@ and r...@debian.org]
>
> Hello,
>
> 2016-06-05 12:01 GMT+02:00 Niels Thykier <ni...@thykier.net>:
> > Hi members of DSA, Security, RT and all porters.
> >
> > While the freeze still seem far away, I think it is time to start with
> > the architecture qualifications.
>
> Excellent! Thanks
>
> I tried to follow the follow-up thread, ended up watching an hour
> video which was quite fun and forgot all details. :-)
>
> I have put up the classical wiki page for Stretch at:
>   https://wiki.debian.org/ArchiveQualification/Stretch
>
> Please review and comment if required.
>
> > For starters, here are the architectures we are aware of:
> >
> >  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
> >s390x
> >- *No* blockers at this time from RT, DSA nor security.
> >- s390, ppc64el and all arm ports have DSA concerns.
>
> I understand s390x and ppc64el DSA concerns have been clarified
> in-list and those concerns are due to nature of the architecture.
>
> For the ARM ports, which have also been clarified, let me re-confirm:
>  * arm64 port has remote power and remote console available, plus
> geo-redundancy, hardware is available and there is more hardware
> coming in the pipeline. I am unsure why it is listed with multiple DSA
> concerns, that surprises me (with DSA and ARM porter hats). The port
> currently has 4 machines up, one down waiting to be replaced, in total
> 5 and more coming.
>  * armhf/armel ports share hardware, we currently have 6 machines up
> with remote power and remote console (of course that being development
> boards is not so nice as server remote management goodies). Some
> machines require a button press but local admins are great and always
> happy to help.
>
> If none steps up explaining what are DSA concerns on the ARM
> architectures, please update status requalification page dropping
> those concerns. [DSA hat on]
>
> I see armel has one porter listed, if more are needed, please add
> myself and Riku Voipio (armel buildd maints). [ARM hat on]
> I see arm64/armhf are covered porterwise however there should be more
> porters available if needed.
>
> >- armel has a RT concern about lack of buildds (only 2)
>
> >From the above comment: "armhf/armel ports share hardware, we
> currently have 6 machines up"
>
> >  * mips64el (NEW)
> >- No DSA buildd (RT blocker)
>
> As far as I can see mips64el is using shared builds with mipsel port
> hardware, those machines are DSA.
>
> >- Rebuild after import not complete (RT Blocker)
>
> Is there a list of packages that should be rebuilt?
>
> >- Not yet in testing (due to the above).
>
> Please let's work on getting it in testing ASAP I think the above
> blockers can be worked out quite reasonably.
>
> >  * kfreebsd-i386, kfreebsd-amd64
> >- Not included in Jessie due to lack of sustainable man-power (RT
> >  blocker)
> >- No news of the situation having changed
> >- If there is no news on the situation after DebConf16, I will
> >  assume kfreebsd-* will not target Stretch.
>
> Who has been keeping it up for stretch? (As a side note Stephen
> Chamberlain, Christoph Egger and many other people keep working on it)
> Not sure if those arches have more or less manpower than powerpc (in
> example). I think it would be great to make a call here, we either
> move kfreebsd ports to debian-ports infrastructure or go for the
> release with it.
>
> While working out ArchitectureQualification/Stretch wiki page I
> believe everything is mostly fine for release, however I got a
> personal concern on powerpc architecture. Is it well maintained? Does
> it have porters? Does it have users? Does it still make sense to carry
> along?
>
> Another concern (DSA) which I have added and explained in the wiki
> page is the lack of georedundancy for the 'mips' port. Verbatim copy
> from wiki follows:
> "mips: It has 5 buildds in the same datacenter, current hardware are
> routers or development boards which makes it very difficult to ship to
> other places. The host providing redundancy (lucatelli) at UBC-ECE
> must be decomissioned ASAP, leaving the port in a situation of not
> geographic redundancy. However advanced plans exists to deploy mips
> hardware in other data centers RSN."
>
> I'll keep you posted whenever there is progress on that area. I do not
> believe it should be a blocker for release, but we must ensure geo
> redundancy first.
>
> > Beyond mips64el, we are not aware of any new architectures for Stretch.
>
> Could you please check with sparc64 porters? I think some of them
> commented on the follow ups.
>
> Regards,
> --
>  Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.
>
>

Re: [Stretch] Status for architecture qualification

[Hector Oron]

[Add to CC debian-wb-team@ and r...@debian.org]

Hello,

2016-06-05 12:01 GMT+02:00 Niels Thykier <ni...@thykier.net>:
> Hi members of DSA, Security, RT and all porters.
>
> While the freeze still seem far away, I think it is time to start with
> the architecture qualifications.

Excellent! Thanks

I tried to follow the follow-up thread, ended up watching an hour
video which was quite fun and forgot all details. :-)

I have put up the classical wiki page for Stretch at:
  https://wiki.debian.org/ArchiveQualification/Stretch

Please review and comment if required.

> For starters, here are the architectures we are aware of:
>
>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
>s390x
>- *No* blockers at this time from RT, DSA nor security.
>- s390, ppc64el and all arm ports have DSA concerns.

I understand s390x and ppc64el DSA concerns have been clarified
in-list and those concerns are due to nature of the architecture.

For the ARM ports, which have also been clarified, let me re-confirm:
 * arm64 port has remote power and remote console available, plus
geo-redundancy, hardware is available and there is more hardware
coming in the pipeline. I am unsure why it is listed with multiple DSA
concerns, that surprises me (with DSA and ARM porter hats). The port
currently has 4 machines up, one down waiting to be replaced, in total
5 and more coming.
 * armhf/armel ports share hardware, we currently have 6 machines up
with remote power and remote console (of course that being development
boards is not so nice as server remote management goodies). Some
machines require a button press but local admins are great and always
happy to help.

If none steps up explaining what are DSA concerns on the ARM
architectures, please update status requalification page dropping
those concerns. [DSA hat on]

I see armel has one porter listed, if more are needed, please add
myself and Riku Voipio (armel buildd maints). [ARM hat on]
I see arm64/armhf are covered porterwise however there should be more
porters available if needed.

>- armel has a RT concern about lack of buildds (only 2)

>From the above comment: "armhf/armel ports share hardware, we
currently have 6 machines up"

>  * mips64el (NEW)
>- No DSA buildd (RT blocker)

As far as I can see mips64el is using shared builds with mipsel port
hardware, those machines are DSA.

>- Rebuild after import not complete (RT Blocker)

Is there a list of packages that should be rebuilt?

>- Not yet in testing (due to the above).

Please let's work on getting it in testing ASAP I think the above
blockers can be worked out quite reasonably.

>  * kfreebsd-i386, kfreebsd-amd64
>- Not included in Jessie due to lack of sustainable man-power (RT
>  blocker)
>- No news of the situation having changed
>- If there is no news on the situation after DebConf16, I will
>  assume kfreebsd-* will not target Stretch.

Who has been keeping it up for stretch? (As a side note Stephen
Chamberlain, Christoph Egger and many other people keep working on it)
Not sure if those arches have more or less manpower than powerpc (in
example). I think it would be great to make a call here, we either
move kfreebsd ports to debian-ports infrastructure or go for the
release with it.

While working out ArchitectureQualification/Stretch wiki page I
believe everything is mostly fine for release, however I got a
personal concern on powerpc architecture. Is it well maintained? Does
it have porters? Does it have users? Does it still make sense to carry
along?

Another concern (DSA) which I have added and explained in the wiki
page is the lack of georedundancy for the 'mips' port. Verbatim copy
from wiki follows:
"mips: It has 5 buildds in the same datacenter, current hardware are
routers or development boards which makes it very difficult to ship to
other places. The host providing redundancy (lucatelli) at UBC-ECE
must be decomissioned ASAP, leaving the port in a situation of not
geographic redundancy. However advanced plans exists to deploy mips
hardware in other data centers RSN."

I'll keep you posted whenever there is progress on that area. I do not
believe it should be a blocker for release, but we must ensure geo
redundancy first.

> Beyond mips64el, we are not aware of any new architectures for Stretch.

Could you please check with sparc64 porters? I think some of them
commented on the follow ups.

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Re: [Stretch] Status for architecture qualification

[Stephen Powell]

On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote:
> 
> There is openmainframe project https://www.openmainframeproject.org/ ,
> which I believe offers access to z/VM instances hosted by Marist
> colledge.
> 
> At the openmainframeproject EU meetup, it was indicated that SUSE
> joined with indication that Open Build Service might be able to use
> resources hosted by Marist.
> 
> I wonder if it makes sense to reach out, and see if there are
> resources available to use as porter boxes & build boxes. That way
> Debian might be able to get such donated resource available on ongoing
> basis and hopefully with some hw support.
> 

Of course, there's always Hercules.  Real hardware is always better of course.
But then again, strictly speaking, A z/VM instance is a virtual machine,
running under z/VM.  And z/VM is running in an LPAR, which is essentially
a virtual machine running under PR/SM.  And the physical machine behind
those (at least) two levels of virtualization doesn't really have the
same hardware architecture as a virtual machine, such as physical chpids
vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM
or IOCP.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Re: [Stretch] Status for architecture qualification

[Paul Wise]

On Wed, 2016-06-15 at 01:37 +0300, Dimitri John Ledkov wrote:

> At the openmainframeproject EU meetup, it was indicated that SUSE
> joined with indication that Open Build Service might be able to use
> resources hosted by Marist.
> 
> I wonder if it makes sense to reach out, and see if there are
> resources available to use as porter boxes & build boxes. That way
> Debian might be able to get such donated resource available on ongoing
> basis and hopefully with some hw support.

Marist already support Debian with an s390x buildd:

ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
"(sponsor=*marist*)"
https://db.debian.org/machines.cgi?host=zani

Our other sponsors for s390 are www.iic.kit.edu and www.zivit.de:

ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
"(architecture=s390*)" sponsor

-- 

bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: [Stretch] Status for architecture qualification

[Dimitri John Ledkov]

On 14 June 2016 at 20:22,   wrote:
> On 2016-06-14 03:06, Philipp Kern wrote:
>>
>> On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote:
>>>
>>> Philipp Kern:
>>> > On 2016-06-05 12:01, Niels Thykier wrote:
>>> >>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
>>> >>s390x
>>> >>- *No* blockers at this time from RT, DSA nor security.
>>> >>- s390, ppc64el and all arm ports have DSA concerns.
>>> > What is the current DSA concern about s390x?
>>> The concern listed as: "rely on sponsors for hardware (mild concern)"
>>>
>>> As I recall the argument went something along the lines of:
>>>
>>> "Debian cannot replace the hardware; if any of the machines dies, we
>>> need a sponsor to replace it.  If all of them dies and we cannot get
>>> sponsored replacements, we cannot support the architecture any longer"
>>>
>>> (My wording)
>>
>>
>> Yeah, but that's unfortunately one of the universal truths of this port.
>> I mean in theory sometimes they turn up on eBay and people try to make
>> them work[1].
>>
>> It also seems true for other ports where we commonly relied on sponsors
>> to hand us replacements. But maybe it's only ppc64el these days, maybe
>> there are useful builds available for the others (including arm64 and
>> mips) on the market now.
>>
>> Kind regards and thanks
>> Philipp Kern
>>
>> [1] https://www.youtube.com/watch?v=45X4VP8CGtk
>> (Here's What Happens When an 18 Year Old Buys a Mainframe)
>
>
> Fun story, i had a client who was considering getting their hands on a Z9,
> they asked me a few others to go with them to see IBM present a demo of it.
> Long story short the IBM guys started a job and literally started pulling
> CPU and Mem boards out of the machine mid job. The error log on the OS/2
> maintenance laptop was going crazy, but the OS kept running the job.
>
> In other words, i don't think a s390x box will ever just die. Really
> interesting machines to say the least, hopefully one day i will get to play
> with one. The other issues with s390x is that  in most cases you don't buy
> them. You essentially lease the CPU usage and IBM charges you based on how
> much CPU usage you've consumed over a given time. It makes me wonder how
> they ever get on eBay. IBM typically takes them back after you stop paying
> for it.
>

In the talk he did say that for that acient machine he was offered
subscription to the upgraded z/OS for some small amount of dollars a
quarter.

There is openmainframe project https://www.openmainframeproject.org/ ,
which I believe offers access to z/VM instances hosted by Marist
colledge.

At the openmainframeproject EU meetup, it was indicated that SUSE
joined with indication that Open Build Service might be able to use
resources hosted by Marist.

I wonder if it makes sense to reach out, and see if there are
resources available to use as porter boxes & build boxes. That way
Debian might be able to get such donated resource available on ongoing
basis and hopefully with some hw support.

-- 
Regards,

Dimitri.

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/14/2016 09:06 AM, Philipp Kern wrote:
> Yeah, but that's unfortunately one of the universal truths of this port.
> I mean in theory sometimes they turn up on eBay and people try to make
> them work[1].

Hilarious talk, thanks a lot for the link :).

> It also seems true for other ports where we commonly relied on sponsors
> to hand us replacements. But maybe it's only ppc64el these days, maybe
> there are useful builds available for the others (including arm64 and
> mips) on the market now.

The hardware sponsoring is the main thing that keeps us from making sparc64
an official port, I would say.

The state of the port itself is great: We recently even got LibreOffice running
on sparc64 (patches not yet merged) and the port is quite popular, according
to popcon, sparc64 has already more users than arm64 and some of the mips
ports :). If we were to add sparc64 to Debian, we could rebuild the archive
within a few weeks.

We have one user who has two Sun T2 servers which are new-in-box (NIB),
would those be ok to set up as machines for DSA?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

[Emilio Pozuelo Monfort]

On 14/06/16 09:06, Philipp Kern wrote:
> On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote:
>> Philipp Kern:
>>> On 2016-06-05 12:01, Niels Thykier wrote:
  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
s390x
- *No* blockers at this time from RT, DSA nor security.
- s390, ppc64el and all arm ports have DSA concerns.
>>> What is the current DSA concern about s390x?
>> The concern listed as: "rely on sponsors for hardware (mild concern)"
>>
>> As I recall the argument went something along the lines of:
>>
>> "Debian cannot replace the hardware; if any of the machines dies, we
>> need a sponsor to replace it.  If all of them dies and we cannot get
>> sponsored replacements, we cannot support the architecture any longer"
>>
>> (My wording)
> 
> Yeah, but that's unfortunately one of the universal truths of this port.
> I mean in theory sometimes they turn up on eBay and people try to make
> them work[1].
> 
> It also seems true for other ports where we commonly relied on sponsors
> to hand us replacements. But maybe it's only ppc64el these days, maybe
> there are useful builds available for the others (including arm64 and
> mips) on the market now.

AFAIK we rely on sponsors for all ports. The difference is that if we eventually
have to buy things ourselves, we can get mips*, arm* or x86 buildds (for
example), but we can't reasonably get a s390x one.

But that's not something we can change, so as long as there no other concerns,
this shouldn't be a blocker.

Emilio

Re: [Stretch] Status for architecture qualification

[Philipp Kern]

On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote:
> Philipp Kern:
> > On 2016-06-05 12:01, Niels Thykier wrote:
> >>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
> >>s390x
> >>- *No* blockers at this time from RT, DSA nor security.
> >>- s390, ppc64el and all arm ports have DSA concerns.
> > What is the current DSA concern about s390x?
> The concern listed as: "rely on sponsors for hardware (mild concern)"
> 
> As I recall the argument went something along the lines of:
> 
> "Debian cannot replace the hardware; if any of the machines dies, we
> need a sponsor to replace it.  If all of them dies and we cannot get
> sponsored replacements, we cannot support the architecture any longer"
> 
> (My wording)

Yeah, but that's unfortunately one of the universal truths of this port.
I mean in theory sometimes they turn up on eBay and people try to make
them work[1].

It also seems true for other ports where we commonly relied on sponsors
to hand us replacements. But maybe it's only ppc64el these days, maybe
there are useful builds available for the others (including arm64 and
mips) on the market now.

Kind regards and thanks
Philipp Kern

[1] https://www.youtube.com/watch?v=45X4VP8CGtk
(Here's What Happens When an 18 Year Old Buys a Mainframe)

Re: [Stretch] Status for architecture qualification

[Niels Thykier]

Philipp Kern:
> On 2016-06-05 12:01, Niels Thykier wrote:
>>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
>>s390x
>>- *No* blockers at this time from RT, DSA nor security.
>>- s390, ppc64el and all arm ports have DSA concerns.
> 
> What is the current DSA concern about s390x?
> 
> Kind regards and thanks
> Philipp Kern
> 

The concern listed as: "rely on sponsors for hardware (mild concern)"

As I recall the argument went something along the lines of:

"Debian cannot replace the hardware; if any of the machines dies, we
need a sponsor to replace it.  If all of them dies and we cannot get
sponsored replacements, we cannot support the architecture any longer"

(My wording)

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: [Stretch] Status for architecture qualification

[Philipp Kern]

On 2016-06-05 12:01, Niels Thykier wrote:

 * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
   s390x
   - *No* blockers at this time from RT, DSA nor security.
   - s390, ppc64el and all arm ports have DSA concerns.


What is the current DSA concern about s390x?

Kind regards and thanks
Philipp Kern

Re: About structure sk_buff

[Grant Grundler]

On Mon, Jun 6, 2016 at 3:10 AM, Corcodel Marian 
wrote:

>
>
> On 06.06.2016 12:59, Corcodel Marian wrote:
>
>> Hi
>> Why sk_buff  have memory allocated on hardware drivers on majority nic
>> drivers?
>>
>
This seems like an appropriate question for netdev mailing list:
 http://vger.kernel.org/vger-lists.html#netdev

(Tip: explain in more detail what you think is wrong with "rx mode" and
someone should be polite enough to point out why it works. Offhand, I don't
quite understand what you are trying to point out.)

cheers,
grant

 This is wrong on rx mode look like:
>>
>> struct sk_buff *skb;
>> struct device *d = >pci_dev->dev;
>>
>> data = rtl8169_align(data);
>> dma_sync_single_for_cpu(d, addr, pkt_size, DMA_FROM_DEVICE);
>> prefetch(data);
>> skb = netdev_alloc_skb_ip_align(tp->dev, pkt_size);
>> if (skb)
>> memcpy(skb->data, data, pkt_size);
>> dma_sync_single_for_device(d, addr, pkt_size, DMA_FROM_DEVICE);
>>
>> sk_buff is allocated on place tx mode
>> and on start_xmit  no need to keep sk_buff on hardware structure because
>> any info is extracted from
>>  next level of driver.
>>
>>
> --
> Visit my project
> https://sourceforge.net/projects/network-card-driver/?source=navbar
>
>

Re: [Stretch] Status for architecture qualification

[John David Anglin]

On 2016-06-05 8:56 AM, Steven Chamberlain wrote:

John Paul Adrian Glaubitz wrote:

>I have invested lots of time and effort to get sparc64 into a usable state in 
Debian.
>We are close to 11.000 installed packages. Missing packages include Firefox,
>Thunderbird/Icedove, golang and LibreOffice to name the most important ones.

Is there some way to define 'core'[0] packages as blockers for testing
migration, and arch release qualification;  but other packages not?

Many of these ports would be useful if just a base system was released,
and preferably having stable/security updates for that part (otherwise
it is difficult for users to try it, developers to work on it, or DSA to
support buildds for it;  all of which are limitations on ports' further
growth).
I might mention that many kernel and tool chain bugs have been resolved 
on hppa since
we joined ports.  Total source package count  is now close to 11100, 
although this fluctuates.
Using this measure we are at the same level as alpha, ppc64 and 
sparc64.  SMP systems

are stable and run reliably as buildd machines.

Even if we increased our relative package count, we don't have the 
manpower to re-qualify
as a release architecture.  However, I like Steve's suggestion. Helge 
effectively defined a set
of core packages for hppa when he set up a new jessie-based install disk 
a few months ago.
This is currently available at .  I tend to think 
this should be done within

the context of Debian ports.

Dave

--
John David Anglin  dave.ang...@bell.net

Re: About structure sk_buff

[Corcodel Marian]

On 06.06.2016 12:59, Corcodel Marian wrote:

Hi
Why sk_buff  have memory allocated on hardware drivers on majority nic 
drivers?

 This is wrong on rx mode look like:

struct sk_buff *skb;
struct device *d = >pci_dev->dev;

data = rtl8169_align(data);
dma_sync_single_for_cpu(d, addr, pkt_size, DMA_FROM_DEVICE);
prefetch(data);
skb = netdev_alloc_skb_ip_align(tp->dev, pkt_size);
if (skb)
memcpy(skb->data, data, pkt_size);
dma_sync_single_for_device(d, addr, pkt_size, DMA_FROM_DEVICE);

sk_buff is allocated on place tx mode
and on start_xmit  no need to keep sk_buff on hardware structure 
because any info is extracted from

 next level of driver.



--
Visit my project 
https://sourceforge.net/projects/network-card-driver/?source=navbar

Re: [Stretch] Status for architecture qualification

[Niels Thykier]

Steven Chamberlain:
> Hi,
> 

Hi,

> John Paul Adrian Glaubitz wrote:
>> I have invested lots of time and effort to get sparc64 into a usable state 
>> in Debian.
>> We are close to 11.000 installed packages. Missing packages include Firefox,
>> Thunderbird/Icedove, golang and LibreOffice to name the most important ones.
> 
> Is there some way to define 'core'[0] packages as blockers for testing
> migration, and arch release qualification;  but other packages not?
> 

There is no current definition and I doubt it will be trivial to agree
on a definition.  Also, the moment you want to keep the set
self-contained (by including build-depends) it very easily explodes
unless you patch packages to disable "optional" features.

> Many of these ports would be useful if just a base system was released,
> and preferably having stable/security updates for that part (otherwise
> it is difficult for users to try it, developers to work on it, or DSA to
> support buildds for it;  all of which are limitations on ports' further
> growth).
> 

Assuming we use your definition as basis, you probably also want the
packages necessary to support a DSA maintained buildd.  Otherwise it
seems it fail one of your own proposed requirements.

> Trying to have *every* package build and stay built on every port, and
> supported for the lifetime of stable, is a lot of work without much
> purpose sometimes.  And it's unreasonable for any one port to block
> testing migration of a package on all arches, unless it is something
> really essential.
> 
> This might be done either:
>   * in the official archive, with relaxed rules for testing migration
> and more frequently de-crufting of out-of-date packages;

I suspect this will be a lot of work and an uphill battle as the our
current tooling is not really written for this case.  At the very least,
I fear a lot of extra special cases in Britney that I cannot easily deal
with.

>   * creating a mini testing/stable suite based on debian-ports.org?
> where maybe only the core packages are candidates to migrate.
> 

At least short term, this probably a lot more tractable. I am happy to
provide help with setting up a Britney instance for ports.  Though we
would need some way to provide a architecture specific version of the
"core" packages.

> [0]: I'd define core packages as everything needed to install, boot, and
> then build packages on that arch.  The rebootstrap project gives us some
> idea of what those are;  but add to that the kernel and any bootloaders.
> Being able to rebootstrap, should be part of the arch release
> qualification anyway IMHO.
> 
> Regards,
> 

Hmm, the rebootstrap idea is interesting as a new requirement.  I will
look into it.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: [Stretch] Status for architecture qualification

[Oleg Endo]

Hi,

On Sun, 2016-06-05 at 13:26 +0200, John Paul Adrian Glaubitz wrote:

> sh4:
> 

> 
> The two biggest issues with sh4 are currently with binutils and the 
> kernel. binutils has problems when building Qt5:
> 

There is in fact another big elephant in the room, which I have
mentioned several times before...

The atomic model that is currently being used on sh4-linux works only
on SH3* and SH4* single-core systems.  Packages built for the current
sh4-linux will not work on multi-core systems like SH7786...

There should be two distinct builds .. sh4-linux with the current
atomic model (-matomic-model=soft-gusa) and sh4a-linux with the newer 
-matomic-model=hard-llcs.  I think it would be the easiest thing for
Debian to switch the whole thing to SH4A only and drop the older SH4.

I will add a GCC configure option to allow changing the default atomic
model.  Currently it's hardcoded to -matomic-model=soft-gusa for sh3
-linux or sh4*-linux.

Cheers,
Oleg

(GCC SH Maintainer)

Re: [Stretch] Status for architecture qualification

[Holger Levsen]

thanks to everyone explaining arch:any to me :)

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: [Stretch] Status for architecture qualification

[Steven Chamberlain]

Hi,

John Paul Adrian Glaubitz wrote:
> I have invested lots of time and effort to get sparc64 into a usable state in 
> Debian.
> We are close to 11.000 installed packages. Missing packages include Firefox,
> Thunderbird/Icedove, golang and LibreOffice to name the most important ones.

Is there some way to define 'core'[0] packages as blockers for testing
migration, and arch release qualification;  but other packages not?

Many of these ports would be useful if just a base system was released,
and preferably having stable/security updates for that part (otherwise
it is difficult for users to try it, developers to work on it, or DSA to
support buildds for it;  all of which are limitations on ports' further
growth).

Trying to have *every* package build and stay built on every port, and
supported for the lifetime of stable, is a lot of work without much
purpose sometimes.  And it's unreasonable for any one port to block
testing migration of a package on all arches, unless it is something
really essential.

This might be done either:
  * in the official archive, with relaxed rules for testing migration
and more frequently de-crufting of out-of-date packages;
  * creating a mini testing/stable suite based on debian-ports.org?
where maybe only the core packages are candidates to migrate.

[0]: I'd define core packages as everything needed to install, boot, and
then build packages on that arch.  The rebootstrap project gives us some
idea of what those are;  but add to that the kernel and any bootloaders.
Being able to rebootstrap, should be part of the arch release
qualification anyway IMHO.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: [Stretch] Status for architecture qualification

[peter green]

On 05/06/16 13:00, Holger Levsen wrote:

On Sun, Jun 05, 2016 at 01:26:39PM +0200, John Paul Adrian Glaubitz wrote:
   

ppc64:

This architecture is basically on par with the release architectures. We have 
over
11.000 packages installed
 

[...]
   

sparc64:
We are close to 11.000 installed packages.
 

I'm not sure whether you are talking about source or binary packages but
sid/amd64 has over 24000 source packages and over 5 binary packages,
so I would call the above "on par". Or what am I missing?

   
I presume he is talking about source packages in the "installed" state 
in wana-build. For comparison this is currently 12153 for amd64 and 
10937 for mips.


(this leads to the interesting conclusion that about half the source 
packages in sid are arch-all only)

Re: [Stretch] Status for architecture qualification

[Christian Seiler]

On 06/05/2016 02:00 PM, Holger Levsen wrote:
> On Sun, Jun 05, 2016 at 01:26:39PM +0200, John Paul Adrian Glaubitz wrote:
>> ppc64:
>>
>> This architecture is basically on par with the release architectures. We 
>> have over
>> 11.000 packages installed
> [...]
>> sparc64:
>> We are close to 11.000 installed packages. 
> 
> I'm not sure whether you are talking about source or binary packages but
> sid/amd64 has over 24000 source packages and over 5 binary packages,
> so I would call the above "on par". Or what am I missing?

But around 12000 of those source packages only build Arch: all packages.
If you look at amd64's buildd stats in sid, there are ~12000 source
packages in the Installed state:

https://buildd.debian.org/status/architecture.php?a=amd64=sid

i386 also has ~12000; arm64, armhf, armel, powerpc and ppc64 have ~11500
each; mipsel has ~11300 and mips has ~11000.

Arch: all has ~15000 source packages in the Installed state (but that
also counts packages that build both Arch: !all and Arch: all.

From these statistics, sparc64 appears to be a tiny bit behind mips in
terms of archive coverage, but not by much.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

On 06/05/2016 02:00 PM, Holger Levsen wrote:
> I'm not sure whether you are talking about source or binary packages but
> sid/amd64 has over 24000 source packages and over 5 binary packages,
> so I would call the above "on par". Or what am I missing?

There are just around 12,000 source packages with arch:amd64 in sid:

glaubitz@wuiet:~$ wanna-build -A sparc64 -d unstable --list=installed | wc -l
10828
glaubitz@wuiet:~$ wanna-build -A ppc64 -d unstable --list=installed | wc -l
10990
glaubitz@wuiet:~$ wanna-build -A amd64 -d unstable --list=installed | wc -l
12154
glaubitz@wuiet:~$

The rest is arch:all:

glaubitz@wuiet:~$ wanna-build -A all -d unstable --list=installed | wc -l
15672
glaubitz@wuiet:~$

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



signature.asc
Description: OpenPGP digital signature

Re: [Stretch] Status for architecture qualification

[Holger Levsen]

On Sun, Jun 05, 2016 at 01:26:39PM +0200, John Paul Adrian Glaubitz wrote:
> ppc64:
> 
> This architecture is basically on par with the release architectures. We have 
> over
> 11.000 packages installed
[...]
> sparc64:
> We are close to 11.000 installed packages. 

I'm not sure whether you are talking about source or binary packages but
sid/amd64 has over 24000 source packages and over 5 binary packages,
so I would call the above "on par". Or what am I missing?


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: [Stretch] Status for architecture qualification

[John Paul Adrian Glaubitz]

Hi Niels!

On 06/05/2016 12:01 PM, Niels Thykier wrote:
> Beyond mips64el, we are not aware of any new architectures for Stretch.
> 
> I kindly ask you to:
> 
>  * Porters, please assert if your architecture is targeting Stretch.

To give some insight what's happening in Debian Ports. We have two candidates 
which
I think would qualify for inclusion in a stable release. There is also a third
potential candidate for future releases of Debian once the hardware has become
available.

ppc64:

This architecture is basically on par with the release architectures. We have 
over
11.000 packages installed with some fluctuation due to the frequent necessary 
binNMUs
for the Haskell packages. Moreover, yaboot, the bootloader used on many powerpc
machines is now supporting ppc64, too. So building usable debian-installer CD 
images
should be possible:

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322540

Although yaboot still currently FTBFS on ppc64, so someone has to look into 
that.

Both openSUSE and Fedora provide official installation images for ppc64, 
upstream
development in the toolchain and kernel is active, too.

> http://dl.fedoraproject.org/pub/fedora-secondary/releases/23/Server/ppc64/iso/
> http://download.opensuse.org/ports/ppc/distribution/13.2/iso/

To set up buildds and porterboxes, virtual machines could be set up on the same
POWER servers that are used to provide powerpc and ppc64el machines, provided
that there are still enough resources available.

sparc64:

Since sparc (32-bit userland, 64-bit kernel) was dropped after Wheezy, 
development
focus shifted to sparc64 which is fully 64-bit. Upstream development was 
recently
picked up again and both kernel and toolchain are again in active development 
with
many developers being employed by Oracle. They have released a reference 
platform
last fall:

> https://oss.oracle.com/projects/linux-sparc/

I have invested lots of time and effort to get sparc64 into a usable state in 
Debian.
We are close to 11.000 installed packages. Missing packages include Firefox,
Thunderbird/Icedove, golang and LibreOffice to name the most important ones. I
haven't looked into golang yet, but Firefox, Thunderbird and LibreOffice have 
good
chances to be working soon. LibreOffice has just some tests failing in the 
testsuite
thanks to James Clarke who has ported the architecture-dependent code from 
sparc to
sparc64. Firefox and Thunderbird require some fixing in the JavaScript engine:

> https://bugzilla.mozilla.org/show_bug.cgi?id=1275204

There are also some pending patches which fix binutils/gold and gcc-5/6 after 
which
even more packages should build without problems:

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809509
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818934
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792921

Otherwise, many packages mostly fail to build from source because of some bad
programming practices which provokes unaligned access:

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806208

To set up buildds and porterboxes, we would need new hardware. We have some 
older
SPARC Fire T2000 machines running as buildds plus one beefy SPARC-T5 (192 GiB 
RAM,
192 CPU threads), but those are not really suitable as official DSA machines. I
have reached out to Oracle and asked for hardware donations for that matter.

sh4:

This architecture is also known as SuperH and is actually no longer actively
developed and marketed by its developing company, Renesas.

However, there have been interesting developments for this architecture, it is
becoming open source and therefore potentially interesting for many Debian users
and developers who are concerned with privacy and free computing:

> https://lwn.net/Articles/647636/

This has become possible since - as explained in the article above - all patents
related to SuperH are expiring one after another meaning that the hardware can 
be
reimplemented without infringing any patents.

The current result of this effort is the J-Core project:

> http://j-core.org/

The big advantage of Super-H/J-Core over existing open source architectures like
OpenRISC is that both kernel and toolchain are already fully supported so that
Debian can be installed on these machines without any limitations.

We are currently at around 9100 installed packages, a large number of packages 
will
soon be able to build once I have finished bootstrapping GHC (the Haskell 
compiler)
which takes some time on my older SH-7785LCR hardware (still building for 14 
days).


The two biggest issues with sh4 are currently with binutils and the kernel. 
binutils
has problems when building Qt5:

> https://sourceware.org/bugzilla/show_bug.cgi?id=17739

While the kernel needs some additional syscalls to be wired up in the interface 
which
prevents gtk+3.0_3.20.x being built on sh4:

> https://bugzilla.kernel.org/show_bug.cgi?id=119121

As the SH port of the Linux kernel was recently turned into maintained state 
again
after two 

Re: Rename amd64 to klinux-amd64

[Lennart Sorensen]

On Wed, May 11, 2016 at 05:04:06AM -0700, Amir H. Firouzian wrote:
> Hello alls,
> Due to fact that other kernels are become populate like BSD, and Debian is
> universal OS, So is it better to rename all Ports and mention the kernel
> use that inside like kfreebsd-amd64 or khurd-i386?
> 
> https://www.debian.org/ports/

i386 was't renamed when it stopped even supporting i386 and moved to
i486 and later i586.

Too many things already know the port name and depend on it.

I think historical precedence says that Debian is linux unless it says
otherwise in the port name.  linux is implied.

-- 
Len Sorensen

Re: Please explain

[Lennart Sorensen]

On Sat, Jan 09, 2016 at 04:28:18AM -0800, Will Puffenbarger wrote:
> New user need explain for difference between 32 and 64 bit how to get to
> ubuntu faster on smaller device by faking pathways

Well the difference between 32 and 64 bit is:

64 bit x86 has twice as many registers (which makes things a bit faster
in general), can have more memory per process (32 bit is limited to about
3GB per program, while 64 bit is not), and 64 bit uses SSE for floating
point rather than x87, which is also quite a bit faster.  64 bit does use
a bit more memory since pointers are 64 bit rather than 32 bit (In the
future one would be able to get all the benefits of 64 bit x86 except
for the memory limit per process, without the size impact by using the
new x32 architecture, but it is still being worked on).

The rest of your question I can't understand.

-- 
Len Sorensen

Re: chroot debian

[Adam Wilson]

On Sat, 9 Jan 2016 04:19:56 -0800
Will Puffenbarger  wrote:

> Please explain section and how they intermingle and pro's and con's

Are you referring to the component system (main, contrib, non-free)?

Re: Fwd: Re: Bug#571136: please remove useless devices from devices.tar.gz

[Steven Chamberlain]

Hi,

Marco d'Itri wrote:
> On Jan 10, Cyril Brulebois  wrote:
> > We have a bug report with a patch by Marco against debootstrap (see
> > attachment), which changes how devices are generated; I can't really
> > tell how much this might affect all of you (especially with debootstrap
> It is not supposed to, since both hurd and kfreebsd already used 
> a different method to manage /dev.

Yes, the code Marco changed cannot be reached when HOST_OS is kfreebsd*,
freebsd* or hurd*.  kfreebsd devfs provides all the device nodes without
manually creating any or using devices.tar.gz;  even for more exotic use
cases like BSD jails.  hurd appears to have something equivalent.

Thanks for letting us know.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Fwd: Re: Bug#571136: please remove useless devices from devices.tar.gz

[Marco d'Itri]

On Jan 10, Cyril Brulebois  wrote:

> We have a bug report with a patch by Marco against debootstrap (see
> attachment), which changes how devices are generated; I can't really
> tell how much this might affect all of you (especially with debootstrap
It is not supposed to, since both hurd and kfreebsd already used 
a different method to manage /dev.

-- 
ciao,
Marco


signature.asc
Description: PGP signature