Re: Re: Making Debian ports less burdensome

[Ralf Treinen]

On Sun, Feb 28, 2016 at 02:41:42PM +, peter green wrote:

> 5: in the dose case seperating out arch specific packages (which are not
> allowed to be uninstallable) from arch all packages (which are allowed to be
> uninstallable), it is indicated in the list with an [all] tag but spotting
> the handful of uninstallable arch specific packages in the much larger list
> of uninstallable arch all packages for testing isn't easy (for unstable the
> information is even less useful because of the massive ammount of entries
> that have nothing to do with ports).

what improvement do you suggest? having two separate sections with
arch-specicific/arch-all packages on a listing page?

The total numbers are already separated on summary pages.

-Ralf.

Re: Re: Making Debian ports less burdensome

[peter green]

I would have thought porters would be following the buildd/piuparts/CI
pages for their port (where available) and thus would not need to be
notified about arch-specific FTBFS or testing issues. If porters are
relying on package maintainers or some automation to notify them
instead of being pro-active about builds and testing, that isn't going
to produce a high-quality port.

There is a tool for checking uninstallable and out of date packages already:

The problem with the current tools is they don't do a good job of:

1: seperating out port specific issues verses general issues.
2: seperating out issues with packages that actually matter* verses low 
popcon leaf packages that could be removed with minimal impact.
3: seperating out very new issues verses older issues without bug 
reports verses issues that are already being actively discussed verses 
stale issues with bug reports but no patches verses stale issues with 
bug reports and patches.
4: linking the automatic detection of an issue to the bug report on the 
issue (afaik the dose pages have no mechanism for this, the buildd pages 
have "failing reasons" but they are little used because only buildd 
admins can set them). Also linking together reports of essentially the 
same issue from multiple sources (i.e. package is uninstallable 
*because* it failed to rebuild for a transition).
5: in the dose case seperating out arch specific packages (which are not 
allowed to be uninstallable) from arch all packages (which are allowed 
to be uninstallable), it is indicated in the list with an [all] tag but 
spotting the handful of uninstallable arch specific packages in the much 
larger list of uninstallable arch all packages for testing isn't easy 
(for unstable the information is even less useful because of the massive 
ammount of entries that have nothing to do with ports).
6: indicating issues that are both blocking transitions (so need to be 
dealt with urgently) and are specific to a handful of architectures.


Improving the existing tools might help with some of the issues but I 
can see advantages in a porter-focussed tool that collects information 
from multiple sources.


* Exactly where to draw the line on "actually matter" is potentially a 
subject of some debate.

Re: Making Debian ports less burdensome

[Christian Seiler]

On 02/27/2016 05:18 PM, Steven Chamberlain wrote:
>> I have a question here: package A build-depends on libB. A has
>> Arch: any or Arch: linux-any in debian/control. libB OTOH only
>> has e.g. Arch: amd64 i386 mips in it's control file.
> 
> Concrete example:
> https://bugs.debian.org/811554

While this is a slightly different example to what I was talking about,
I would strongly advise not to keep two copies of the architecture list
around (one in debian/control, the other in debian/rules): you can
easily modify one list and forget to modify the other. This has
happened before in other contexts unrelated to my question, see e.g.
.

>> Disadvantage: listed as BD-Uninstallable on multiple
>> architectures where libB isn't built
> 
> I think that is not a problem, unless the package has built before in
> sid and is now out-of-date.

Ok, thanks.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: Making Debian ports less burdensome

[Steven Chamberlain]

Christian Seiler wrote:
> I have a question here: package A build-depends on libB. A has
> Arch: any or Arch: linux-any in debian/control. libB OTOH only
> has e.g. Arch: amd64 i386 mips in it's control file.

Concrete example:
https://bugs.debian.org/811554

There I suggested blacklisting known-bad arches rather whitelisting the
ones that are known to work.

> Disadvantage: listed as BD-Uninstallable on multiple
> architectures where libB isn't built

I think that is not a problem, unless the package has built before in
sid and is now out-of-date.

> explicitly list the architectures of libB also in A
> [...]
> Disadvantage: requires source upload to build on new arch
> once libB is ported

With 20+ arches, I don't expect package libB's maintainer could keep up
with new arches appearing that it could build and work on.  If
dependencies also kept such a list, I just don't think it would scale.

A down-side to an overly liberal Architectures list is, building a
package that doesn't work:  but if you don't build it, who will ever
test it (especially if many build-deps took the same attitude)?
Having tests run during package build or CI tests could help here.

Or, packages build accidentally, then a later version FTBFS.  That's why
I thought of auto-removals, but if porters more actively removed those I
think it would be helpful.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Making Debian ports less burdensome

[Paul Wise]

On Sat, Feb 27, 2016 at 9:41 PM, Steven Chamberlain wrote:

> buildd.d.o is an essential data source
...
> some ideas could be implemented into buildd.d.o itself someday.

Why someday and not today?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Making Debian ports less burdensome

[Christian Seiler]

On 02/27/2016 02:41 PM, Steven Chamberlain wrote:
>   * B-D Uninstallable can be a huge list, where dozens of those only
> wait for just one package - it makes sense to group/collapse them;
> (this happens in the dose pages also)

I have a question here: package A build-depends on libB. A has
Arch: any or Arch: linux-any in debian/control. libB OTOH only
has e.g. Arch: amd64 i386 mips in it's control file.

If A is in principle portable (i.e. other than the fact that
libB isn't ported to those archs yet, there's nothing intrinsic
in A that shouldn't work on any architecture), what is the
correct way of handling this?

 - keep everything as is:

   Disadvantage: listed as BD-Uninstallable on multiple
   architectures where libB isn't built

   Advantage: once libB is ported to a new architecture, the
   buildds will take care of everything (at worst a gb or binnmu
   is needed)

 - explicitly list the architectures of libB also in A

   Disadvantage: maintenance burden for maintainer (maintainer
   of A needs to explicitly track changes in libB to support
   ports)

   Disadvantage: requires source upload to build on new arch
   once libB is ported

   Advantage: no BD-Uninstallable status in buildds

From the perspective of a porter: which one would you prefer and
why?

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: Making Debian ports less burdensome

[Steven Chamberlain]

Paul Wise wrote:
> I would have thought porters would be following the buildd/piuparts/CI
> pages for their port (where available) and thus would not need to be
> notified about arch-specific FTBFS or testing issues.

buildd.d.o is an essential data source, but the way it is displayed
there is not ideal for porters:

  * Build-Attempted includes things that FTBFS on all, or many arches,
like all 32-bit, and is not really specific to the porter's arch;

  * it lists FTBFS that the porter has already handled (bug filed,
patches provided), the list can become cluttered with those and it
is hard to see what remains unhandled;

  * B-D Uninstallable can be a huge list, where dozens of those only
wait for just one package - it makes sense to group/collapse them;
(this happens in the dose pages also)

  * critical toolchain packages don't appear any more promimently than
a sid-only, RC-buggy leaf package with an RM bug filed for it.

THat's why I'm trying to design a better dashboard for porters, though
some ideas could be implemented into buildd.d.o itself someday.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Making Debian ports less burdensome

[Simon Richter]

Hi,

On 27.02.2016 05:43, Paul Wise wrote:

> I would have thought porters would be following the buildd/piuparts/CI
> pages for their port (where available) and thus would not need to be
> notified about arch-specific FTBFS or testing issues.

For the most part, maintainers are in a much better position initially.

A package failing on m68k can mean

 - it is broken on slow machines (runs into a timeout)
 - it requires lots of memory to build
 - it is broken on big-endian machines
 - it is broken on m68k specifically, because
   - the m68k toolchain has an issue
   - the package is lacking explicit support (assembler section?)
   - a bug in the package is exposed on m68k only
 - it is broken everywhere, so m68k breaks as well

I think it makes sense for a maintainer to make the initial call on
whether that is a problem to be handled by the porters, or an upstream
issue. If it's failing on one architecture only because the program
makes some unportable assumption, I believe that to be a bug in the package.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Making Debian ports less burdensome

[Paul Wise]

On Sat, Feb 27, 2016 at 8:04 AM, Steven Chamberlain wrote:

> As far as the dashboard goes, I've started out with:
> https://kfreebsd.eu/dashboards/ports/

Seems like that should be moved here:

https://buildd.debian.org/status/

> I want to add pages per-arch that list the packages that FTBFS,

Already exists:

https://buildd.debian.org/status/architecture.php?a=kfreebsd-amd64=sid

> one-per-line, showing if a bug is filed already or not.  (And if not,
> being able to draft a FTBFS bug with a few clicks.  This leads towards
> eventually filing those bugs automatically.)

These need to be added though.

> I want to the emphasize bugs in 'core' packages and show and count those
> separately.  Not sure yet where to get that list from, though it should
> be different per architecture.

You'll need to define 'core' first. Are you talking about the packages
needed to rebootstrap the port, priority standard, 'key' packages as
defined by the release team's autoremoval prevention stuff or
something else?

> Graphing the numbers on that page over time would be nice.
> mips and armel currently seem worst of the current release arches.
> mips64el looks pretty good despite not being a release arch yet.
> And hurd is ahead of kfreebsd.

Something to add here:

https://buildd.debian.org/stats/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Making Debian ports less burdensome

[Paul Wise]

Some thoughts after reading the thread:

I would have thought porters would be following the buildd/piuparts/CI
pages for their port (where available) and thus would not need to be
notified about arch-specific FTBFS or testing issues. If porters are
relying on package maintainers or some automation to notify them
instead of being pro-active about builds and testing, that isn't going
to produce a high-quality port.

There is a tool for checking uninstallable and out of date packages already:

https://qa.debian.org/dose/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Making Debian ports less burdensome

[Steven Chamberlain]

Steven Chamberlain wrote:
> I envisage some kind of a scoreboard, graphs, or those weather symbols
> we all love to see.

As far as the dashboard goes, I've started out with:
https://kfreebsd.eu/dashboards/ports/

I want to add pages per-arch that list the packages that FTBFS,
one-per-line, showing if a bug is filed already or not.  (And if not,
being able to draft a FTBFS bug with a few clicks.  This leads towards
eventually filing those bugs automatically.)

I want to the emphasize bugs in 'core' packages and show and count those
separately.  Not sure yet where to get that list from, though it should
be different per architecture.

The 'Total FTBFS' are (some of the) RC bugs that would be introduced, if
that arch was accepted for the next stable release.  I think it's a
metric to consider during arch qualification.

Graphing the numbers on that page over time would be nice.
mips and armel currently seem worst of the current release arches.
mips64el looks pretty good despite not being a release arch yet.
And hurd is ahead of kfreebsd.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Making Debian ports less burdensome

[Steven Chamberlain]

Ian Jackson wrote:
> Sorry to be discouraging, but I don't think this is the right
> approach.

That's ok, I'm happy to be talked out of the auto-removals part.

> [...] I definitely don't want to see us routinely dropping packages
> from an arch, without anyone having taken a decision about whether
> this is the right thing to do.

Removal can mean two different things BTW:
  * ftpmaster removes it from sid (though it will re-appear if the FTBFS
gets fixed)
  * maintainer deliberately removes it from the Architecture: list

But I've seen both of these things happening *already* (to kfreebsd),
which is what led me to think about this.  I would actually prefer to
avoid it.

I'm sometimes unaware of this until it's too late - because no FTBFS bug
was filed, or porters were not copied on it, or on the RM bug.  I used
to file these FTBFS bugs myself but it can be tedious and I got bored of
doing it.  Maybe at least *that* work can be semi-automated?

> Toolchain problems with sufficintly wide impact ought to be dealt with
> by deprecating architectures, not by dropping packages piecemeal.

That would be fair enough, if porters are made very aware of the
problems and their implications.  I'd like the release team to have a
detailed list of those issues to base their arch qualification on.

I envisage some kind of a scoreboard, graphs, or those weather symbols
we all love to see.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Making Debian ports less burdensome

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On Fri, Feb 26, 2016 at 09:02:48PM +, Steven Chamberlain wrote:
> > Removing the package from the breaking port is an option, and it
> > should be easy to trigger, but it should not be automatic.  If we make
> > the process easy and the maintainer doesn't do it (and also doesn't
> > fix the bug), I think it is reasonable to auto-remove the package from
> > testing altogether (as we currently do).
> 
> I think the testing autoremoval thing started out the same way, it
> merely reported long-standing RC bugs, but removal was manual in the
> beginning.

Oh don't get me wrong, I'm all for doing things automatically.  The question is
what is done.  I agree with Ian on this: dropping an arch for a package should
not be automatic.  But I think it should be easy for the maintainer or porter
to trigger (so the release team doesn't have to spend time on it).

In short, when a build fails on an arch that used to work:
- - Auto-file an FTBFS bug to maintainer and porters.
- - With no response, auto-remove from testing.
- - With response, if requested, remove from arch.

That way the release team only needs to step in for core packages (which should
not be auto-removed, of course).

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW0Md9AAoJEJzRfVgHwHE6Vm0P/iaCViA36l3VQbOz9MwhfgxA
xxXgbKe4R91TK1vxAgdLXa3Nv68Q8pRSizDb8B3Jxm/fmZDF07FiCsZ0M3h1RxrF
Lsnh7rc/lHnRLauk+0TBQr8kPSFWAYu/eINPcZK9NWaLHHhBtTNMg6lxF41sbVkf
YBrDjcTAAH9fuxH73xg60+9hyQXSGq4eSxaqB6o8UoWz2DJXA1vhsvtyiWSPlLwc
wRTN0Ebmd+U1ptIBkbkGyKqGOR0IIwMmyzoPPSimnROvr2lZKA4UySuE4lW2MEzb
qjv8uQmfpGqNYZoMRi40fmva8A6h/lRt4GkxHodpsZE2BZnR6DNewYbRQuBPptxj
qbEtZKsQbSEm79KrLvpYV8IeYQcPltv8JHUpmutTiQjDpWP9USA2nZqIs0iL401J
tnZHPAJBvjnzZMJBabAAehkYXE8UdoRlvFbdH9lGLKdd+wv5gHLTyeJ7pxrSxD0J
iQ/7o/48jRiX8li0R93StIa1Vkrx8SiYL1lsepWRV+uifkuH4zynOKOGqU8guxua
H8J00GtI9utdnr0NCTXEl2C1lXNy+oqBcGYOVyDUHfJd3YnXooNT+PEl+nJ/CXLA
FC/VuYem1rczUGh4sHc4y5BIyZTEz8MYEKI6TJ5sorke2O6jwCbA0lwDFWLl7c7V
BH5SgRy97BdkkcEeQT1c
=xzj+
-END PGP SIGNATURE-

Re: Making Debian ports less burdensome

[Ian Jackson]

Steven Chamberlain writes ("Re: Making Debian ports less burdensome"):
> I think the testing autoremoval thing started out the same way, it
> merely reported long-standing RC bugs, but removal was manual in the
> beginning.
> 
> Okay, perhaps I should start working on:
> 
>   * A report of out-of-date packages in sid, for each arch;  ideally
> try to correlate those with FTBFS bugs, and highlight where there
> isn't one already filed.  If it could generate a template bug report
> ready to send (with appropriate usertags or X-Debbugs-Cc: headers),
> that would be even better.
> 
>   * A report of FTBFS bugs that have not had activity in some time.
> (Perhaps filter out FTBFS that affect many arches like amd64/i386).
> 
> Where a bug has a patch that just hasn't been applied by the maintainer,
> a porter NMU might be justified.  It would be nice to have a list of
> those to show to a DD who may be able to help.
> 
> If the bug has no patch, maybe it could produce an ftpmaster RM bug
> template ready for someone to send;  showing the reverse-depends too.

Sorry to be discouraging, but I don't think this is the right
approach.

Of course there are tradeoffs between the costs of this kind of bug to
less-popular architectures, or to less-popular packages, but I don't
think this is the right way to make that tradeoff.

If an individual package that someone cares about wants to drop an
arch for a difficult-to-fix bug, then that's one thing.  I definitely
don't want to see us routinely dropping packages from an arch, without
anyone having taken a decision about whether this is the right thing
to do.

Toolchain problems with sufficintly wide impact ought to be dealt with
by deprecating architectures, not by dropping packages piecemeal.
Conversely most portability bugs are pretty easy to fix if you have a
repro.

Thanks,
Ian.

Re: Making Debian ports less burdensome

[Steven Chamberlain]

Hi,

Bas Wijnen:
> Removing the package from the breaking port is an option, and it
> should be easy to trigger, but it should not be automatic.  If we make
> the process easy and the maintainer doesn't do it (and also doesn't
> fix the bug), I think it is reasonable to auto-remove the package from
> testing altogether (as we currently do).

I think the testing autoremoval thing started out the same way, it
merely reported long-standing RC bugs, but removal was manual in the
beginning.

Okay, perhaps I should start working on:

  * A report of out-of-date packages in sid, for each arch;  ideally
try to correlate those with FTBFS bugs, and highlight where there
isn't one already filed.  If it could generate a template bug report
ready to send (with appropriate usertags or X-Debbugs-Cc: headers),
that would be even better.

  * A report of FTBFS bugs that have not had activity in some time.
(Perhaps filter out FTBFS that affect many arches like amd64/i386).

Where a bug has a patch that just hasn't been applied by the maintainer,
a porter NMU might be justified.  It would be nice to have a list of
those to show to a DD who may be able to help.

If the bug has no patch, maybe it could produce an ftpmaster RM bug
template ready for someone to send;  showing the reverse-depends too.

If it is a core package, removal isn't viable, so porters need alerting
to those.  Those bugs, and the number of FTBFS bugs generally, may be a
better metric of arch release qualification than some of the criteria
that have been used in the past.

Though to be an accurate metric, we need to enumerate all the FTBFS,
not just rely on someone having filed a bug already.

(I'm specifically referring to FTBFS on arches where the package built
in the past, and is "out-of-date" in sid.  Otherwise it's not a
release-critical issue, not blocking testing migration).

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

Re: Making Debian ports less burdensome

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I like your suggestions in general, but am a bit worried about the results of
this:

On Thu, Feb 25, 2016 at 05:41:57PM +, Steven Chamberlain wrote:
>   * If left unfixed, the bugs should trigger an auto-removal from
> unstable so that the package can migrate on the other arches.  It
> also means the FTBFS bugs can be downgraded to non-RC, and helps
> packages to get back into a releaseable state.  And it cleans up
> the archive, allowing old source packages to go away after
> transitions complete.

That would lead to ports with many missing packages too easily, I think.
Removing the package from the breaking port is an option, and it should be easy
to trigger, but it should not be automatic.  If we make the process easy and
the maintainer doesn't do it (and also doesn't fix the bug), I think it is
reasonable to auto-remove the package from testing altogether (as we currently
do).

Making it easy to remove a package from one arch can be done in several ways.
Depending on the problem, this information ("don't build this package") may
belong on the buildd or in the package.  If it belongs on the buildd, there
should be a blacklist there.  Maintainers should be able to edit those
blacklists, for example through control@b.d.o.  If it belongs in the package,
we could make it easier to specify Architecture: any-except-a+b+c.  The current
system AFAIK is to list all the architectures that do work, which means that
such a package needs to be modified when a new release arch is added.  That's
not good.  Perhaps a new header can be added, such as "Except-Architecture:
arm, armhf".

While we're at it, perhaps we can define some architecture groups for use in
that header, such as "32-bit", or "big-endian"?  Then the exception can target
architectures based on what breaks instead of just listing them.  Those groups
should also be usable in the Architecture: field.

Anyway, perhaps I'm going too far now.  My point in this discussion is that I
would like to make it easy for maintainers to make their package not build on
an architecture.  If they use that, the package should be auto-removed from
testing on that architecture, so the old version does not prevent migration of
the new version.  If they don't use it, the package should be removed from
testing entirely, just as it is now.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW0IvZAAoJEJzRfVgHwHE61qYP/Re+Dw5LGqd39VCCq/YGiJo7
q83CiJCsNauJWw9V7Y+tizw4h43SZ/CHrZp1Jhi2nU7W4b5dSZEYADpusEQEKfWV
5dqI4Us3fh595NWoRwR8s9UG8HnyvFl6Zt+5CScJLvtUCJXnY6IqNFoQXPz7AO+R
x7ht9SY8otkZ7NQBbvZpbtGnrX4TAwkpenAdYFLKpSxC6goQEbnlfeLxO2R8hDgD
E5g0M6SqGn/ClJ4Lnn10/r/9og3wBRBS+cIK/UsrhDtXrzbncq3ulXPZoznJxy4B
6W4OHjYr4im4QuhGPU2qiZP2VhBGjyi3s+Ds/oVlLZY+s8rtQHwy4PMXF8JjziNl
wdVpYR6H7+7sUHeeM2xH2hKi7Q84dJA0QlSGZdRy4yf5lnw9VH5BNs0NfeVltW0i
TmANygltxafQ4Z4wyiW+lx1R/JuuT9/0Q+5sFyczux+y/nJMKQf4LCSDV+TBXlbf
m+AcO4sLrBF7uOsVTwElw+n4+4rQ06RDzT8IP4sYW6MwOCNsjNzchbkEL5w1Y+KS
pcaI77LrqwwmQjC1MF/aCaeAXQNghRqfTpUkzmemnnjFm5KGSa6SyHI8DXYY+ox4
io7kEyBx6nAWgtQ8MUQ8S07DKvoSDKR/MSESeGqyfTEB4Ox1XFJT/hEX/eVrsCO9
MM4IhlyO5BkwSzE/lGWm
=VlPQ
-END PGP SIGNATURE-

Re: Making Debian ports less burdensome

[Steven Chamberlain]

Steven Chamberlain wrote:
> Matthias Klose wrote:
> > [...] when unstable is out of sync, and should be forbidden for a set
> > of core packages from my point of view.
> 
> [...] We could say that fixing RC bugs in
> those packages is a requirement for the port to be releaseable.

This reminds me of:
https://wiki.debian.org/ReleaseGoals/CrossBuildableBase

To successfully rebootstrap, a set of core packages all must be able to
build, their build-depends must be installable, and (IIRC) sometimes
must have the same binNMU version.

Npt being able to re-bootstrap a port is probably an indication its
toolchain is in bad shape, so this is probably where porters need to be
more active.

I would like to think kfreebsd toolchain has improved a bit since I
started working in that area, and the feedback I get from Helmut when
things break is incredible helpful.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Making Debian ports less burdensome

[Steven Chamberlain]

Matthias Klose wrote:
> [...] when unstable is out of sync, and should be forbidden for a set
> of core packages from my point of view.

Exactly;  there are some packages that can't just be removed, or
the whole port would be broken.  We could say that fixing RC bugs in
those packages is a requirement for the port to be releaseable.  I think
the architecture release criteria is really lacking that kind of detail
to judge ports by.  But now, we have a quite good definition of what are
'core' packages of each port, from the rebootstrapping work.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Making Debian ports less burdensome

[Steven Chamberlain]

Adam Borowski wrote:
> John Paul Adrian Glaubitz wrote:
> > > We have a testing distribution in debian-ports?
> 
> We don't, which is a shame.  This badly hinders stuff like porting d-i
> [...]

Without those things, many will struggle to install the port or
do much development on it.  Some options are:

 1. snapshot sid during the freeze, patch some packages and build
install media mostly by hand - I think hurd releases are done
something like this;

 2. debian-ports.org having one or more Britney instances that produce
'testing' suites - rolling releases basically;

 3. or make it easier somehow for ports to become release arches?

where I think the latter, stable releases, are mandatory to ever have
DSA-administered buildds, which in turn is a requirement for getting
into the official release.

> But it appears like Steven meant official release archs.

Yes.  I was thinking of https://bugs.debian.org/815885
(FTBFS on mips was blocking security fixes from migrating)

That was quite easily fixed by the porters, but it could have been
handled much better I think:

  * porters are typically not notified, unless someone files a FTBFS bug
and copies the appropriate mailing list - sometimes it never happens
at all;

  * it seems a patch was sent but wasn't attached to any BTS bug so it
got lost and not applied earlier;

  * *if* the bug stayed unfixed for weeks, delaying fixes from migrating
to testing, that's will annoy maintainers.  If no porters fixed this
bug, isn't it fair that doko could remove the out-of-date binaries
on that arch?  (Essentially leaving it without Java unless fixed).

For example, with kfreebsd it got too difficult to port many GNOME3
packages.  Removing GNOME3 and dependencies from kfreebsd took huge
pressure off maintainers and porters;  everyone was able to concentrate
on other things that really mattered - making GNOME3 better on linux;
and defaulting kfreebsd to another desktop that simply worked, so
porters could spend time on other things.

I saw another example of an arm64 FTBFS keeping a video driver for
MIPS systems out of testing.  An arch-specific removal is obviously
the right thing to do there.

> it would practically mean declaring everything but i386/amd64
> unimportant

I don't want that outcome, I value the ports very highly.  (OTOH
some might even say i386 is unimportant now...)

I want the opposite, making ports more convenient to have in the
official releases, so we can actually have more of them.  Perhaps
slimming them down to something really small (perhaps some not having
Java, or even no X11).  It is nice to be able to release *something*
from the official archive that is installable, stable and you can build
other packages on.  You can easily enough put a testing/sid chroot on
that system to install things that get ported later.

> it doesn't force you to port new stuff but requires a manual action
> (filing an arch-specific RM) to allow regressions.

I hope porters get notified first, and a chance to fix the issue.  A
FTBFS bug that gets no answer is supporting evidence for removal.
Filing those things can be tedious (which is why it often stays
unhandled for so long) so I like the idea of it being somewhat
automated.

Recently, Andreas Beckmann filed dozens of FTBFS-on-kfreebsd bugs.
Once I had them in my mailbox, it was really easy for me to reply to
each one, and I even attached a patch for more than half.  The effort
of filing the bug had actually put me off working on them.

In other cases the package really did want de-crufting;  if kfreebsd was
still in testing, we'd have needlessly held up those from migrating.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Making Debian ports less burdensome

[Matthias Klose]

On 25.02.2016 22:45, Adam Borowski wrote:

On Thu, Feb 25, 2016 at 09:54:30PM +0100, John Paul Adrian Glaubitz wrote:

On 02/25/2016 06:41 PM, Steven Chamberlain wrote:

Packages are auto-removed from testing when they are RC-buggy.
Could we do something similar in unstable, for Debian's ports?


We have a testing distribution in debian-ports?


We don't, which is a shame.  This badly hinders stuff like porting d-i to a
-ports architecture or making an unofficial release (mostly because of not
knowing when to binNMU and in-archive binNMUs conflicting with yours).From


I cross built gcc-5 for m68k, sh4 and sparc64 (including gnat). However this is 
a pain if you have to deal with different binNMUs, either on the release archs 
or the ports. Cross built openjdk-8 for sh4 and sparc64 as well, however no 
success so far with m68k. Two reasons for this: mismatching binNMUs, or binNMUs 
not done across all archs, and binary-indep -dev packages, which make the 
situation just worse when unstable is out of sync, and should be forbidden for a 
set of core packages from my point of view.



But it appears like Steven meant official release archs.  And here, it would
practically mean declaring everything but i386/amd64 unimportant -- I'd say
that while something like half of maintainers are helpful towards porters, a
big part ignores every architecture they don't personally use, and a small
minority is outright hostile.


Well, if you see some architecture popping up as a release architecture for 
years now, you see the release team waving these archs for years on the promise 
that things will improve despite release criteria not being met, and you don't 
see any improvement, why would you care? Even security updates on some release 
architectures don't build.  I was told at a Debconf taking Debian as hostage 
when asking for the removal of such architectures, but as seen with kfreebsd, 
this seems to work fine as well.


Matthias

Re: Making Debian ports less burdensome

[Adam Borowski]

On Thu, Feb 25, 2016 at 09:54:30PM +0100, John Paul Adrian Glaubitz wrote:
> On 02/25/2016 06:41 PM, Steven Chamberlain wrote:
> > Packages are auto-removed from testing when they are RC-buggy.
> > Could we do something similar in unstable, for Debian's ports?
> 
> We have a testing distribution in debian-ports?

We don't, which is a shame.  This badly hinders stuff like porting d-i to a
-ports architecture or making an unofficial release (mostly because of not
knowing when to binNMU and in-archive binNMUs conflicting with yours).

But it appears like Steven meant official release archs.  And here, it would
practically mean declaring everything but i386/amd64 unimportant -- I'd say
that while something like half of maintainers are helpful towards porters, a
big part ignores every architecture they don't personally use, and a small
minority is outright hostile.  Let's keeps the current system for release
archs -- it doesn't force you to port new stuff but requires a manual action
(filing an arch-specific RM) to allow regressions.

-- 
A tit a day keeps the vet away.

Re: Making Debian ports less burdensome

[John Paul Adrian Glaubitz]

On 02/25/2016 06:41 PM, Steven Chamberlain wrote:
> Packages are auto-removed from testing when they are RC-buggy.
> Could we do something similar in unstable, for Debian's ports?

We have a testing distribution in debian-ports?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913