Bug#657598: freebsd-libs: FTBFS on kfreebsd-i386
Package: freebsd-libs Version: 8.3~svn229725-3 Severity: serious Hi, Log from the buildd[1]: """ Warning: Object directory not changed from original /build/buildd-freebsd-libs_8.3~svn229725-3-kfreebsd-i386-AkvhUR/freebsd-libs-8.3~svn229725/lib/libcam cc -Wall -g -pipe -fPIC -I. -I/build/buildd-freebsd-libs_8.3~svn229725-3-kfreebsd-i386-AkvhUR/freebsd-libs-8.3~svn229725/sys -D_GNU_SOURCE -isystem /usr/include/bsd -DLIBBSD_OVERLAY -D__va_list=__builtin_va_list -O2 -isystem /usr/include/freebsd -I/build/buildd-freebsd-libs_8.3~svn229725-3-kfreebsd-i386-AkvhUR/freebsd-libs-8.3~svn229725/debian/local/include -I/build/buildd-freebsd-libs_8.3~svn229725-3-kfreebsd-i386-AkvhUR/freebsd-libs-8.3~svn229725/lib/libcam -I/build/buildd-freebsd-libs_8.3~svn229725-3-kfreebsd-i386-AkvhUR/freebsd-libs-8.3~svn229725/lib/libcam/../../sys -std=gnu99 -fstack-protector -c camlib.c In file included from /build/buildd-freebsd-libs_8.3~svn229725-3-kfreebsd-i386-AkvhUR/freebsd-libs-8.3~svn229725/sys/cam/cam_ccb.h:39:0, from camlib.c:41: /usr/include/sys/callout.h:43:26: fatal error: sys/_callout.h: No such file or directory compilation terminated. *** Error code 1 """ A timly fix would be much appreciated as this blocks some of the last parts of the mono transition. Thanks, ~Niels [1] https://buildd.debian.org/status/package.php?p=freebsd-libs -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120127105745.4176.10690.report...@mikazuki.thykier.net
Re: libbatik-java change led to uninstallables on kfreebsd
Package: libbatik-java Version: 1.7+dfsg-2 Severity: serious On Jun 22, 2012 22:50 "Steven Chamberlain" wrote: > Hi, > Hi, > libbatik-java's dependencies were changed recently like so: > > > Package: libbatik-java > > Architecture: all > > -Depends: openjdk-6-jre-headless | java2-runtime-headless, > > +Depends: openjdk-6-jre-headless | openjdk-7-jre-headless | > > java7-runtime-headless, > > Unfortunately this seems to have made about 120 packages uninstallable > in sid on kfreebsd-*. > I can see how that is less than optimal. > > [...] > > Or was this simply a mistake and should java2-runtime-headless still > be in that list? > > Thanks, > Regards, I think the best solution is to split out the binaries from libbatik-java; that should allow use to remove the JRE dependencies per Java Policy. As for the JRE dependencies, I think the java2-runtime-headless might have been a mistake (and should have been java6 + java7). I will check up on that. ~Niels -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120623081415.84301832ce...@bmail02.one.com
Please build test libsysactivity 0.5.4-5 on x86 BSD machine with > 4 GB RAM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi
As the subject suggests I would like a build test of libsysactivity on an
x86 machine with 4 GB RAM (or more). The new version of libsysactivity
carries some patches to properly calculate memory on BSD machines.
The problem I would like to assert that the patches fix is that there
are no longer integer overflows when calculating memory on a x86 BSD
machine with 4 GB RAM.[1]
libsysactivity 0.5.4-5 is available from:
-
http://mentors.debian.net/debian/pool/main/l/libsysactivity/libsysactivity_0.5.4-5.dsc
- git clone git://git.debian.org/collab-maint/libsysactivity.git
You can also just fetch 0.5.4-4 from the archive and apply the attached
debdiff.
Thank you in advance,
~Niels
Note: I am not subscribed to any of the BSD lists; please CC me directly,
if you for some reason do not want to CC the bug.
[1] The observant reader will notice that the patches also fix an issue
for 64bit machines. Feel free to do a verification test of that as well if
you got a 64 bit machine with +4 GB RAM; however I already got a
successful test build with those. :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Topal (http://freshmeat.net/projects/topal)
iEYEAREIAAYFAkyKD38ACgkQVCqoiq1YlqxFTwCfdTo3FOj8gqNfXRYPJLtxpSiA
r4cAoOXFwM7CEwhpIbuMMfx8DjczGgZT
=N2U2
-END PGP SIGNATURE--BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iEUEABEIAAYFAkyKDeQACgkQVCqoiq1YlqzEnwCY0qgeciuPAvwt3ieMsFk0YUjZ
YACfQK12MTI/3SZJX6UnaPnp0w2nyUE=
=js8G
-END PGP SIGNATURE-
Description: Packaging diff between 0.5.4-4 and 0.5.4-5.
.
Assumes patches have been applied and will apply new paches.
diff --git a/debian/changelog b/debian/changelog
index 33fc5a8..0253e5a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+libsysactivity (0.5.4-5) unstable; urgency=low
+
+ * Added patch to fix the issue with calculating memory on kFreeBSD
+based architectures for machines with > 4 GB RAM.
+(Closes: #594594)
+ * Added patch to disable "cpu idle" test, which causes build
+failures due to false positives.
+
+ -- Niels Thykier Fri, 10 Sep 2010 12:11:25 +0200
+
libsysactivity (0.5.4-4) unstable; urgency=low
* Applied patch from upstream to fix an issue with calculating memory
diff --git a/debian/patches/disable-cpu-idle-test.patch
b/debian/patches/disable-cpu-idle-test.patch
new file mode 100644
index 000..bddf75e
--- /dev/null
+++ b/debian/patches/disable-cpu-idle-test.patch
@@ -0,0 +1,17 @@
+Description: Disables the "cpu idle" test; the test causes
+ build failures due to false positives.
+Origin: upstream
+
+diff --git a/test/test_cpu.c b/test/test_cpu.c
+index ae5b35a..44d86ef 100644
+--- a/test/test_cpu.c
b/test/test_cpu.c
+@@ -58,7 +58,7 @@ void print_cpu_info(struct sa_cpu* cpu) {
+ }
+
+ void test_cpu_info(struct sa_cpu* cpu) {
+-#ifdef SA_CPU_IDLE
++#if 0
+ if (cpu->idle != 0) {
+ printf("\nERROR: Idle is not zero\n");
+ exit(EXIT_FAILURE);
diff --git a/debian/patches/freebsd-memory-64bit.patch
b/debian/patches/freebsd-memory-64bit.patch
new file mode 100644
index 000..f20cb50
--- /dev/null
+++ b/debian/patches/freebsd-memory-64bit.patch
@@ -0,0 +1,66 @@
+Description: Backported fix for an int overflow when
+ calculating memory on FreeBSD machines.
+ .
+ Note: this is a partial patch which is needed together
+ with freebsd-memory-int-overflow.patch
+Origin: upstream
+Bug-Debian: http://bugs.debian.org/593018
+
+diff --git a/src/FreeBSD/memory.c b/src/FreeBSD/memory.c
+index 4c57efa..1897943 100644
+--- a/src/FreeBSD/memory.c
b/src/FreeBSD/memory.c
+@@ -53,35 +53,37 @@ int sa_get_memory(struct sa_memory* dst) {
+ if (dst == NULL)
+ return EINVAL;
+
+- size_t tmp;
+- size_t len = sizeof dst;
+- if (sysctlbyname("hw.physmem", &tmp, &len, NULL, 0) == -1)
++ uint64_t tmp64 = 0;
++ size_t len = sizeof tmp64;
++ if (sysctlbyname("hw.physmem", &tmp64, &len, NULL, 0) == -1)
+ return ENOSYS;
+- dst->total = tmp;
++ dst->total = tmp64;
+
+- if (sysctlbyname("vm.stats.vm.v_free_count", &tmp, &len, NULL, 0) == -1)
++ if (sysctlbyname("vfs.bufspace", &tmp64, &len, NULL, 0) == -1)
+ return ENOSYS;
+- dst->free = tmp * page_size;
++ dst->buffers = tmp64;
+
+- if (sysctlbyname("vfs.bufspace", &tmp, &len, NULL, 0) == -1)
++ uint32_t tmp32;
++ len = sizeof tmp32;
++ if (sysctlbyname("vm.stats.vm.v_free_count", &tmp32, &len, NULL, 0) ==
-1)
+ return ENOSYS;
+- dst->buffers = tmp;
++ dst->free = (uint64_t) tmp32 * page_size;
+
+- if (sysctlbyname("vm.stats.vm.v_cache_count", &tmp, &len, NULL, 0) ==
-1)
++
Roll call for porters of architectures in sid and testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, As we announced in [LAST-BITS], we would like to get a better idea of that status of the ports, to make an informed decision about which port can be released with jessie. One of the steps is to get an overview of which of the porters are (still) active for each port. Once the results from the role-call are in, we will request other information about the status of the ports. In the meantime, feel free to update and collect info about the ports in the Debian wiki[WIKI]. If you are (or intend to become) an active porter for the lifetime of jessie, then please send a signed email explaining your involvement in the port to the Release Team before 1st of October 2013. Please explain the level of your involvement in the port. Feel free to use the following template as your reply: """ Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the jessie release: For , I - test (most|all) packages on this architecture - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - maintain buildds - ... """ Niels, on behalf of the release team [LAST-BITS] http://lists.debian.org/debian-devel-announce/2013/08/msg6.html [WIKI] https://wiki.debian.org/ArchiveQualification/Jessie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJSIu2TAAoJEAVLu599gGRC86EP/j/7FEZ9pxpTEHrBI41GTu6r nENS5kAZAuxFQHfYLtKexBcgneGd6cgdmr3cIoh1ZL9lJgXq74X8FL5IbWNqUw9S o9UQWpZJiwIIlH4fqSgFVLIphI0DQr7dXI7xcDIm4kl6Fdruo1tGxX8xqL23jzdP nQb3jrXv3bj5943MfWeCbODILv2N6qev9VtWeQ6Wmh8PvxRUl7VqgdQaeHtlMsUp TQT5fz0cw8gc2amlwlOZxaGDV2C8mHboJIKMEsu79BK4SlFSED9rXn4juFPUnAgG uADsMdBBqEIgSMN42cPHQju+KLfJe/+xScmlzzDS/d7aWWs02TibcQ1ZnPi+bcgp bd/Wa0lms+Fc2OpcuFle9Lwo+2B+ka1Dd3itm+D0SbmrxoGi6CuMMwydLcQbSJ73 hHw9HJEIQr2x/ZItNPJrSvvj50rwYXcmFbxtVAwv2pFXfQ37iukYgAaaMvnwpNNJ 6dM1coCF9skNkXLO8rkZ+5aupGgjpS9BdKKAEQrPy/aoaW9KNCZrLQeA4C3QySBU OcCNBv7taSjVAVNszKtRIQpu2gzFGAV0u9Gj41qW1JzDHYrmAvMyGxrndOxTmaFr p05QWgcMsPhNvdHjd6sWLyzJ5NYUKksCPMRgCc0BEd6moIyrt7UFsp2+guJZPBJ0 pffEJGK2iGtrWmJfElof =TUeZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130901073351.a92862...@thykier.net
Re: Roll call for porters of architectures in sid and testing (Status update)
On 2013-09-01 09:33, Niels Thykier wrote: > Hi, > > As we announced in [LAST-BITS], we would like to get a better idea of > that status of the ports, to make an informed decision about which > port can be released with jessie. One of the steps is to get an > overview of which of the porters are (still) active for each > port. Once the results from the role-call are in, we will request > other information about the status of the ports. In the meantime, feel > free to update and collect info about the ports in the Debian wiki[WIKI]. > > If you are (or intend to become) an active porter for the lifetime of > jessie, then please send a signed email explaining your involvement in > the port to the Release Team before > 1st of October 2013. Please explain the level of your involvement in > the port. > > Feel free to use the following template as your reply: > > [...] > > Niels, on behalf of the release team > > [LAST-BITS] > http://lists.debian.org/debian-devel-announce/2013/08/msg6.html > > [WIKI] https://wiki.debian.org/ArchiveQualification/Jessie > Hi all, Here is a little status update on the mails we have received so far. First off, thanks to all the porters who have already replied! So far, the *no one* has stepped up to back the following architectures: hurd-i386 ia64 mips mipsel s390x I have pinged some people and #d-hurd, so this will hopefully be amended soon. Remember that the *deadline is 1st of October*. In the list above, I excluded: amd64 and i386: requirement for porters is waived s390: Being removed from testing during the Jessie cycle (Agreement made during the Wheezy release cycle) The following table shows the porters for each architecture in *unstable* that I have data on so far: armel: Wookey (DD) armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD) kfreebsd-amd64: Christoph Egger (DD), Axel Beckert (DD), Petr Salinger (!DD), Robert Millan (DD) kfreebsd-i386: Christoph Egger (DD), Axel Beckert (DD), Petr Salinger (!DD), Robert Millan (DD) powerpc: Geoff Levand (!DD), Roger Leigh (DD) sparc: Axel Beckert (DD), Rainer Herbst (!DD) If you are missing from this list above, then I have missed your email. Please follow up to this mail with a message-ID (or resend it, whichever you prefer). We also got a number of people interested in architectures not currently in unstable. These are: alpha: Bill MacAllister (!DD), Kieron Gillespie (!DD) arm64: Wookey (DD) parisc/hppa: Helge Deller (!DD) ppc64: Steven Gawroriski (!DD) sparc64: Steven Gawroriski (!DD), Kieron Gillespie (!DD) This will hopefully teach me to remember to include the "in unstable" restriction to the next "roll call". :) Anyhow, if you are working on these architectures on debian-ports and saw a new name in the list above, this might be an opportunity to recruit new people. We also received a couple of emails from people who are not or did not want to be porters at the moment. However, they expressed an interest in the architectures: David Kuehling: mipsel - debug arch-related issues Meelis Roos: ppc, sparc64 (parisc) - test and report bugs in upstream kernel Peter Green: armhf (possibly any-arm) - works on raspbian In the template email included in the roll call, we included some tasks that people might be doing. These are the task people have said they are doing for a given port. * test packages: armhf, kfreebsd-amd64 (x4), kfreebsd-i386 (x4), powerpc, sparc (x2) * fix toolchain issues: armhf, powerpc * triage arch-specific bugs: armhf, kfreebsd-amd64 (x3), kfreebsd-i386 (x3), powerpc, sparc (x2) * fix arch-related bugs: armhf, kfreebsd-amd64 (x3), kfreebsd-i386 (x3), powerpc * maintain buildds: armhf, kfreebsd-amd64, kfreebsd-i386 NB: I have manually translated some prose-text into the items above, so something might have been lost (or gained) in that translation. Some of the porters also added some new items. I have included some of these items below: + test d-i "when needed": powerpc (x2) + maintain arch-related pkgs: kfreebsd-amd64, kfreebsd-i386 + maintain non-DSA porter box: kfreebsd-amd64 + maintain production system of $arch: sparc/stable + can offer hardware access[1]: sparc (Axel Beckert) + eglibc issues: kfreebsd-amd64, kfreebsd-i386 + maintain+test cross-toolchains for $arch: armel, armhf ~Niels [1] Restrictions may apply. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/523ab805.7000...@thykier.net
Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)
Hi, The final results are in: Summary table: Arch || DDs || NMs/DMs || Other || Total ---++-++-++---++-- armel || 3 || 0 || 1 ||4 armhf || 3 || 1 || 2 ||6 hurd-i386 || 5 || 0 || 3 ||8 ia64 || *0* || 0 || 3 ||3 kfreebsd-amd64 || 4 || 0 || 2 ||6 kfreebsd-i386 || 4 || 0 || 2 ||6 mips || 1 || 0 || 1 ||2 mipsel || 1 || 0 || 1 ||2 powerpc[1] || (1) || 0 || 2 || 2.5? s390x || *0* || 0 || 0 || *0* sparc[2] || 1 || 0 || 0 ||1 [1] The (1) and .5 is from a "I am not primarily a porter [...]"-remark, so I wasn't sure how to count it. [2] By the looks of it, if sparc was replaced by sparc64, we could be looking at 3 in the "Other"-column rather than 0. NMs/DMs include DMs and people currently in NM process. The "Other" column may include people who said they would like to become porters (but would need to be introduced to the job) and thus may imply some active recruiting from the current porters. This is at least true for hurd-i386. The current policy says that we require "5 developers" (i.e. DDs) for release architectures[AP], so based on that only amd64, i386 and hurd-i386 would pass this requirement. It is quite possible we need to revise that requirement, but most of the architectures would (still) do well to attract a few more (DD) porters. I have attached a file with my notes of who are behind those numbers. If your name is missing or you believe I have miscounted something[CD] for an architecture listed in the table above, please reply to this email *promptly* (CC'ing me explicitly is fine) with your concerns or corrections. At this time, I have *not* updated the arch qualification table yet. I will do that in a couple of days. We will also follow up on this in the next bits from the release team. ~Niels [AP] http://release.debian.org/jessie/arch_policy.html [CD] I may (or may not) have been caffeine-deprived when I did the counting. You are free to make assumptions about whether that has affected my ability to do addic^Htion or parsing your email(s) properly. Summary table: Arch || DDs || NMs/DMs || Other || Total ---++-++-++---++-- armel || 3 || 0 || 1 ||4 armhf || 3 || 1 || 2 ||6 hurd-i386 || 5 || 0 || 3 ||8 ia64 || *0* || 0 || 3 ||3 kfreebsd-amd64 || 4 || 0 || 2 ||6 kfreebsd-i386 || 4 || 0 || 2 ||6 mips || 1 || 0 || 1 ||2 mipsel || 1 || 0 || 1 ||2 powerpc[1] || (1) || 0 || 2 || 2.5? s390x || *0* || 0 || 0 || *0* sparc || 1 || 0 || 0 ||1 [1] Roger Leigh: "I am not primarily a porter [...]". armel: Wookey (DD), Gatis Visnevskis (!DD), Nobuhiro Iwamatsu (DD), Steve McInture (DD) armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD), Justus Winter (!DD), Lennart Sorensen (!DD), Nobuhiro Iwamatsu (DD), Steve McInture (DD) hurd-i386: Samuel Thibault (DD), Barry deFreese (DD), Thomas Schwinge (!DD), Pino Toscano (DD), Svante Signell (!DD), Michael Banck (DD), Guillem Jover (DD), Zhang Cong (!DD) kfreebsd-amd64: Christoph Egger (DD), Axel Beckert (DD), Petr Salinger (!DD), Robert Millan (DD), Steven Chamberlain (!DD), Guillem Jover (DD) kfreebsd-i386: Christoph Egger (DD), Axel Beckert (DD), Petr Salinger (!DD), Robert Millan (DD), Steven Chamberlain (!DD), Guillem Jover (DD) mips: Graham Whaley (!DD), Andreas Barth (DD) mipsel: Graham Whaley (!DD), Andreas Barth (DD) powerpc: [Roger Leigh (DD)], Geoff Levand (!DD), Lennart Sorensen (!DD) sparc: Axel Beckert (DD) Maybes for ia64 (?): Martin Lucina (!DD), Émeric MASCHINO (!DD), Mark Wickens (!DD) (Some inaccuracies can occur in the (xN) below; /me got confused and may have lost count for some of them) Items suggested in the roll call: * test packages: armel (x3), armhf (x4), hurd-i386 (x4), kfreebsd-amd64 (x6), kfreebsd-i386 (x6), mips, mipsel, powerpc (x3), sparc * fix toolchain issues: armel, armhf (x3), hurd-i386 (x3), mips, mipsel, powerpc (x2) * triage arch-specific bugs: armel (x3), armhf (x4), hurd-i386 (x4), kfreebsd-amd64 (x5), kfreebsd-i386 (x5), mips (x2), mipsel (x2), powerpc (x2), sparc * fix arch-related bugs: armel (x2), armhf (x4), hurd-i386 (x5), kfreebsd-amd64 (x5), kfreebsd-i386 (x5), mips (x2), mipsel (x2), powerpc (x2) * maintain buildds: armhf, hurd-i386 (x2), kfreebsd-amd64, kfreebsd-i386, mips, mipsel Items suggested by porters in their mails: + test d-i "when needed": hurd-i386, powerpc (x3) + maintain arch-related pkgs: kfreebsd-amd64, kfreebsd-i386 + maintain non-DSA porter box: hurd-i386 (x2), kfreebsd-amd64 + maintain production system of $arch: sp
Re: Bits from the Release Team (Jessie freeze info)
On 2013-10-19 16:38, Jeremiah C. Foster wrote: > Hello, > > On Sun, Oct 13, 2013 at 05:01:31PM +0200, Niels Thykier wrote: > > [snip freeze policy] > Hi, I s/-arm/-ports/'ed the CC, since I figured the rest of the porters would find the answer equally interesting. >> Results of porter roll-call >> === >> >> [...] >> >> That said, we would like to encourage porters behind all ports to >> ensure that the toolchain is up to date and working. We are aware of >> at least gcc on mips having its test suite disabled[GCC]. Other ports >> may suffer from similar issues and we hope to have those resolved >> sooner rather than later. We are currently waiting for the gcc >> maintainers to compile a list of such issues. > > So I can extrapolate from this that ensuring that the toolchain is up > to date and working is a key activity of a porter. Yes; build-essential being broken is obviously a problem. But also having the same default compiler on all architectures is also desired. > If my assumption is > correct, is there a complete definition of the "toolchain" as we see > it in Debian that a porter might reasonably be expected to use to do > thier porting? > I do not have an complete list of packages, although it will definitely include build-essential. My intuition is that "toolchain" should include any compiler used by packages on that architecture[1] (e.g. if the arch has built haskell packages, it should have a working haskell compiler as well). But as said, that is my personally view and not an official statement. > In addition, I wonder if there is a way to report the status of the > toolchain and what sort of expectations are there around "up to date"? 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. As for up-to-date, I don't have a complete answer here. I seem to remember the GCC maintainers being frustrated at having to maintain gcc-4.6 (it is apparently still default for some architectures) despite gcc-4.8 being the latest stable release. > Is it expected to build Debian toolchain nightly and run a specific > test suite? Is the expectation that one uses pbuilder and builds a set > of packages? What we got in the policy so far[2]: """ Installer: The architecture must have a working,tested installer. [...] Archive coverage: The architecture needs to have successfully compiled the current version of the overwhelming part of the archive [...] """ 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. 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! > Perhaps this is outlined on the wiki somewhere and if not > perhaps it ought to be? > > Regards, > > Jeremiah > > Having documentation on it would definitely be a good thing. For actual requirements, we should add them to the policy[2], but having a wiki-page of "recommended porter practises/tests" would probably be a nice addition too. ~Niels [1] My rationale for this is that we would like to be able to rebuild/reproduce builds, which would require a working compiler. [2] http://release.debian.org/jessie/arch_policy.html -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52654b6d.9020...@thykier.net
Re: Bits from the Release Team (Jessie freeze info)
On 2013-10-29 16:05, Ian Jackson wrote:
> Niels Thykier writes ("Bits from the Release Team (Jessie freeze info)"):
>> Results of porter roll-call
>> ===
> ...
>> Summary table:
>> Arch || DDs || NMs/DMs || Other || Total
>> - ---++-++-++---++--
>> armel || 5 || 0 || 2 ||7
>> armhf || 6 || 1 || 2 ||9
>> hurd-i386 || 5 || 0 || 3 ||8
>> ia64 || *0* || 0 || 3 ||3
>> kfreebsd-amd64 || 5 || 0 || 2 ||6
>> kfreebsd-i386 || 5 || 0 || 2 ||6
>> mips || 2 || 0 || 1 ||3
>> mipsel || 2 || 0 || 1 ||3
>> powerpc[1] || (1) || 0 || 2 || 2.5?
>> s390x || 1 || 0 || 1 ||2
>> sparc || 1 || 0 || 0 ||1
> ...
>> Based on the number of porters, we are considering changing the
>> current requirements of "5 DDs" to better reflect the reality of the
>> situation. We will follow up in a future bits on the changes.
>
> Thanks.
>
You are welcome. :)
> I think it is disappointing to find that we may be dropping
> architectures where a significant amount of effort is available,
> simply because the volunteers don't have enough status - specifically,
> because of a lack of DDs.
>
As mentioned we are debating whether the "5 DDs" requirement still makes
sense. Would you say that we should abolish the requirement for DD
porters completely? I.e. Even if there are no (soon to be) DDs, we
should consider the porter requirements fulfilled as long as they are
enough "active porters" behind the port[0]?
> I'm keen that Debian should continue to support a wide range of
> architectures. Would it help if I, as a DD, volunteered to sponsor
> porter uploads for any architecture ? That is I guess I'm
> volunteering to become a new kind of person - a "non-port-specific
> porter sponsor".
>
I suppose that could help ports without a DD if we allowed such to be in
testing. However, it is my understanding that our main issue with ports
often is that they are not actively maintained (or appears to lack
active maintenance).
As an example I remember having received several complains from e.g.
the GCC maintainers in regards to the state of gcc on various ports[1].
Here I would suspect a patch would be sufficient without needing to
actually NMU gcc to get the fix in.
There are also stuff like the port concerns from DSA that attention.
> Obviously I will review the debdiff etc. I'm an experienced C
> programmer with some background in C language lawyering and
> portability stuff, so I should usually be able to do a decent review
> of a patch even on an unfamiliar architecture.
>
> In fact, regardless of what the release team decide for the policy, I
> would be happy to sponsor porter uploads. Please just email me.
>
> Ian.
>
>
:)
~Niels
[0] Leaving the definition of "active porter" vaguely defined for now.
[1] Obviously, I haven't been keeping track of them so I had to ask for
a reminder.
https://lists.debian.org/debian-release/2013/10/msg00710.html
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/526fdfe3.7060...@thykier.net
Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On 2013-10-29 17:48, Ian Jackson wrote:
> Niels Thykier writes ("Re: Bits from the Release Team (Jessie freeze info)"):
>> [...]
>> As mentioned we are debating whether the "5 DDs" requirement still makes
>> sense. Would you say that we should abolish the requirement for DD
>> porters completely? I.e. Even if there are no (soon to be) DDs, we
>> should consider the porter requirements fulfilled as long as they are
>> enough "active porters" behind the port[0]?
>
> I don't have a good feel for the answer to that question.
>
> It's just that if it is the case that a problem with ports is the lack
> of specifically DDs, rather than porter effort in general, then
> sponsorship is an obvious way to solve that problem.
>
> If you feel that that's not really the main problem then a criterion
> which counts porters of any status would be better.
>
I suppose a "sponsor-only" DD could be sufficient, provided that the
sponsor knows the porters well enough to be willing to sign off on e.g.
access to porter boxes. I guess the sponsor would also need to dedicate
time to mentor (new?) porters on workflows and on quicks like when is a
FTBFS RC and when it isn't etc.
> (Mind you, I have my doubts about a process which counts people
> promising to do work - it sets up some rather unfortunate incentives.
> I guess it's easier to judge and more prospective than a process which
> attempts to gauge whether the work has been done "well enough".)
>
> [...]
>
> Thanks,
> Ian.
>
>
Ah, you are not the first to question this process. Obviously, we
intend to keep people up on their promise by "actively maintaining their
port". Sadly, we do not have a clear definition of "actively maintained
ports" and I doubt we will have it any time soon either.
But porters can start by working on the concerns from DSA (if they
haven't already done so). Ports having gcc-4.6 as default compiler
might also consider improving in that area[1].
Then there are more concrete things like ruby's test suite seg. faulting
on ia64 (#593141), ld seg. faulting with --as-needed on ia64
(#718047[2]), a lot of ruby packages being stuck on kfreebsd-any due to
ruby2.0 FTBFS (#726095[3]). Personally, I would also expect that
key-packages work on all ports (on which they are built) in general[4].
All of the (non-mild) DSA concerns are already something we will
officially hold against the ports. Most of the other issues listed
above are not official concerns. However, I would not be surprised if
most of them became official issues eventually.
Until we have a clear definition of "actively maintained ports", I would
recommend porters to err on the side of being verbose over being silent.
As an example, lack of visible reply to mails like [5] makes it seem
like nobody is home.
Mind you, I am not saying porters have the responsibility to fix every
problem forwarded to their port list. I am also aware that sometimes
issues/mail "disappear" in the depths of people inbox - heck it happens
to me as well.
Come to think of it; maybe we should have a BTS page for each of the
ports (e.g. a pseudo package in the BTS). That way it would at least be
easier for all people to find outstanding issues for the port[6]. It
would also give us the possiblity to trivial declare a problem RC (or
not) for ports. (Plus, then I won't have to update some random file on
release.d.o for every new issue :P)
Anyhow, I hope to be able to give a more "official" statement in the
near future.
~Niels
[1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be
acceptable as a default for Jessie.
[2] Apparently it is controversial whether that bug should be RC, but it
definitely looks like that kind of thing that will cause issues for ia64
later.
[3] That one got a patch, but it might be worth it to put some pressure
on the maintainer or even doing a NMU.
[4] A rule of thumb could be something like "your port should probably
not be listed here in the long run:
http://udd.debian.org/bugs.cgi?release=jessie_and_sid&merged=ign&keypackages=only&fnewerval=7&flastmodval=7&rc=1&sortby=id&sorto=asc
"
[5] https://lists.debian.org/debian-mips/2013/08/msg5.html
Btw, this is not intended to single out mips.
[6] I know that people have been usertags for issues that affect the
port, but it is not clear to me that all those usertags bugged is
something we expect porters to fix. Rather it seems more like porters
tagging the FTBFS bugs they file.
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52762b6a.5060...@thykier.net
Re: Potential issues for most ports
On 2013-11-03 15:49, Thorsten Glaser wrote: > Niels Thykier dixit: > >> [...] >> Until we have a clear definition of "actively maintained ports", I would >> recommend porters to err on the side of being verbose over being silent. > > I’ve held off on the m68k side because I think the role call was only > for architectures in the main archive, right? > Yes, we are only talking about architectures in the main architecture. >> [1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be >> acceptable as a default for Jessie. > > Didn't Doko say he’d want 4.8? We (on the m68k side) are putting > effort into that one, since 4.7 appears to only be used by eglibc > right now. And 4.6 for GNAT, but gnat-4.8 is new, and the ICE may > be fixed as there’s active upstream on the GCC/m68k side. > > bye, > //mirabilos > I am not entirely up to speed on what he wants; I am still waiting for him to get back to me (see [1]). ~Niels [1] https://lists.debian.org/debian-release/2013/10/msg00710.html -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527671af.7050...@thykier.net
Re: Potential issues for most ports
On 2013-11-03 16:54, Niels Thykier wrote: > On 2013-11-03 15:49, Thorsten Glaser wrote: >> > Niels Thykier dixit: >> > >>> >> [...] >>> >> Until we have a clear definition of "actively maintained ports", I would >>> >> recommend porters to err on the side of being verbose over being silent. >> > >> > I’ve held off on the m68k side because I think the role call was only >> > for architectures in the main archive, right? >> > > Yes, we are only talking about architectures in the main architecture. > s/main arcihtecture/main archive/; ~Niels -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527674bd.2070...@thykier.net
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On 2013-11-03 16:03, Steven Chamberlain wrote: > On 03/11/13 10:54, Niels Thykier wrote: >> Come to think of it; maybe we should have a BTS page for each of the >> ports (e.g. a pseudo package in the BTS). > > We've had this on kfreebsd, due it to having been a release goal: > > http://udd.debian.org/bugs.cgi?release=jessie_or_sid&merged=ign&fnewerval=7&kfreebsd=1&sortby=severity&sorto=desc&cseverity=1&ctags=1 > Actually, I meant a "real" BTS page (e.g. like [1]) rather than "just" a list of tagged bugs. The list of tagged bugs definitely have it uses, but it does not give me an overview of which bugs should be fixed by the maintainer of the given package and which the porters should fix. > It uses usertags, but someone has to set those. Porters usually set > them on bugs they file; but quite often "FTBFS on kfreebsd" bugs are > filed without being tagged or Cc'd to our list, so someone has to > periodically look for and tag things. > > Regards, > In this regard; I am guilty of filing some those bugs without tagging them. Honestly, adding the tags get a bit in the way right now. If a package FTBFS on 4 architectures, I have to dig up 3-4 different usertags (with different "user") and associate it with the bug. Do we have a tool you can give a source package, a version plus a list of architectures and it will generate a bug with the right tags? I think that would help a lot for me. ~Niels [1] http://bugs.debian.org/release.debian.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52789fdb.2000...@thykier.net
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On 2013-11-03 23:04, Steve Langasek wrote: > On Sun, Nov 03, 2013 at 11:54:34AM +0100, Niels Thykier wrote: >> [...] > >> I suppose a "sponsor-only" DD could be sufficient, provided that the >> sponsor knows the porters well enough to be willing to sign off on e.g. >> access to porter boxes. I guess the sponsor would also need to dedicate >> time to mentor (new?) porters on workflows and on quicks like when is a >> FTBFS RC and when it isn't etc. > > Why would the sponsor need to be involved in getting the porters access to > porter boxes? Porter boxes exist so that DDs *not* involved in a port have > access to a machine of the architecture and can keep their packages working. > I've never heard of a porter who didn't have access to their own box for > porting work. > I will not rule out that it was a poor choice of example on my part for ia64 (and maybe powerpc), which is(/are) the concrete port(s) we would be talking in this case. That said, it is my understanding that "one does not simply own an s390(x)"[1]. Nor would I be concerned to have arm porters that worked on all 3 arm ports while possessing hardware only for a (non-empty) subset of those architectures. ~Niels [1] I certainly wouldn't have space for something like this: http://en.wikipedia.org/wiki/File:Z800_2066_JKU.jpeg (and much less the money. Yeah I know that is technically not an s390, but as I understand it, an s390 should be "around that size") -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5278a3e1.30...@thykier.net
Re: Release sprint results - team changes, auto-rm and arch status
On 2013-11-30 11:46, Robert Millan wrote: > On 28/11/2013 21:49, Steven Chamberlain wrote: >> On 28/11/13 20:04, Niels Thykier wrote: >>> kFreeBSD was a technology preview, and has not generated enough >>> user interest to bring in sufficient install base to continue >>> in this state. >>> >>> We will review this situation after 28th January 2014. >>> Architectures still causing us concern at that point will join >>> ia64 in no longer being considered for britney migrations and >>> may be dropped from testing after a further period. >> >> I'm unclear on what this means, or what should happen by that >> date to ensure it is considered sufficient to continue in 'this >> state' (meaning, a release architecture and considered for >> Britney migration?). > Hi, Sorry for the very late reply to this mail. > Uhm I think we both may have misunderstood. Perhaps 'this state' > just means 'as technology preview'. I.e. normal QA requirements are > no longer waived because of preview status. > This is exactly what we meant; we intend to not do technology previews for Jessie. > If that is the case, I think the kFreeBSD port is perfectly capable > of meeting these requirements. The system is quite robust already, > in fact I've used it in production environments several times > (including infrastructure for a major corporation which will remain > unnamed), with very satisfactory results. > We have heard reports of issues with GNOME that are allegedly going on answered or/and are not resolved. These are issues reported to debian-bsd@l.d.o by the GNOME maintainers - the examples I got include [1] and [2]. Disclaimer: I have not had the time to read all examples I got or read the full threads of these examples. Nor did I get these directly from the GNOME maintainers; these are examples provided by members of the release team during the sprint[3]. It would probably be good if you (i.e. the BSD porters) could start a dialogue with the GNOME maintainers and figure out exactly where GNOME is on kFreeBSD (vs. where it is supposed to be). Once that is sorted out, please send the release team a summary of the status so we have accurate information here. ~Niels [1] https://lists.debian.org/debian-bsd/2013/10/msg00144.html [2] https://lists.debian.org/debian-bsd/2013/10/msg00145.html [3] I cannot rule out that they got the examples from the GNOME maintainers. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ada1db.8040...@thykier.net
Re: Release sprint results - team changes, auto-rm and arch status
On 2013-12-16 23:32, Robert Millan wrote:
> On 15/12/2013 13:34, Niels Thykier wrote:
>> It would probably be good if you (i.e. the BSD porters) could start a
>> dialogue with the GNOME maintainers and figure out exactly where GNOME
>> is on kFreeBSD (vs. where it is supposed to be). Once that is sorted
>> out, please send the release team a summary of the status so we have
>> accurate information here.
>
> Will do. But this can't be done right away. The reports you mention are
> too vague ("xxx doesn't work", etc) to act upon. We will first need to
> evaluate the current state of things to have an accurate idea on where
> we stand regarding GNOME.
>
Hi Robert / BSD porters,
Any news on your front on the status of GNOME on kFreeBSD?
The other day, I was told on IRC that some of the glib tests had been
disabled / ignored on kFreeBSD (see #649196 and #712848). I have not
reviewed them in detail, though the former have no follow up at all (but
I don't see a CC either, so I guess that is not surprising).
~Niels
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52c9264b.1050...@thykier.net
Re: Release sprint results - team changes, auto-rm and arch status
On 2014-01-05 12:22, Robert Millan wrote:
> On 05/01/2014 10:30, Niels Thykier wrote:
>> On 2013-12-16 23:32, Robert Millan wrote:
>>> On 15/12/2013 13:34, Niels Thykier wrote:
>>>> It would probably be good if you (i.e. the BSD porters) could start a
>>>> dialogue with the GNOME maintainers and figure out exactly where GNOME
>>>> is on kFreeBSD (vs. where it is supposed to be). Once that is sorted
>>>> out, please send the release team a summary of the status so we have
>>>> accurate information here.
>>>
>>> Will do. But this can't be done right away. The reports you mention are
>>> too vague ("xxx doesn't work", etc) to act upon. We will first need to
>>> evaluate the current state of things to have an accurate idea on where
>>> we stand regarding GNOME.
>>>
>>
>> Hi Robert / BSD porters,
>>
>> Any news on your front on the status of GNOME on kFreeBSD?
>
Hi,
> So far #733122. Barring that, the GNOME desktop seems to work fine (including
> empathy, nautilus, etc). Once the patch in #733122 is applied, it will be
> easier
> to gather reports from day-to-day users and provide a more complete
> assessment.
>
Thanks for looking into this. I have asked on #d-gnome about the patch
you submitted; hopefully it can be applied soon, so we can get a better
view.
> GDM is a different story (see #733546). The problem goes much deeper though.
> It's
> now begun to use SystemD by default, and then falling back to ConsoleKit when
> that's not available. There are two serious problems with this:
>
> - The GDM->ConsoleKit codepath is seldom tested. We don't know if it's
> actually
> working.
>
> - According to upstream website, ConsoleKit is deprecated and not actively
> maintained.
>
> We can help as porters but we can't maintain abandoned codepaths on our own. I
> think GDM upstream doesn't want to deal with this problem, so perhaps it is
> better
> if we accept that GDM is not a portable program anymore, and make it
> Linux-only.
>
Do you have an idea of the consequences of making it linux-only? If it
is just using (e.g.) xdm instead of and kFreeBSD losing a couple of
packages, it will probably not be much of an issue. But then, I assume
that GNOME and GDM are not tightly coupled.
> And then there's #734070 which AFAICT only results in a few harmless errors
> (still,
> it'd be nice to have it merged, just in case).
>
Good. :)
>> The other day, I was told on IRC that some of the glib tests had been
>> disabled / ignored on kFreeBSD (see #649196 and #712848). I have not
>> reviewed them in detail, though the former have no follow up at all (but
>> I don't see a CC either, so I guess that is not surprising).
>
> #649196 is probably not an issue anymore. We've replaced our thread
> implementation
> since.
>
Okay, perhaps you could follow up on the bug with that information and
ask if it is still an issue?
> As for #712848, the latest comment sent by Petr suggested that the test might
> be
> incorrect when applied to kqueue.
>
I guess you are referring to comment #25 here? Quote:
"""
This test is guarded by:
[...]
The kqueue support might have the same limit.
I do not know whether is better to use kqueue via gamin
or kqueue directly in glib2.0.
Petr
"""
Seems like no one picked it up from there. To be honest, I am not sure
where the ball is on that bug right now - as an outsider it is not clear
to me if Petr is asking for the GNOME maintainers or the BSD porters to
follow/second him. Admittedly, I have very limited knowledge of the
code in question, so it may be more obvious to you.
Perhaps you could follow up on the bug and prod the GNOME maintainers
for a follow up, if you believe the ball is in their court right now.
~Niels
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d1aa50.8000...@thykier.net
Re: Release sprint results - team changes, auto-rm and arch status
On 2014-01-11 23:10, Robert Millan wrote: > On 11/01/2014 21:32, Niels Thykier wrote: >>> As for #712848, the latest comment sent by Petr suggested that the test >>> might be >>> incorrect when applied to kqueue. >>> >> >> I guess you are referring to comment #25 here? Quote: >> >> [...] >> >> Seems like no one picked it up from there. To be honest, I am not sure >> where the ball is on that bug right now - as an outsider it is not clear >> to me if Petr is asking for the GNOME maintainers or the BSD porters to >> follow/second him. Admittedly, I have very limited knowledge of the >> code in question, so it may be more obvious to you. >> Perhaps you could follow up on the bug and prod the GNOME maintainers >> for a follow up, if you believe the ball is in their court right now. > > Before we get into that, would it be possible to establish the severity of > this bug? Specifically, whether it is Release-Critical or not. > > It is currently marked as non-RC, and so far we haven't seen any indication > that it produces actual breakage (outside the testsuite, that is) [1]. > It was filed as serious and then downgraded by Julien on July 9th. Indeed, buildd.d.o lists no build problems at all. So at first glance I would expect the tests to have been disabled/ignored. Assuming this is no a simple "error-hiding" tactics, then the bug is non-RC. If it hides user-visible errors, then the severity depends on the (consequences of the) errors hidden. > However, your comments in this and earlier mails seem to imply that it is > RC, or that you think it could be. > I had no intention of making such an implication. From what I gathered from various sources, glib and GNOME on kFreeBSD had issues and that is what I am following up on. > In our experience as porters, we've found that we get lots of testsuite > failures (and not just in GNOME). However, often the tests just fail because > they're overzealous, or because they make wrong (unportable) assumptions > about the underlying APIs. > The assumption here is that the test is indeed overzealous / not relevant to kFreeBSD and have no value as a regression test on kFreeBSD. If that is indeed the case, by all means (have the maintainer) disable the test on kFreeBSD and close the bug. The concern from my point of view, is if a valid test is disabled when it could have been ported. The last thing I want is to have an RC bug appear in testing for a problem the regression test suite from upstream could have caught. > I believe #628383 would be a good example of what I'm saying. But the problem > is very typical. It's not uncommon for us to submit fixes for testsuite bugs > rather than having to fix the bugs the tests are supposed to find. > I believe that is perfectly fine to fix portability issues in the tests themselves. > Probably Petr and/or Steven can elaborate more on this, since they've been > much > more actively involved than me in this kind of work. > Ok. > [1] If the reason it is RC is that it causes FTBFS (and serious buildd grief), > I think http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734290#10 is a > good solution in that regard. > This particular kind of resolution would concern me. Simply disabling all tests and ignoring all problems would undermine any value of the regression test suite (on non-Linux ports in this case) and allow RC bugs to migrate to testing before they are noticed. With my release hat on, I want as many problems stopped before they reach testing. Having a build-time regression test suites from upstream is certainly valuable in this regard and we currently have no replacement for testing the actual program itself. ~Niels -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d25121.5040...@thykier.net
Re: gdm3
On 2014-01-12 00:01, Robert Millan wrote: > On 11/01/2014 22:54, Robert Millan wrote: >>> Do you have an idea of the consequences of making it linux-only? If it >>> is just using (e.g.) xdm instead of and kFreeBSD losing a couple of >>> packages, it will probably not be much of an issue. But then, I assume >>> that GNOME and GDM are not tightly coupled. >> >> Yes, I think that's the case. I still have to look a bit more carefully >> though, so >> please don't take my word on it. >> >> I'll followup on this. > > See #735023. Result of my tests is included there. > Thanks for testing it (and for looking into #649196). ~Niels -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d2519e.5020...@thykier.net
Re: Bits from the Release Team: Architecture health check
On 2014-01-29 23:24, Steven Chamberlain wrote: > On 29/01/14 22:11, Robert Millan wrote: >> On 29/01/2014 19:41, Niels Thykier wrote: >>> * kfreebsd-amd64 and kfreebsd-i386 >>>- On one hand, we are unconvinced that kFreeBSD will be able >>> to be on par with other release architectures in terms of >>> supported packages for Jessie. >>>- On the other hand, we believe kFreeBSD could be improved by >>> reducing the scope of the port for Jessie. >> >> Could you elaborate? I.e. what is the problem and what solution you >> have in mind. > > What exactly does the 'scope of the port' mean? Suites of packages, > tasksel tasks, desktop environments? Particular use cases (server, > laptop, desktop)? Or something else? > Hi, I believe this is a first for us (as well) - at the very least, I won't claim to have all the answers. Anyhow, as I see it, we want you to choose a set of supported packages, then we will probably ask how / why you made that choice and, quite possibly, poke a bit at making you choosing a slightly larger set etc. So, at this point, I think that you get to choose an initial draft for the "scope of the port". Of course, I don't expect you to list some 18k+ source packages, so defining it as something like "Desktop environments except GNOME plus tasksel task X, Y and Z". Alternatively, you may want to define it as the set of packages you won't support (e.g. "KDE, all webservers (except apache2 with PHP5), etc.") In fact, it is probably best for you if you combine the two approaches. But anyhow, you get to serve the ball on this one. Just remember, we will probably ask "why did you choose this set?" (or maybe even "what would it take for you to also support Y?") > I'm grateful we've been given another 2 months to work on this. You are welcome. > The > init system debate might have come to a conclusion by then, and it could > have some bearing on this. If some packages (potentially the whole > GNOME desktop environment) get a hard systemd dependency that would > somewhat reduce the scope of the port for us I think. > > Regards, > I believe Robert already concluded that GDM was likely a lost cause for kFreeBSD atm. I suppose that is what you are referring to? @Robert: Re your "Could you elaborate?". I haven't forgotten it, but I out of time - so I will get back to you on that. ~Niels -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52e988c1.8010...@thykier.net
Re: Bits from the Release Team: Architecture health check
On 2014-01-30 16:23, Robert Millan wrote: > On 30/01/2014 00:03, Niels Thykier wrote: >> @Robert: Re your "Could you elaborate?". I haven't forgotten it, but I >> out of time - so I will get back to you on that. > > It's ok. > > I wanted more detail both on the problem and on the solution. You just > provided > the second, which I believe is the most important. > Okay - as promised, the problem side. As I see it, there are two concrete problems with the (number of) supported packages. First, the number of packages actually built on kFreeBSD is just shy of 90%, whereas most other release architectures are at 96%[1]. Here kFreeBSD has increased in the past quarter from ~89.5% to "almost, but not quite 90%". Secondly, there are cases like GDM, where a single unsupported package have rather "long reaching" consequences. In the concrete example, GNOME (via gnome-core) strictly depends on gdm3, meaning that if gdm3 goes, (more or less) all of gnome goes with it[2]. That in turn means that task-gnome-desktop cannot be installed on kFreeBSD (I presume this will at least affect d-i). Here we need you to assess what can you reasonably support. Once we know that we can look at the consequences and how to deal with them. By the way, when you present your set of supported packages, please consider highlighting where you would like the "default" package set to be different from current release architectures. E.g. with the TC's decision on init systems, Linux will be using systemd as default init system[3]. I presume kFreeBSD will go with a different init system. ~Niels [1] https://buildd.debian.org/stats/graph-week-big.png The notable exception here being s390x, which is at ~93%. [2] I vaguely remember something XDM being a possible alternative to GDM, but never mind that for now. [3] Here I bluntly assume there will not be a GR overturning that decision. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fbd439.1070...@thykier.net
Re: Bits from the Release Team: Architecture health check
On 2014-02-14 00:23, Steven Chamberlain wrote: > On 12/02/14 20:06, Niels Thykier wrote: >> kFreeBSD is just shy of 90%, whereas most other release architectures >> are at 96%[1]. Here kFreeBSD has increased in the past quarter from >> ~89.5% to "almost, but not quite 90%". > > I'm a little puzzled you mention this as a problem because... > >> Here we need you to assess what can you reasonably support. Once we >> know that we can look at the consequences and how to deal with them. > > if we decide some packages can't be supported any more, I assume some > would become linux-any and thus the number of built packages would fall? > So these seem like conflicting goals. > Hi, Indeed, they are conflicting goals. But I do not see why that is so surprising. There are plenty of things in software development (and especially in release management) that involves a trade-off on conflicting goals. Ideally, I want all those graphs to show 99.999...%[1], but in the short term I cannot have that. Right now, we are trying to look at this from a pragmatic angle. If we get a better kFreeBSD by focusing and dropping some packages (possibly including a desktop or/and some specific server tasks), then so be it - as long as there is ambition, motivation and a realistic plan from your side, then I am willing to consider it. > I fully agree with the latter point though, I see value in having a plan > for what to support, and probably free some packages of an obligation to > either build, be installable or functional kfreebsd if it no longer > makes sense. > > Regards, > Those packages will probably end up being linux-any in the short term (and some of them, possibly, in the long term as well). In said short term, they will need to be cleaned up (decrufted etc), so they no longer hold up migration to testing for Jessie. For Jessie + 1, I would like for the gap to close between Linux and kFreeBSD architectures. But lets take that part later. ~Niels [1] Which is obviously a different way of writing 100% :P http://en.wikipedia.org/wiki/0.999... Okay, maybe not 100%, but then aim for 95%. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ff4f2a.5030...@thykier.net
Re: Bits from the Release Team: Architecture health check
On 2014-02-14 00:32, brunomaxi...@openmailbox.org wrote: >>> Secondly, there are cases like GDM, where a single unsupported package >>> have rather "long reaching" consequences. In the concrete example, >>> GNOME (via gnome-core) strictly depends on gdm3, meaning that if gdm3 >>> goes, (more or less) all of gnome goes with it[2]. That in turn means >>> that task-gnome-desktop cannot be installed on kFreeBSD (I presume this >>> will at least affect d-i). > > gdm3 could be replaced by lightdm in the gnome-core package or not? > > I believe Robert concluded that it was possible to use an alternative to gdm3 (I forgot if it was lightdm or xdm). Nevertheless, it would require that the GNOME maintainers are willing to adopt and support that change. If the GNOME maintainers are not willing to support lightdm/xdm as alternatives, I suspect kFreeBSD might be better served with not supporting GNOME in Jessie and revisit this problem in Jessie + 1. ~Niels -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/53007b84.5050...@thykier.net
Re: Bits from the Release Team: Architecture health check
On 2014-02-19 17:32, Robert Millan wrote:
> On 29/01/2014 23:03, Niels Thykier wrote:
>> I believe this is a first for us (as well) - at the very least, I won't
>> claim to have all the answers. Anyhow, as I see it, we want you to
>> choose a set of supported packages, then we will probably ask how / why
>> you made that choice and, quite possibly, poke a bit at making you
>> choosing a slightly larger set etc.
>
> Hi Niels,
>
> After some discussion we've reached the following position statement, which
> has the approval of Steven, Petr and myself:
>
> ~~~
> It is with much regret that we observe that GDM has grown hard dependencies
> on a Linux-specific component (systemd). Although GDM still offers the
> possibility of running it using ConsoleKit, this codepath is no longer
> supported by upstream, and ConsoleKit itself is considered deprecated
> software and has been abandoned by its developers.
>
> Furthermore, we observe that the GNOME UI has grown hard dependencies on GDM,
> as well as other developments which make it impractical to run GNOME on
> kernels other than Linux. Our understanding is that GNOME release managers
> don't
> see this as a problem and are not actively trying to resolve this.
>
> In this situation we do not think it's reasonably practical for us to continue
> providing assistance to ensure portability of the GNOME desktop on
> GNU/kFreeBSD.
>
> When it comes to individual applications, we'd like to support as many of
> them as possible. As long as they are still intended to be portable by
> their upstream developers, and that they don't have any hard dependency
> on the GNOME desktop itself (i.e., they can be run as standalone apps), we
> intend to continue providing porting assistance for them.
> ~~~
>
Hi,
Thanks for looking into this and I apologise for not following up any
sooner.
As I read/understand the above, you basically say (something along the
lines of):
"""
The Debian kFreeBSD porters will not support packages, where upstream
have no (visible) interest/intention of being portable (beyond
${OS}-any) nor their reverse dependencies. Examples of these include
(but are not limited to) systemd and GNOME (via GDM).
"""
It is not that I want to change your wording or anything. I just wanted
to make sure I had captured the important parts of it.
In any event, we will be evaluating kFreeBSD (along with other
architectures) relatively soon. Our current plans suggest early-mid
April, but I do not have a fixed date yet.
~Niels
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5320afb2.9020...@thykier.net
system hangs when building gcc on kfreebsd-amd64
Dear BSD porters, Do you have any news on this bug? It is severely affecting *all* GCC versions and prevents new versions of them from migrating to testing. ~Niels -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5357f6cc.4040...@thykier.net
Re: Bug#778366: unblock: kfreebsd-10/10.1~svn274115-2
Control: tags -1 d-i On 2015-02-14 04:22, Michael Gilbert wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: unblock > Severity: normal > x-debbugs-cc: debian-b...@lists.debian.org > > Please consider unblocking kfreebsd-10. It fixes 2 security issues: > https://security-tracker.debian.org/kfreebsd-10 > > unblock kfreebsd-10/10.1~svn274115-2 > unblock-udeb kfreebsd-10/10.1~svn274115-2 > > Ok from my PoV, CC'ing KiBi for a d-i ack. Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54e2f5f1.2080...@thykier.net
Bug#779074: kfreebsd-defaults: Please stop building on linux architectures
Source: kfreebsd-defaults Version: 10+1 Severity: serious Hi, The kfreebsd-10 package stopped building its binaries on linux architectures. However, kfreebsd-defaults still builds its binaries for linux and they depend on (now missing) linux version of the kfreebsd-10 binaries. The end result is that the linux variant of the kfreebsd-defaults binaries are uninstallable in unstable and kfreebsd-10 cannot migrate to testing, since it would make more packages uninstallable. Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150224073509.4108.29342.report...@mangetsu.thykier.net
[Stretch] Status for architecture qualification
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. 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. - armel has a RT concern about lack of buildds (only 2) * mips64el (NEW) - No DSA buildd (RT blocker) - Rebuild after import not complete (RT Blocker) - Not yet in testing (due to the above). * 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. 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. * Review the list architectures and the reported blockers/concerns * Reply to this mail with updates to these blockers/concerns (if any). - DSA/Security/RT: Please use the word "blocker" or "RC" for issues that *must* be solved for you to be willing to support the architecture. Thanks, ~Niels signature.asc Description: OpenPGP 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. > Thanks. :) > ppc64: > > [...] AFAICT, it is not in unstable and I have not heard of any attempts to bootstrap it there yet. Who is working on it and what is the ETA? > > sparc64: > > [...] > Thanks for the update. For every one working on this, please keep in mind that it can take quite a while to be set up and included in testing (even without missing hardware). If you are unable to acquire (promise of) the necessary hardware within a month or two, making it into a Stretch will probably be very hard. > sh4: > > [...] > > Thanks, > Adrian > > [...] While it sounds exciting, I doubt it will be ready for Stretch (I presume this was the "potential candidate for a future release"). Thanks, ~Niels signature.asc Description: OpenPGP digital signature
Re: [Stretch] Status for architecture qualification
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
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: 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. > 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
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
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: Porter roll call for Debian Stretch
Mathieu Malaterre: > Hi all, > > [...] > > [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 > 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). Not sure I can answer your 2nd question though. ~Niels
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? > > [...] > > 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
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: Architecture qualification meeting, scheduling
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: Enabling PIE by default for Stretch
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
Arch qualification for buster: call for DSA, Security, toolchain concerns
Hi, As part of the interim architecture qualification for buster, we request that DSA, the security team and the toolchain maintainers review and update their list of known concerns for buster release architectures. Summary of the current concerns and issues: * DSA have announced a blocking issue for armel and armhf (see below) * Concerns from DSA about ppc64el and s390x have been carried over from stretch. * Concerns from the GCC maintainers about armel, armhf, mips, mips64el and mipsel have been carried over from stretch. If the issues and concerns from you or your team are not up to date, then please follow up to this email (keeping debian-release@l.d.o and debian-ports@l.d.o in CC to ensure both parties are notified). Whilst porters remain ultimately responsible for ensuring the architectures are ready for release, we do expect that you / your team are willing to assist with clarifications of the concerns and to apply patches/changes in a timely manner to resolve the concerns. List of blocking issues by architecture === The following is a summary from the current architecture qualification table. armel/armhf: * Undesirable to keep the hardware running beyond 2020. armhf VM support uncertain. (DSA) - Source: [DSA Sprint report] [DSA Sprint report]: https://lists.debian.org/debian-project/2018/02/msg4.html List of concerns for architectures == The following is a summary from the current architecture qualification table. * Concern for ppc64el and s390x: we are dependent on sponsors for hardware. (Raised by DSA; carried over from stretch) * Concern for armel and armhf: only secondary upstream support in GCC (Raised by the GCC maintainer; carried over from stretch) * Concern for mips, mips64el, mipsel and ppc64el: no upstream support in GCC (Raised by the GCC maintainer; carried over from stretch) Architecture status === These are the architectures currently being built for buster: * Intel/AMD-based: amd64, i386 * ARM-based: arm64, armel, armhf * MIPS-based: mips, mipsel, mips64el * Other: ppc64el, s390x If the blocking issues cannot be resolved, affected architectures are at risk of removal from testing before buster is frozen. We are currently unaware of any new architectures likely to be ready in time for inclusion in buster. On behalf of the release team, Niels Thykier signature.asc Description: OpenPGP digital signature
