Re: Re-evaluating architecture inclusion in unstable/experimental
On Fri, 2018-09-28 at 14:16 +0200, John Paul Adrian Glaubitz wrote: > So, it's not always a purely technical decision whether a port > remains a release architecture. It's also often highly political and > somehow also influenced by commercial entities. Please don't make implications like that unless you can back them up. Adam (involved to greater or lesser extent in every decision as to whether an architecture should be added to or removed from testing over the past almost decade, with no commercial interest involved in any way)
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
Re: please remove kfreebsd-any from Architecture
On Sat, 2014-05-31 at 00:42 +0200, Emilio Pozuelo Monfort wrote: > On 30/05/14 17:57, Steven Chamberlain wrote: > > On 16:01, Emilio Pozuelo Monfort wrote: > >> Just a reminder: there are still various things depending on the removed > >> packages, preventing things from migrating to testing. > > > > Do you agree it's just the two metapackages from src:meta-gnome3 that > > need changes, or is there anything else? > > > > http://lists.debian.org/53863f46.2050...@pyro.eu.org > > There's that and also #749888. I don't know if there are other things, I > haven't > looked in detail. There's also gnome-session. gnome-core depends on gnome-session, which in turn depends on gnome-shell. Regards, Adam -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1401716207.4230.16.ca...@jacala.jungle.funky-badger.org
Re: [Fwd: Re: hurd-i386 qualification for Wheezy]
On Thu, 2012-05-24 at 19:35 +0200, Svante Signell wrote: > Looks like group reply in my mailer means reply only to the mailing list > I have defined a filter for? Anyway, forwarding to debian-release too. *checks headers* You wanted "reply all", predictably enough. Which means this is now annoyingly unthreaded. You also didn't copy -hurd on your forward... > On Thu, 2012-05-24 at 18:08 +0100, Adam D. Barratt wrote: > > > I'm not sure we've ever released with an architecture which was in > > > either broken or fucked, but hopefully someone will correct me if I'm > > > mistaken on that. > > > > Anyone? :-) > > > > Opinions as to whether it makes sense to release an architecture in > > either of those states would also be welcome. > > Is there a definition of what broken and fucked means, so this could be > related to. Well, the question was primarily aimed at members of the Release Team, who know what the terms mean. In short, an architecture is "broken" if a source package may migrate even though doing so causes new uninstallability on that architecture. A fucked architecture is one on which source packages may migrate even if the packages have not yet been built on the architecture. > Also, is "tech preview" defined somewhere. Were there any > descriptions made/discussions when kFreeBSD was introduced for Squeeze? Phil already addressed this. Regards, Adam -- 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/1337883952.25124.6.ca...@jacala.jungle.funky-badger.org
Re: hurd-i386 qualification for Wheezy
On 19.05.2012 19:04, Adam D. Barratt wrote: Very quickly following up on a possible nomenclature issue and a couple of other things. On Sat, 2012-05-19 at 17:29 +0200, Samuel Thibault wrote: - We of course aim at tech preview for wheezy only, not a full release. Our goal is to establish a testing distribution for wheezy which does not block others ports (i.e. so-called fuckedarch), and get a full testing for wheezy+1. That's not what the phrase "tech preview" was used to mean for kfreebsd-* at least. [...] I'm not sure we've ever released with an architecture which was in either broken or fucked, but hopefully someone will correct me if I'm mistaken on that. Anyone? :-) Opinions as to whether it makes sense to release an architecture in either of those states would also be welcome. Regards, Adam -- 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/e5cd4db270a3b1679caf32483191a...@mail.adsl.funky-badger.org
Re: hurd-i386 qualification for Wheezy
Hi,
Very quickly following up on a possible nomenclature issue and a couple
of other things.
On Sat, 2012-05-19 at 17:29 +0200, Samuel Thibault wrote:
> - We of course aim at tech preview for wheezy only, not a full
> release. Our goal is to establish a testing distribution for wheezy
> which does not block others ports (i.e. so-called fuckedarch), and get
> a full testing for wheezy+1.
That's not what the phrase "tech preview" was used to mean for
kfreebsd-* at least.
They were added to testing via {fucked,broken}arches some time in
mid-2009 (it's mentioned in a dda posting in July, the britney config
change didn't hit get until August), declared to be release
architectures in October and were also removed from "fuckedarches" soon
after - i.e. kfreebsd-* specific issues became RC and out-of-dateness on
those architectures was a blocker for migration. At some point before
February 2010 (when I committed the change which had been lurking
uncommitted on the live code branch) they were removed from brokenarches
too and installability issues became RC.
I'm not sure we've ever released with an architecture which was in
either broken or fucked, but hopefully someone will correct me if I'm
mistaken on that.
> Some questions/open issues for the release team:
[...]
> - How are discussions about the concerns-* fields coordinated? Is the
> release team going to inquire those, or should we?
Either works, although I suspect we can manage to ask ourselves about
the {S,}RM ones... ;-) Feel free to ask DSA and the security team,
preferably somewhere public that could be pointed to for the record.
> - About buildd-dsa, we are fine with a DSA'd buildd, if DSA is happy
> to maintain it, they will however probably have to learn a few Hurd
> things? We don't know to what extend DSA have to tinker with the
> machine, but we would be happy to help.
I think the prevailing view recently has been that having DSAed buildds
and porter boxes is generally preferable; this might be something to
cover under the above discussion with DSA.
Regards,
Adam
--
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/1337450680.29502.34.ca...@jacala.jungle.funky-badger.org
hurd-i386 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 hurd-i386's status for the release. Regards, Adam pp the Release Team -- 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/e1sudck-00057x...@kaa.jungle.funky-badger.org
"Pre-testing" hurd issues
Hi,
A few weeks ago I performed a few test britney runs, in order to try and
answer the question "how much pain would trying to squeeze hurd in to
testing be right now?". I've just realised that I never really publicly
shared any of the result, hence this mail; looking through what I noted
at the time I've forgotten some of the detail and some of it's no longer
relevant, but hopefully what remains is of some use.
The end result of my test runs was an initial set of ~3800 hurd binaries
in testing, of which around 150 were uninstallable. Looking through the
problems I noted at the time, several are still relevant:
- coreutils FTBFS on hurd with test failures
- python2.7 FTBFS on hurd. The build log appears to truncate part way
through the testsuite
- britney won't consider migrating util-linux/hurd because of the
out-of-date {c,}fdisk-udeb binaries in unstable. I'm guessing these
should actually still be being built; it looks like they were
accidentally dropped as part of fixing #635530.
- #650080 means that the "hurd" source package itself had to be forced
in
Regards,
Adam
--
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/1335987287.24513.12.ca...@jacala.jungle.funky-badger.org
Bug#627103: Cant install dropbear on Debian/Hurd because of incomplete dependencies
On Fri, 19 Aug 2011 12:30:07 +0200, Samuel Thibault wrote: reassign 627103 hurd fixed 627103 20110519-2 thanks It seems I had missed that bug report. This should be already fixed since June actually. Are you sure? hurd 20110519-3 still depends on "random-egd", and that package still doesn't exist in the archive. Regards, Adam -- 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/4aec5d758ed69bb82ba8101cdb795...@adsl.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-hurd-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
