Hi,
> Looking at the description of the issue, it would also seem reasonable
> to attempt to fix it in Jessie.
0.6.1-2 in jessie is not affected. It uses VNC as backend and does not
implement RFX. It is slow for high resolutions, yes, but that's not this
issue - it's because you haven't seen a fa
Package: wnpp
Severity: wishlist
Owner: Lev Lamberov
* Package name: pyvenv-el
Version : 1.9
Upstream Author : Jorgen Schaefer
* URL : http://github.com/jorgenschaefer/pyvenv
* License : GPL-3+
Programming Lang: Emacs Lisp
Description : Python virtual
On Fri, Feb 17, 2017 at 06:59:00PM +, Niels Thykier wrote:
> Santiago Vila:
> > On Fri, Feb 17, 2017 at 06:23:00AM +, Niels Thykier wrote:
> >
> >> Santiago already brought it up in #844264. I believe my answer in
> >> comment 70 is still relevant (other than I incorrectly used "after the
On Wed, Feb 15, 2017 at 06:26:51PM +0100, Santiago Vila wrote:
> 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-build
Am Sonntag, den 19.02.2017, 16:09 +0100 schrieb Steve Cotton:
> Impossible d'initialiser SDL:Couldn't open X11 display
Why does the package require an X11 display to build?
- Fabian
signature.asc
Description: This is a digitally signed message part
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 them mysterious
> trouble. It also causes trouble for stalwarts like Santiago, doing
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-bsphere-le-go
Version : 0.0~git20170215.0.7a984a8-1
Upstream Author : Gal Ben-Haim
* URL : https://
On Sun, Feb 19, 2017 at 06:27:16PM +0100, Christoph Biedl wrote:
> Ian Jackson wrote...
>
> > If there is to be a failure probability threshold I would set it at
> > 10^-4 or so. After all, computer time is cheap.
>
> To determine 10^-4 with some accurance you'd have to rebuild that
> package 200
On Sun, Feb 19, 2017 at 10:59:56PM +0100, Santiago Vila wrote:
> BTW: Could anybody tell me when exactly "FTBFS on a single-CPU machine"
> stopped being serious and RC? Did such thing ever happened?
I don't think so. (It never stopped being serious.)
If some people disagree I'd say this is life
❦ 19 février 2017 22:59 +0100, Santiago Vila :
> I'm pretty sure that I was already a DD when such thing could have
> happened, but right now I can't remember it.
>
> (See #848063 for why I'm asking this).
IMO, you are also pretty aggressive.
More and more packages come with test suites to hel
On Mon, Feb 20, 2017 at 12:05:42AM +0100, Vincent Bernat wrote:
> More and more packages come with test suites to help developers and
> packagers ensure things are working as expected. It would be great if
> test suites didn't have failures of their own but it's better to have
> them and it's under
On Mon, Feb 20, 2017 at 12:05:42AM +0100, Vincent Bernat wrote:
> Your chosen build environment is not common and fixing build failures
> for uncommon environment may seem a waste of the "Debian-allocated time"
> for some people (including me).
Yeah. I think your priorities are somewhat backwards
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
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 related note: Having some way to declare minimum requirem
14 matches
Mail list logo
