Re: debian-installer now available in Ports

2017-04-12 Thread Steven Chamberlain
I've set up some additional jobs at

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

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  I started each
build like this:

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

Steven Chamberlain
diff --git a/ b/
index 99e58ad..08ffbd7 100644
--- a/
+++ b/
@@ -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
+	if [ "${CODENAME}" = "jessie-kfreebsd" ]; then
+		export DI_CODENAME=${CODENAME}-proposed-updates
+	else
+	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.
@@ -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/
 # 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
 # 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):
@@ -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 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=
 # 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

Re: debian-installer now available in Ports

2017-04-12 Thread Steven Chamberlain

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

Steven Chamberlain

Description: Digital signature

Bug#854074: gcc-6: please enable PIE hardening flags by default on kfreebsd-*

2017-02-03 Thread Steven Chamberlain

Matthias Klose wrote:
> [CCing porters, please also leave feedback in #835148 for non-release 
> architectures]

Since that bug is done/closed/actioned, I've cloned a new one for this

> On 29.09.2016 21:39, Niels Thykier wrote:
> > 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).

I think we are ready for this now;  please enable PIE by default on
kfreebsd-* when it is practical (or rather, allow dpkg-buildflags to
enable it).

Steven Chamberlain

Description: Digital signature

Re: [Stretch] Status for architecture qualification

2016-06-05 Thread Steven Chamberlain

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

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

Steven Chamberlain

Description: Digital signature

Re: Time to change the debian-ports list?

2014-09-05 Thread Steven Chamberlain

On 05/09/14 18:39, Steve McIntyre wrote:
  * Remove the confusion: turn debian-ports into a separate *normal*
mailing list, announce it and let people subscribe to it [...]

That sounds perfect IMHO.  It could be used for general discussion about
porting, upcoming new ports, or any ports that don't quite merit having
their own mailing list yet.

debian-cross-ports or debian-architectures or something.

I'd prefer not to have it, or have to sign up to it as a porter.  It'd
probably get more spam than useful mail.

I can't think of a reason to mail *all* ports that wouldn't be
appropriate for debian-devel-announce;  or if your mail only concerns a
few ports it should be convenient to cross-post to the relevant ports'
lists only.

Steven Chamberlain

To UNSUBSCRIBE, email to
with a subject of unsubscribe. Trouble? Contact

Re: preparing for GCC 4.9

2014-05-24 Thread Steven Chamberlain

On 08/05/14 16:25, Matthias Klose wrote:
 I would like to see some partial test rebuilds (like buildd or minimal chroot
 packages) for other architectures. Any possibility to setup such a test 
 for some architectures by the porters? Afaics the results for the GCC 
 look okish for every architecture.

I rebuilt 105 source packages on kfreebsd-amd64 comprising minbase and
build-essential (except for GCC itself) using GCC 4.9 and did not notice
any new build failures introduced by it.

I'll continue to check that the binaries compiled by GCC 4.9 are
actually okay.

The issue with running the GCC testsuite on kfreebsd-amd64 buildds is
being fixed by FreeBSD upstream, and on Debian buildds within 1-2 weeks.

Steven Chamberlain

To UNSUBSCRIBE, email to
with a subject of unsubscribe. Trouble? Contact

Re: A new metric for source package importance in ports

2013-11-27 Thread Steven Chamberlain
Hi josch!

On 27/11/13 17:58, Johannes Schauer wrote:
 One can see that now the amount of source packages which is needed to build 
 rest of the archive is only 383.

So, there are 383 packages that share the same, maximum value (in this
case 11657) in the second column?

 Does anybody see enough value in these numbers for source package importance 
 the light of bootstrapping Debian (either for a new port or for rebuilding the
 archive from scratch)?

I find the list of 383 packages interesting, at least.  I think this
closure is what I had in mind[0] for regular testing of ports'
toolchains and reproducibility of builds.  Because each Debian port
depends in some indirect way on the authenticity of these packages.  And
likewise any toolchain bugs are most critical here.  I just didn't think
there would be so many packages.

Does the list vary by architecture?  I see many odd things in here such
as 'systemd' and 'redhat-cluster' which would be unavailable if trying
to bootstrap a non-Linux port, for example.

I also find it interesting to see openjdk-7 listed but not gcj;  or even
gcc-4.8.  Was this computed for jessie or sid?


Steven Chamberlain

To UNSUBSCRIBE, email to
with a subject of unsubscribe. Trouble? Contact

Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))

2013-11-05 Thread Steven Chamberlain

On 05/11/13 18:50, Don Armstrong wrote:
 On Tue, 05 Nov 2013, Don Armstrong wrote:
 This sounds like a case where we should turn these usertags into fully
 fledged tags. [Or alternatively, they should just be made usertags under
 the user or similar.]

Either of those sounds good.  Fully-fledged tags would be the easiest
for most reporters to remember to use, but I wonder if this pollutes the
tag namespace.

 [Or multiple pseudopackages.]
 Something like or similar would work, with each
 current port getting a pseudopackage, and the maintainer of the
 pseudopackage being the ports list.

Would that be only for generic issues with a port, not specific to a
package?  I doubt this would be used much.  These bugs might typically
be reassigned to kernel packages or eglibc anyway.

Steven Chamberlain

To UNSUBSCRIBE, email to
with a subject of unsubscribe. Trouble? Contact

Re: Bits from the Release Team (Jessie freeze info)

2013-10-23 Thread Steven Chamberlain
On 22/10/13 23:36, Stewart Smith wrote:
 Jenkins can have slaves on remote hosts, via SSH. It runs a small java
 app there, so as long as the arch has a JVM then you're pretty right.

That may be useful to set up on some arches, for things where Jenkins
needs direct control over CPU-intensive tasks.  Building and testing
d-i, for example.

But for this, I would imagine only the test suite needs to run over SSH,
and the master Jenkins instance just has to process the output?

For the proposed test suite to be as accessible as possible to a
new/upcoming port, the barrier to using it ought to be very low.  A
working JVM is quite a lot to ask, the current openjdk-7 is not even
built for mipsel in more.  mipsel buildds and porterboxes had only 1GB
RAM maximum until now, and that is heavily used already for their
current tasks.

Steven Chamberlain

Description: OpenPGP digital signature

Re: Bits from the Release Team (Jessie freeze info)

2013-10-23 Thread Steven Chamberlain
On 23/10/13 12:55, Stewart Smith wrote:
 Geert Uytterhoeven writes:
 On Wed, Oct 23, 2013 at 12:36 AM, Stewart Smith wrote:
 Jenkins can have slaves on remote hosts, via SSH. It runs a small java
 app there, so as long as the arch has a JVM then you're pretty right.

 For whatever definition of small. I've seen it consuming 1 GiB of
 with 'm68k' in your email address your definition of small is likely
 much different than my many years in large scale databases small :)

Come to think of it, it must take a day or more for m68k to rebuild
eglibc.  This is a more serious problem than resources needed by
Jenkins.  We can't ask them to rebuild their entire toolchain each night!

For the goal of software freedom, it shouldn't be too difficult for
anyone to do that, though.  We should be trying to make it easier.

Maybe it would be permissible for the toolchain test suite to run on a
faster platform, and cross-compile, or use any sort of emulation
available in Debian free packages.

If it were technically feasible for each Debian port to rebuild its
toolchain and some essential packages, at least once per week, I think
that would be an accomplishment.  And the smaller the initial set of
packages required to boostrap the process, the better.

Steven Chamberlain

Description: OpenPGP digital signature

Re: Bits from the Release Team (Jessie freeze info)

2013-10-22 Thread Steven Chamberlain
Hi Niels,

This was quite interesting as it seems to tie in with some other
projects that are already being pursued...

On 21/10/13 16:42, Niels Thykier wrote:
 I would love for us to have an automated system to give us a
 weather-report on the toolchain for each architecture.  It would be
 nice both for us to see how ports are doing and for porters to spot and
 fix problems early.

That sounds a lot like the purpose of Jenkins[0], but I'm not sure if
it's exactly suitable.  It seems a little heavy, that someone could more
easily be able to script some cron jobs for a task than learn how to use it.

And Jenkins isn't available yet on all arches;  some ports may not have
hardware powerful enough to run it.  Maybe that doesn't matter - a
single Jenkins instance might be able to launch jobs via remote shells
to other boxes, running the actual test suite there, or maybe just to
fetch, analyse and report on the resulting log files.

Ideally I'd like to see a set of command-line scripts runnable either
from cron, or maybe someday by Jenkins jobs if someone wants to set that
up.  And packaged up for people to use at home!


 Which implies a set of packages being the current version of the
 overwhelming part of the archive plus all of d-i.  However, that is not
 something you just build, so having a smaller set as a basic test
 would probably be way more useful.  I am not aware of such a basic test
 set, so feel free to propose one.

Some people have been trying to identify small sets of essential
packages already, in the context of bootstrapping an architecture[1].  I
wonder if that's likely to overlap with this?  It encompasses toolchain
and essential arch-specific packages.

I imagine a healthy port should be able to bootstrap itself with only
current package versions.  If this was being tested regularly it could
let porters know if circular dependencies are introduced, for example.


I would maybe take that a little further and say that a system is only
stable if it can bootstrap itself, install and boot into the resulting
system, and repeat the whole process again...

 I like the toolchain nightly thing as well. I don't think it is
 required, but it sounds like the kind of thing that would help people
 spot issues sooner rather than later!

And this also ties in with the reproducible-builds project[2] (not sure
if you were hinting at that before).  The 'toolchain' is of particular
concern because the security of the whole system depends on it.
Differences in the output of builds needs to be avoided, or otherwise
explained.  It would help greatly if there were frequent builds
happening so we could see unexpected changes occurring.


So if something can make something that fulfills all the above goals it
would certainly be beneficial :)

Steven Chamberlain

To UNSUBSCRIBE, email to
with a subject of unsubscribe. Trouble? Contact

Bug#725385: FTBFS on s390x: test suite causes segfault

2013-10-04 Thread Steven Chamberlain
Package: spek
Version: 0.8.2-3
Severity: serious
Justification: fails to build from source (but built successfully in the


The spek test suite crashes, apparently only on s390x, and reproduced on
two different buildds:

 make  check-TESTS
 make[3]: Entering directory 
 audio info: 1ch-96000Hz-24bps.flac
 /bin/bash: line 5: 31724 Segmentation fault  ${dir}$tst
 FAIL: test
 1 of 1 test failed
 make[3]: *** [check-TESTS] Error 1

On 04/10/13 22:41, Aurelien Jarno wrote:
 [...] a quick look seems to show the problem is in libav, though I haven't
 looked in details yet.
 #0  0x03ff80002388 in ?? ()
 #1  0x03fffc982312 in ?? () from 
 #2  0x03fffc987a82 in avformat_open_input () from 
 #3  0x800057ca in Audio::open (this=this@entry=0x3e7900f, 
 file_name=...) at
 #4  0x800027e8 in test_file (info=..., name=...) at
 #5  operator() (__closure=optimized out) at
 #6  std::_Function_handlervoid(), 
 test_audio_info()::__lambda0::_M_invoke(const std::_Any_data ) 
 (__functor=...) at /usr/include/c++/4.8/functional:2071
 #7  0x80003252 in test_audio_info () at
 #8  0x800024e0 in main () at

Steven Chamberlain

To UNSUBSCRIBE, email to
with a subject of unsubscribe. Trouble? Contact

Re: Current and upcoming toolchain changes for jessie

2013-06-13 Thread Steven Chamberlain

On 13/06/13 13:51, Matthias Klose wrote:
 GCC 4.8 is now the default on all x86 architectures, and on all ARM
 architectures (the latter confirmed by the Debian ARM porters).  I did not get
 any feedback from other port maintainers, so unless this does change and port
 maintainers get involved with toolchain maintenance, the architectures staying
 at 4.6 or 4.7 shouldn't be considered for a successful release 

I trust these are the architectures that are okay so far:
| gcc48_archs = amd64 armel armhf arm64 i386 x32 kfreebsd-amd64
kfreebsd-i386 hurd-i386

So the following would be the architectures for which some response is
requested urgently from port maintainers, to confirm they are ready for
GCC 4.8 as default:

Release arches: ia64 mips mipsel powerpc s390 s390x sparc

All the above have built gcc-4.8.1-2 or higher.

Other ports:  alpha hppa* m68k powerpcspe ppc64 sh4* sparc64*

* these ports don't appear to have successfully built GCC 4.8 yet.

Steven Chamberlain

To UNSUBSCRIBE, email to
with a subject of unsubscribe. Trouble? Contact