Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Adam D. Barratt]

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

[Adam D. Barratt]

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

[Adam D. Barratt]

On Sun, 2016-10-09 at 21:12 +0300, Adrian Bunk wrote:
> [ adding debian-powerpc ]
> 
> On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> > Niels Thykier  schrieb:
> > > 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.
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 is about
> > a powerpc-specific build failure of mariadb in stable. The maintainer
> > said he can't work on it, so if anyone considers himself/herself a
> > powerpc porter, this is something to look it.
> 
> Can you give a hint what exactly should be looked at?

https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.0=powerpc=10.0.27-0%2Bdeb8u1=1473621159

> The bug did not make it clear that there is any problem left at all when 
> I looked at it recently.
> 
> The last message was closing the bug.
> 
> There was a control command reopening the bug without giving any 
> rationale, but the last control command was
>   fixed 832931 10.0.27-1

For unstable, yes. The stable package is still broken.

> buildd.debian.org says that 10.0.27-0+deb8u1 was installed on jessie.[1]

That's an artefact of how builds for suites with "overlays" (i.e. pu /
tpu) are displayed. If one actually looks at the archive:

mariadb-client-10.0 | 10.0.25-0+deb8u1 | stable | powerpc
mariadb-client-10.0 | 10.0.27-0+deb8u1 | stable | amd64, arm64, armel, 
armhf, i386, mips, mipsel, ppc64el, s390x

Regards,

Adam

Re: Porter roll call for Debian Stretch

[Adam D. Barratt]

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

[Adam D. Barratt]

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: binNMUs: please exercise some care

[Adam D. Barratt]

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

[Adam D. Barratt]

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: powerpc qualification for Wheezy

[Adam D. Barratt]

On Wed, 2012-05-16 at 13:19 +0100, Adam D. Barratt wrote:
 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 powerpc's status for the release.

*gentle prod*

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1337797937.16492.11.ca...@jacala.jungle.funky-badger.org

powerpc qualification for Wheezy

[Adam D. Barratt]

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 powerpc's status for the release.

Regards,

Adam
pp the Release Team


-- 
To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1sudcl-00058d...@kaa.jungle.funky-badger.org

Re: GCC-4.5 as the default for (at least some) architectures

[Adam D. Barratt]

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