Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On Fri, 2018-06-29 at 11:44 +0100, Luke Kenneth Casson Leighton wrote: [...] > On Fri, Jun 29, 2018 at 10:35 AM, Adam D. Barratt > wrote: > > > > what is the reason why that package is not moving forward? > > > > I assume you're referring to the dpkg upload that's in proposed- > > updates > > waiting for the point release in two weeks time? > > i don't know: i'm an outsider who doesn't have the information in > short-term memory, which is why i cc'd the debian-riscv team as they > have current facts and knowledge foremost in their minds. which is > why i included them. It would have been wiser to do so *before* stating that nothing was happening as if it were a fact. > > I'm also getting very tired of the repeated vilification of SRM > > over > > this, and if there were any doubt can assure you that it is not > > increasing at least my inclination to spend my already limited free > > time on Debian activity. > > ah. so what you're saying is, you could really do with some extra > help? I don't think that's ever been in dispute for basically any core team in Debian. That doesn't change the fact that the atmosphere around the change in question has made me feel very uncomfortable and unenthused about SRM work. (I realise that this is somewhat of a self-feeding energy monster.) Regards, Adam
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On Fri, 2018-06-29 at 10:20 +0100, Luke Kenneth Casson Leighton wrote: [...] > debian-riscv has been repeatedly asking for a single zero-impact > line > to be included in *one* file in *one* dpkg-related package which > would > allow riscv to stop being a NMU architecture and become part of > debian/unstable (and quickly beyond), for at least six months, now. > cc'ing the debian-riscv list because they will know the details about > this. it's really quite ridiculous that a single one-line change > having absolutely no effect on any other architecture whatsover is > not > being actioned and is holding debian-riscv back because of that. > > what is the reason why that package is not moving forward? I assume you're referring to the dpkg upload that's in proposed-updates waiting for the point release in two weeks time? Please check your facts before ranting, particularly with such a wide cross-posting. Also, ttbomk, the dpkg change landing in stable is not likely to magically lead to the architecture being added to unstable - a decision which is not the release team's to make or block. Again, please ensure you've actually done your research. I'm also getting very tired of the repeated vilification of SRM over this, and if there were any doubt can assure you that it is not increasing at least my inclination to spend my already limited free time on Debian activity. Regards, Adam
Re: Porter roll call for Debian Stretch
On Fri, 2016-09-30 at 19:04 +, Niels Thykier wrote: > As for "porter qualification" > = > > We got burned during the Jessie release, where a person answered the > roll call for sparc and we kept sparc as a release architecture for > Jessie. However, we ended up with a completely broken and unbootable > sparc kernel. fwiw, you mean wheezy. Regards, Adam
Re: binNMUs: please exercise some care
On 2015-10-23 13:28, Thorsten Glaser wrote: [...] On Fri, 23 Oct 2015, Adam D. Barratt wrote: [...] It's also not quite that simple, even working things out by hand - see #599128 for example. Hm, I’m still under the impression that the +bN suffix to the Debian version of the package in the archive is the authoritative source for what binNMU version a package currently has, as that’s taking porter uploads into account which is a requirement. If the current code doesn’t do that I consider it a bug which must be fixed (at the same time, or before doing this change), which makes it more tricky, yes. Specifically, wanna-build doesn't expose the binNMU version information for suites other than unstable / experimental (actually, it might be that it doesn't for suites that have an overlay - either way, it affects {,old}stable and testing), so the only way to be certain what binNMU number to use is to check manually. In practice what actually happens is that people forget about the bug, schedule the binNMUs and then grumble when either dak rejects the packages or something gets confused. Regards, Adam
Re: binNMUs: please exercise some care
On 2015-10-23 12:02, Thorsten Glaser wrote: On Fri, 23 Oct 2015, Adam D. Barratt wrote: wanna-build does, yes, but at least the Release Team tend to use the "wb" wrapper tool which automatically works out the next free number on each architecture. Ah, cool – so we have only to patch this tool to automatically use the highest number per batch on all affected architectures (or even to use the highest number if all architectures would be touched, but that’s probably an unreasonable amount of code change). Well, except you only really want to do it for libraries that are ma:same, as that's the only case where it actually matters and otherwise you're pointlessly losing versions. It's also not quite that simple, even working things out by hand - see #599128 for example. Where’s the source code to that tool? http://anonscm.debian.org/cgit/debian-release/release-tools.git/ (in scripts/). Regards, Adam
Re: binNMUs: please exercise some care
On 2015-10-23 11:56, Thorsten Glaser wrote: On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote: I didn't say once per arch. I said once per package, which is worse. I normally schedule binNMUs for several dozens packages. Multiply that by several But you need to look the number up anyway? The wanna-build --binNMU parameter gets the number to use as argument. wanna-build does, yes, but at least the Release Team tend to use the "wb" wrapper tool which automatically works out the next free number on each architecture. Regards, Adam
amd64 qualification for Wheezy
Hi, With the sound of the ever approaching freeze ringing loudly in our ears, we're (somewhat belatedly) looking at finalising the list of release architectures for the Wheezy release. Comments on / additions and corrections to the content of http://release.debian.org/wheezy/arch_qualify.html would be appreciated, as would any other information you think is relevant to helping us determine amd64's status for the release. Regards, Adam pp the Release Team -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1sudcj-00057b...@kaa.jungle.funky-badger.org
Re: GCC-4.5 as the default for (at least some) architectures
On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote: > I'll make gcc-4.5 the default for (at least some) architectures within the > next > two weeks before more transitions start. GCC-4.5 is already used as the > default > compiler for almost any other distribution, so there shouldn't be many > surprises > on at least the common architectures. About 50% of the build failures exposed > by GCC-4.5 are fixed [1]. I didn't see issues on amd64 and i386, armel > (although optimized for a different processor) and powerpc (some object files > linked into shared libs had to be built as pic). It looks like kfreebsd-* also made the switch and there's been a request to switch for mips and mipsel. Looking through the bug list for src:gcc-4.5, none of the open issues seem to be specific to the remaining release architectures which haven't switched yet - i.e. ia64, s390 and sparc. Are you aware of any issues which would preclude switching the default on those architectures? Has there been any discussion with the port maintainers regarding switching? Regards, Adam -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1303068791.3489.499.ca...@hathi.jungle.funky-badger.org
Bug #248043: ftp.debian.org: Request for new architecture: amd64
Hi, amd64 has been in sid for quite a while now, so I think we can close this now. :-) Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]