Re: gcc-4.9 uploaded to experimental
On Fri, Jan 10, 2014 at 7:23 PM, Matthias Klose wrote: > gcc-4.9 is uploaded to experimental, asking the porters to watch for build > failures and corresponding patches. See > > https://buildd.debian.org/status/package.php?p=gcc-4.9&suite=experimental > > These are already fixed in the vcs. > > - fixed the gospec.c ftbfs on archs without ld.gold > - fixed the g++ b-d on armel/armhf The build log on mips64el can be found from: http://mips64el.debian.net/attempted/gcc-4.9-mips64el.log.xz > > Matthias > > > -- > To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/52cfd843.1010...@debian.org > -- Yunqiang Su -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKcpw6VzmezVP+6LFsb7Afs=xmhs9e295ybriksp0sn7aa0...@mail.gmail.com
Re: Roll call for porters of architectures in sid and testing
在 2014年1月21日，下午9:51，Aníbal Monsalve Salazar 写道： > On Tue, Jan 21, 2014 at 01:43:55PM +0100, Matthias Klose wrote: >> Am 16.01.2014 13:31, schrieb Aníbal Monsalve Salazar: >>> For mips/mipsel, I - fix toolchain issues together with other >>> developers at ImgTec >> >> It is nice to see such a commitment, however in the past I didn't see >> any such contributions. > > Hello doko, > > At my current job, we are working on fixing mips* bugs including > possible compiler errors. As an example, I recently run tests to try to > find tool chain errors for packages that on non-Debian distro were > failing to build. So, at least so far, I'm working on that. > > Regards, > > Aníbal Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the jessie release: For mipsel/mips64el and maybe mips/mips64, I - test most packages on this architecture - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - maintaining rebuild test I am a DM Yunqiang Su signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Porting OpenJDK 8
Great, let me try it on mips64el. I met some trouble for openjdk-6 and openjdk-7. Wish openjdk-8 works :-) On Fri, Apr 18, 2014 at 8:02 PM, Emmanuel Bourg wrote: > Hi, > > OpenJDK 8 is being packaged [1] and I'm looking for porters willing to > try and compile it on other architectures. So far it builds fine on > amd64 and some work has started for kFreeBSD. No other architecture has > been tested yet, so any help is welcome. > > Thank you, > > Emmanuel Bourg > > [1] http://anonscm.debian.org/gitweb/?p=pkg-java/openjdk-8.git > > > -- > 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/53511469.2090...@apache.org > -- Yunqiang Su -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cakcpw6u_kz_emc7bfuhvgczbbf2bzufatpjfd0r9wdtzoxf...@mail.gmail.com
Re: preparing for GCC 4.9
On Thu, May 8, 2014 at 11:25 PM, Matthias Klose wrote: > With gcc-4.9 now available in testing, it is time to prepare for the change of > the default to 4.9, for a subset of architectures or for all (release) > architectures. The defaults for the gdc, gccgo, gcj and gnat frontends > already > point to 4.9 and are used on all architectures. Issue #746805 tracks the > gfortran default change, including the change of the Fortran 90 module version > change. > > The Debian archive was rebuilt twice on amd64, once in February, resulting in > bug submissions for GCC and feedback for the porting guide [1], a second time > in > March to file issues for packages failing to build with GCC 4.9 [2]. Another > test rebuild for Ubuntu on amd64, i386, armhf, ppc64el didn't show any other > compiler regressions on these architectures. > > 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 > rebuild > for some architectures by the porters? Afaics the results for the GCC > testsuite > look okish for every architecture. I set a build farm with gcc-4.9 for mips64el. It works well: it has no more failures than your amd64 one. All the buildlogs can be found in http://mips.wicp.net:9998/mips2/buildlog/ I noticed ctpp2 failed due to symbols problems on both amd64(pbuilder) and mips64el(sbuild). It seems that you didn't report bug on it. > > I'll work on fixing the build failures in [2], help is of course appreciated. > Almost all build failures are analyzed and should be easy to fix (exceptions > e.g. #746883). Patches for the ones not caused by the Debian packaging may be > found in distributions already using GCC 4.9 as the default compiler (e.g. > Fedora 21). > > If anything goes well, and a large amount of build failures are fixed, I plan > to > make GCC 4.9 the default for the C/C++/ObjC/Obj-C++ frontends at the end of > May, > beginning of June. > > Bugs reports for packages building with a legacy version of GCC (4.6, 4.7, > 4.8) > will be filed. > > Matthias > > [1] http://gcc.gnu.org/gcc-4.9/porting_to.html > [2] > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.9;users=debian-...@lists.debian.org > > > -- > 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/536ba1ce.9070...@debian.org > -- Yunqiang Su -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKcpw6Ve=nbetyywgw+qm99bohki2q+1dvxw6fzazfna9wc...@mail.gmail.com
Re: preparing for GCC 4.9
I tested to build kernel for Loongson 3 with gcc-4.9. it works fine. On Fri, May 30, 2014 at 6:00 PM, Adam Conrad wrote: > On Thu, May 08, 2014 at 05:25:02PM +0200, 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 >> rebuild >> for some architectures by the porters? Afaics the results for the GCC >> testsuite >> look okish for every architecture. > > I'm confident that other than one or two potential outliers, test build > results on powerpc and ppc64 should have the same number of regressions > as ppc64el, and also quite confident that where that's not the case, we > can get it fixed in a hurry, so please do those arches in lockstep with > the rest. > > ... Adam > > PS: Switching hats to arm64, that one should also rev with the rest, > but I think that's probably a no-brainer anyway, given that it's > a new ports, where staying on the cutting edge is usually sanee. > > > -- > To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/20140530100040.gw28...@0c3.net > -- Yunqiang Su -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKcpw6WZjC=2ivjhkflif1dix+p7pqgd-qrpj8y6zqcjzxm...@mail.gmail.com
Debian/MIPSeb: proposal to drop mipseb port?
Hi, folks, due to lack of enough man power and build machines for 3 mips* port at the same time, I think that now it is time for us to have a talk about dropping mips32eb support now. mips32eb, named mips, in our namespace, is used by few people now, at least compare with mipsel/mips64el. The reason we keep it till now is 1) some people are still using it. 2) it is the only port 32bit and EB now. In fact I don't know anybody is using Debian's mips32eb port. If you are using it, please tell us.
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
Niels Thykier 于2018年6月28日周四 上午4:06写道： > > 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) > This is a misunderstanding as MIPS company had some unrest in recent half year. Currently we are stable now, and the shape of gcc upstream is also good. > > 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 We are plan to drop mips(eb) and keep 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 > -- YunQiang Su
Re: Porter roll call for Debian Bookworm
For mipsel and mips64el, I - test most packages on this architecture - run a Debian testing or unstable system on port that I use regularly - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - triage d-i bugs - test d-i regularly - fix d-i bugs/issues - maintain buildds - maintain/provide hardware for (or assist with) automated tests on ci.d.n, jenkins.d.n (etc.) I am a DD. -- YunQiang Su
Re: Porter roll call for Debian Bookworm
Graham Inggs 于2021年12月26日周日 21:58写道： > > Hi YunQiang Su > > On Sun, 26 Dec 2021 at 11:17, YunQiang Su wrote: > > > > For mipsel and mips64el, I > > - test most packages on this architecture > > - run a Debian testing or unstable system on port that I use regularly > > - fix toolchain issues > > - triage arch-specific bugs > > - fix arch-related bugs > > - triage d-i bugs > > - test d-i regularly > > - fix d-i bugs/issues > > - maintain buildds > > - maintain/provide hardware for (or assist with) automated tests on > > ci.d.n, > > jenkins.d.n (etc.) > > > > I am a DD. > > Thanks for your response! > > In case #1000435 (matplotlib crashes on mips64el) is not already on > your radar, would you please take a look? > Thank you. I will work on it right now. > Regards > Graham -- YunQiang Su
Re: Porter roll call for Debian Bookworm
Sandro Tosi 于2022年1月14日周五 13:54写道： > > YunQiang, > > On Tue, Jan 4, 2022 at 9:48 AM PICCA Frederic-emmanuel > wrote: > > > > > > > > In case #1000435 (matplotlib crashes on mips64el) is not already on > > > > your radar, would you please take a look? > > > > > > > > > > Thank you. I will work on it right now. > > > > Hello, I just added some information about this problem on this bug > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001168#72 > > > > it seems to me that this is something related to gcc-11. If I build > > matplotlib with gcc-10 there is no more crash. > > did you have a chance to look at it yet? there's quite a substantial > number of packages depending on matplotlib that cant migrate to OK. I will have a look at this now. > testing until this issue is fixed, so we'd greatly appreciate it if > you can investigate it soon. > > Thanks, > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi -- YunQiang Su
