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
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
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
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
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
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
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
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
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,
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
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,
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
-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
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:
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
-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
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
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
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
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?
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
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
22 matches
Mail list logo
