Am 21.02.2017 um 01:55 schrieb Patrick Schleizer:
> for file_name in /usr/lib/server-config.d/*.conf ; do
>file_list="$file_list $file_name"
> done
>
> for file_name in /etc/server-config.d/*.conf ; do
>file_list="$file_list $file_name"
> done
>
> for file_name in /home/.config/server-co
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: golang-github-makenowjust-heredoc
Version : 0.0~git20140704.0.1d91351-1
Upstream Author : TSUYUSATO Kitsune
* URL
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: golang-github-xanzy-go-cloudstack
Version : 2.1.1+git20160728.1.1e2cbf6-1
Upstream Author : Sander van Harmelen
* URL
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: golang-github-vmware-photon-controller-go-sdk
Version : 0.0~PROMOTED-339-1
Upstream Author : VMware, Inc.
* URL :
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter
* Package name: golang-github-lpabon-godbc
Version : 1.0+git20140613.1.9577782-1
Upstream Author : Luis Pabón
* URL : https://git
BeMyStreet devient gratuit pour les pros.
Nous avons une bonne nouvelle pour vous ! BeMyStreet devient gratuit pour les
professionnels pour votre plus grand plaisir. Alors ne vous en privez surtout
pas, vendez en ligne facilement et profitez de tous les avantages BeMyStreet :
***Visibil
On Tue, Feb 21, 2017 at 11:50:15AM +0800, Paul Wise wrote:
> On Tue, Feb 21, 2017 at 6:36 AM, Christoph Biedl wrote:
>
> > This is a charming idea altough I have doubt it will work out: As
> > usual the information has to be kept up-to-date, so unless it is
> > collected and verified every now and
On Tue, Feb 21, 2017 at 6:36 AM, Christoph Biedl wrote:
> This is a charming idea altough I have doubt it will work out: As
> usual the information has to be kept up-to-date, so unless it is
> collected and verified every now and then automatically, it will
> become unsuable pretty soon.
FYI the
On Mon, 2017-02-20 at 23:36 +0100, Christoph Biedl wrote:
> Niels Thykier wrote...
>
> [ topic shift ]
>
> > On a related note: Having some way to declare minimum requirements for
> > e.g. disk space and memory (a la "base GB usage + GB usage/core") used
> > would be great.
> > Especially if it
Package: wnpp
Severity: wishlist
Owner: "Paulo Roberto Alves de Oliveira (aka kretcheu)"
* Package name: peek
Version : 0.8.0
Upstream Author : Philipp Wolfer
* URL : https://github.com/phw/peek
* License : GPL-3+
Programming Lang: C Vala Compiler
Descript
A convention on listen port local or all network interfaces etc. would
be desirable.
At the moment it looks like there is no convention for where server
applications are configured to listen by default, on localhost vs. all
interfaces. Looks like deciding that is up to the upstream author of the
s
A convention on listen port local or all network interfaces etc. would
be desirable.
At the moment it looks like there is no convention for where server
applications are configured to listen by default, on localhost vs. all
interfaces. Looks like deciding that is up to the upstream author of the
s
Santiago Vila writes:
> The following packages FTBFS for me randomly. First column is the bug
> number, second column is the estimated probability of failure in my
> build environment, which is described here:
> https://people.debian.org/~sanvila/my-building-environment.txt
> Before I ask the R
Holger Levsen writes:
> On Mon, Feb 20, 2017 at 09:59:29PM +, Ian Jackson wrote:
>> + A FTBFS bug is still RC even if:
>> + it doesn't happens on buildd.debian.net;
>> + it only happens randomly;
>> + it only happens on machines with one (virtual) cpu core.
> while I do a
Santiago Vila wrote...
> I fully agree with the underlying idea, however: If we can measure the
> failure rate, then it means it already fails too often to be acceptable.
Cannot deny I somehow like that approach.
> For that to happen, the around 50 packages which FTBFS randomly should
> do so le
Niels Thykier wrote...
[ topic shift ]
> On a related note: Having some way to declare minimum requirements for
> e.g. disk space and memory (a la "base GB usage + GB usage/core") used
> would be great.
> Especially if it is available in metadata, so wanna-build can see
> whether it makes sense
On Mon, Feb 20, 2017 at 09:59:29PM +, Ian Jackson wrote:
> My advice would be to avoid asking the TC such general questions.
My advice too.
> There are two sensible questions:
>
> * Should the following bugs be RC ?
> [ list of 20 bugs or whatever ]
with a list of 20 bugs I dont think
Santiago Vila writes ("Re: Help requested: Packages which FTBFS randomly"):
> Maybe this one for a start?:
>
> Should building Debian source packages on a single-CPU machine be
> supported at the same level as building on a multi-core machine, to
> the point that a FTBFS bug on a single-CPU mac
Vincent Bernat writes ("Re: Help requested: Packages which FTBFS randomly"):
> ❦ 20 février 2017 21:13 GMT, Ian Jackson :
> > With the correct infrastructure (which is not that hard) the causes
> > can be completely eliminated. I don't ever experience random build
> > failures of any of my own p
On Mon, Feb 20, 2017 at 09:22:35PM +, Ian Jackson wrote:
> If you do not get good answers, please take this to the TC.[1]
Thanks a lot for your support, Ian.
What kind of question do you think I could make to the TC?
Maybe this one for a start?:
Should building Debian source packages on a
❦ 20 février 2017 21:13 GMT, Ian Jackson :
> With the correct infrastructure (which is not that hard) the causes
> can be completely eliminated. I don't ever experience random build
> failures of any of my own packages and if I did I would hunt them down
> with a vengeance.[1]
Good for you.
h
Ian Jackson writes:
> Russ Allbery writes:
>> The point is that they don't randomly fail in the sense that they don't
>> fail n% of the time when run in any possible build environment.
>> Rather, in the subset of cases we're talking about in this thread, the
>> tests work reliably on the develope
Russ Allbery writes ("Re: aren't unreliable tests worse than none? (Re: Help
requested: Packages which FTBFS randomly)"):
> The point is that they don't randomly fail in the sense that they don't
> fail n% of the time when run in any possible build environment. Rather,
> in the subset of cases we
Santiago Vila writes ("Re: Help requested: Packages which FTBFS randomly"):
> I don't think that's what we want.
Picking on this message at random:
Many of the messages in this thread are IMO defending the
indefensible, using unreasonable arguments. Reading them, and some of
the bug reports you
Christoph Biedl writes ("Re: Help requested: Packages which FTBFS randomly"):
> Ian Jackson wrote...
> > IMO all of these bugs should be RC. A randomly-reproducible build
> > failure with more than negligible probabilty is likely to show up for
> > some of Debian's users and downstreams and cause
Guido Günther writes ("Re: changelog practice, unfinalised vs UNRELEASED vs
~version"):
> On Sun, Feb 12, 2017 at 12:48:35PM +, Ian Jackson wrote:
> > We do not seem to have a coherent approach to how to handle
> > debian/changelog in trees (eg, vcs branches) which are not yet ready
> > for up
On Mon, Feb 20, 2017 at 06:46:25PM +, Holger Levsen wrote:
> On Mon, Feb 20, 2017 at 10:29:28AM -0800, Russ Allbery wrote:
> > The point is that they don't randomly fail in the sense that they don't
> > fail n% of the time when run in any possible build environment.
We don't really know. Some
Holger Levsen writes:
> On Mon, Feb 20, 2017 at 10:29:28AM -0800, Russ Allbery wrote:
>> This is, in a sense, an unreliable test, but it's not unreliable in a
>> way that directly affects the main line of package development.
> until someone affected wants to contribute…
Sure. I think it's a h
On Mon, Feb 20, 2017 at 10:29:28AM -0800, Russ Allbery wrote:
> The point is that they don't randomly fail in the sense that they don't
> fail n% of the time when run in any possible build environment.
…but point taken, not all FTBFS bugs are RC(!) as
<20170220152410.3mkm5tebg5i2y...@perpetual.pse
On Mon, Feb 20, 2017 at 10:29:28AM -0800, Russ Allbery wrote:
> This is, in a sense, an unreliable test, but it's not unreliable in a way
> that directly affects the main line of package development.
until someone affected wants to contribute…
--
cheers,
Holger
signature.asc
Descript
Hi Afif,
On Mon, Feb 20, 2017 at 08:30:15AM -0800, Afif Elghraoui wrote:
> > On Mon, Feb 20, 2017 at 08:14:30AM -0800, Afif Elghraoui wrote:
> >> Description : phylogenetic analyses on trees and sequences for UNIX
> >
> > Please drop " for UNIX" here - since this is redundant on a Debian sy
Holger Levsen writes:
> While I agree with Niels that it would be very worthwhile to be able to
> define ressource requirements for a package to build (and thus know I
> have to life with some packages having trouble sometimes) I find it
> *very* strange to be content with test suites which rando
On Mon, Feb 20, 2017 at 11:45:00AM +0100, Vincent Bernat wrote:
> Time is a limited resource and we need to set our priorities. Having
> test suites that work 100% of the time with constrained resources is not
> a goal I find worthy of the time I can spend on Debian. Unfortunately,
> those bugs are
On Mon, Feb 20, 2017 at 06:10:23PM +0100, Vincent Bernat wrote:
> ❦ 20 février 2017 13:44 GMT, Holger Levsen :
>
> >> As a rule of thumb, upstream usually knows better than me which tests
> >> are important. Tests are quite important for the packager to know if
> >> they didn't make an obvious m
Le 20 février 2017 16:55:49 GMT+01:00, Julien Cristau a
écrit :
>On 02/20/2017 07:57 AM, Niels Thykier wrote:
>> Vincent Bernat:
>>> [...]
>>>
>>> [...] The policy doesn't state that a package
>>> must build when there is not enough disk space or memory. Maybe it
>would
>>> be far simpler to al
On Mon, 2017-02-20 at 08:30 +, Simon McVittie wrote:
> On Mon, 20 Feb 2017 at 01:00:33 +0100, Santiago Vila wrote:
> > Wait a moment. How we do define "common" when applied to a "build
> > environment"?
>
> Do we rely on it for Debian to function, or was it set up to determine
> what works (e.
On Mon, Feb 20, 2017 at 03:24:10PM +, Simon McVittie wrote:
> On Mon, 20 Feb 2017 at 10:41:49 +0100, Santiago Vila wrote:
> > You are somehow trying to equate RC-ness with "it FTBFS in
> > buildd.debian.org".
>
> No, I'm saying that a sufficiently repeatable FTBFS on buildd.debian.org
> is ef
❦ 20 février 2017 13:44 GMT, Holger Levsen :
>> As a rule of thumb, upstream usually knows better than me which tests
>> are important. Tests are quite important for the packager to know if
>> they didn't make an obvious mistake when updating a package (e.g new
>> dependency missing, something e
Hi, Andreas,
على الإثنين 20 شباط 2017 08:26، كتب Andreas Tille:
> Hi Afif
>
> On Mon, Feb 20, 2017 at 08:14:30AM -0800, Afif Elghraoui wrote:
>> Description : phylogenetic analyses on trees and sequences for UNIX
>
> Please drop " for UNIX" here - since this is redundant on a Debian syste
Hi Afif
On Mon, Feb 20, 2017 at 08:14:30AM -0800, Afif Elghraoui wrote:
> Description : phylogenetic analyses on trees and sequences for UNIX
Please drop " for UNIX" here - since this is redundant on a Debian system.
May be
s/ for UNIX/ at command line enabling pipes/
or something like
Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team
* Package name: phyx
Version : 0.99
Upstream Author : Joseph W. Brown, Joseph F. Walker, and Stephen A. Smith
* URL : https://github.com/FePhyFoFum/phyx
* License : GPL
Programming Lang: C++
Package: wnpp
Severity: wishlist
Owner: Apollon Oikonomopoulos
Control: block 673515 by -1
* Package name: bidi-clojure
Version : 1.25.1
Upstream Author : JUXT LTD.
* URL : https://github.com/juxt/bidi
* License : MIT/X11
Programming Lang: Clojure
Descripti
On 02/20/2017 07:57 AM, Niels Thykier wrote:
> Vincent Bernat:
>> [...]
>>
>> [...] The policy doesn't state that a package
>> must build when there is not enough disk space or memory. Maybe it would
>> be far simpler to allow packages to fail to build if there is not enough
>> CPUs.
>>
>
> On a r
On Mon, 20 Feb 2017 at 10:41:49 +0100, Santiago Vila wrote:
> You are somehow trying to equate RC-ness with "it FTBFS in buildd.debian.org".
No, I'm saying that a sufficiently repeatable FTBFS on buildd.debian.org
is effectively release-critical whether Policy says it is or not,
because if we can'
On Mon, Feb 20, 2017 at 01:46:20PM +0100, Vincent Bernat wrote:
> As a rule of thumb, upstream usually knows better than me which tests
> are important. Tests are quite important for the packager to know if
> they didn't make an obvious mistake when updating a package (e.g new
> dependency missing,
❦ 20 février 2017 11:03 GMT, Holger Levsen :
>> Time is a limited resource and we need to set our priorities. Having
>> test suites that work 100% of the time with constrained resources is not
>> a goal I find worthy of the time I can spend on Debian.
>
> While I agree with Niels that it would b
On Mon, Feb 20, 2017 at 11:33:23AM +, Ghislain Vaillant wrote:
> I share the same feelings towards a similar intermittent FTBFS with
> src:python-qtpy (#8544936). I admit I have no clue what is going on,
> neither does upstream, nor does the reporter (Santiago).
That would be #854496. It also
On Mon, 2017-02-20 at 11:45 +0100, Vincent Bernat wrote:
> ❦ 20 février 2017 10:05 GMT, Jonathan Dowland :
>
> > None of the FTBFS problems I've seen in this thread have been because the
> > tests *required* multiple cores, by the way; more so that they were racy
> > or buggy in some other fashi
On 02/20/2017 11:05 AM, Jonathan Dowland wrote:
> On Mon, Feb 20, 2017 at 01:57:52AM +0100, Adam Borowski wrote:
>> * single-CPU machines have gone the way of the dodo. Even the crummiest
>> machine I could find while dumpster-diving looking for a non-sse3 one
>> already has HT and builds your
On Mon, Feb 20, 2017 at 11:45:00AM +0100, Vincent Bernat wrote:
> Time is a limited resource and we need to set our priorities. Having
> test suites that work 100% of the time with constrained resources is not
> a goal I find worthy of the time I can spend on Debian.
While I agree with Niels that
On 02/15/2017 09:45 PM, Santiago Vila wrote:
> Building a package is like following an algorithm. It may take less or
> more time, but it always has to finish. For this reason, "your CPU is
> too slow to build my package" is always a very poor excuse, and I hope
> you are not trying to set a minimu
On 02/19/2017 06:44 AM, gustavo panizzo wrote:
> On Sun, Feb 19, 2017 at 01:10:21AM +0100, Thomas Goirand wrote:
>> On 02/18/2017 05:14 PM, Andrew Bogott wrote:
>>> Does this
>>> announcement mean that the Mirantis apt servers (e.g.
>>> mitaka-jessie.pkgs.mirantis.com) will also be discontinued
>>
❦ 20 février 2017 10:05 GMT, Jonathan Dowland :
> None of the FTBFS problems I've seen in this thread have been because the
> tests *required* multiple cores, by the way; more so that they were racy
> or buggy in some other fashion. If uniprocessor buildds are finding these
> bugs then that's a
On Mon, Feb 20, 2017 at 01:57:52AM +0100, Adam Borowski wrote:
> * single-CPU machines have gone the way of the dodo. Even the crummiest
> machine I could find while dumpster-diving looking for a non-sse3 one
> already has HT and builds your examples successfully. Same for ARM SoCs
> -- my
On Mon, Feb 20, 2017 at 08:30:04AM +, Simon McVittie wrote:
> Debian is an operating system, not an academic exercise. If a package
> builds successfully reliably enough on buildds, porterboxes, and
> developers' hardware or VMs that we can prepare security updates and
> other urgent patches fo
On Mon, Feb 20, 2017 at 01:57:52AM +0100, Adam Borowski wrote:
> * single-CPU machines have gone the way of the dodo. Even the crummiest
> machine I could find while dumpster-diving looking for a non-sse3 one
> already has HT and builds your examples successfully. Same for ARM SoCs
> -- my
On Mon, 20 Feb 2017 at 01:00:33 +0100, Santiago Vila wrote:
> Wait a moment. How we do define "common" when applied to a "build
> environment"?
Do we rely on it for Debian to function, or was it set up to determine
what works (e.g. for QA)? The former is common; the latter might not
be, and failin
57 matches
Mail list logo
