Re: Help, I broke sso.debian.org for chrome

file is the one distributed to participating servers, so if there's something wrong, it will have "infected" the other hosts as well. I can't see anything wrong there either, though... Starting with a blank chromium config (.config/chromium + .pki/nssdb) and importing the client there doesn't help either. Christoph

Re: Help, I broke sso.debian.org for chrome

On Tue, Sep 05, 2017 at 12:16:47PM +0200, Christoph Berg wrote: > My guess is that the new-style certificates are missing some > attributes: > > Old certificate from 2015: > > X509v3 extensions: > X509v3 Basic Constraints: critical > CA:FALSE >

Re: Help needed for #871234 FTBFS with GCC-7: error: type/value mismatch

Hi Alex! Alex Mestiashvili kirjoitti 05.09.2017 klo 14:55: parameter list for 'template struct std::hash' while (pos I think the problem is we don't want std::hash but GHash::hash and GHash::GHashEntry::hash. (Sorry, I haven't looked deeper into how to get the correct 'hash'.) Cheers,

Re: Help, I broke sso.debian.org for chrome

  With Best Regards, Tim On 09/05/2017 03:08 PM, Ian Jackson wrote: > Christoph Berg writes ("Re: Help, I broke sso.debian.org for chrome"): >> Re: Enrico Zini 2017-09-05 <20170905093701.xncmprl2x4so6...@enricozini.org> >>> I refactored the certificate

Re: Help, I broke sso.debian.org for chrome

Christoph Berg writes ("Re: Help, I broke sso.debian.org for chrome"): > Re: Enrico Zini 2017-09-05 <20170905093701.xncmprl2x4so6...@enricozini.org> > > I refactored the certificate generation code for sso.debian.org, and the > > certificates it gene

Help needed for #871234 FTBFS with GCC-7: error: type/value mismatch

Any help is greatly appreciated, here it the gcc's complain: In file included from gff.h:12:0, from gtf_tracking.h:12, from bundles.h:22, from replicates.h:10, from common.cpp:28: GHash.hh: In member function 'GHash::GHashEntry

Re: Help, I broke sso.debian.org for chrome

Re: Enrico Zini 2017-09-05 <20170905093701.xncmprl2x4so6...@enricozini.org> > I refactored the certificate generation code for sso.debian.org, and the > certificates it generates now still work in Firefox but not in Chrome. My guess is that the new-style certificates are missing some attributes:

Help, I broke sso.debian.org for chrome

doesn't even ask for which certificate to use Can you help me find out what is in the certificates it generates now that chrome doesn't like? This is the code that generates the certificate: https://anonscm.debian.org/cgit/debian-sso/debian-sso.git/tree/ca/ca.py#n402 This is the code before

Accepted node-help-me 1.0.1-1 (source all) into unstable, unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 23 Jul 2017 14:35:41 + Source: node-help-me Binary: node-help-me Architecture: source all Version: 1.0.1-1 Distribution: unstable Urgency: low Maintainer: Debian Javascript Maintainers <pkg-javascript

Bug#869494: ITP: node-help-me -- help command for node, partner of minimist and commist

Package: wnpp Severity: wishlist Owner: Ying-Chun Liu (PaulLiu) <paul...@debian.org> X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-help-me Version : 1.1.0 Upstream Author : Matteo Collina <he...@matteocollina.com> * URL : https://github.

Bug#865989: ITP: ruby-native-package-installer -- Ruby library to help install native packages on "gem install"

RL : https://github.com/ruby-gnome2/native-package-installer * License : LGPL-3+ Programming Lang: Ruby Description : Ruby library to help install native packages on "gem install" Users need to install native packages to install an extension library that depends on

Bug#865339: ITP: no-littering-el -- help keeping ~/.emacs.d clean

ramming Lang: Emacs Lisp Description : help keeping ~/.emacs.d clean The default paths used to store configuration files and persistent data are not consistent across Emacs packages. This isn't just a problem with third-party packages but even with built-in packages. This package set

Re: Help me

On Sat, Jun 17, 2017 at 12:05 AM, МБУЗ ГКБ № 1 wrote: > Hi no work in Debian 8.8 > No start firebird 2.5 classic and super error Please contact our support channels for help diagnosing the error: https://www.debian.org/support Once you have diagnosed where the problem is, you can report

Help me

Hi no work in Debian 8.8 No start firebird 2.5 classic and super error work@work-desktop ~ $ sudo dpkg-reconfigure firebird2.5-classic [sudo] password for work: GSEC> GSEC> update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults

Re: Help requested: Packages which FTBFS randomly

On Thu, 23 Feb 2017 at 10:02:55 -0800, Nikolaus Rath wrote: > Yes, but last time I checked a "apt-get source && debuild -us -uc" still > defaults to using just a single CPU unless you explicitly set > DEB_BUILD_OPTIONS=parallel. Check again - dpkg-buildpackage now defaults to -Jauto (it sets

Re: Help requested: Packages which FTBFS randomly

❦ 23 février 2017 10:02 -0800, Nikolaus Rath  : Your chosen build environment is not common [...] >>> >>> This has come up a few times now. Could someone explain what is so odd >>> about his envirnoment? It does not look unusual to me. >> >> Official buildd have several

Re: Help requested: Packages which FTBFS randomly

On Feb 21 2017, Vincent Bernat wrote: > ❦ 21 février 2017 09:48 -0800, Nikolaus Rath  : > >>> Your chosen build environment is not common [...] >> >> This has come up a few times now. Could someone explain what is so odd >> about his envirnoment? It does not

Re: Help requested: Packages which FTBFS randomly

On Tue, 21 Feb 2017 at 23:35:44 +, Ben Hutchings wrote: > Having said that, some ioctls that make sense for block-backed > filesystems, such as FS_IOC_FIEMAP, won't work on a tmpfs (or nfs, > ubifs, etc.). One notable omission is that tmpfs doesn't do generic "user." extended attributes (due

Re: Help requested: Packages which FTBFS randomly

❦ 22 février 2017 00:46 +0100, Adam Borowski  : >> > > * using a qemu build chroot (Debian doesn't do this, other might) >> > >> > Is that because QEMU is slow, or some other reason? >> >> AIUI qemu(-static) cannot handle threading very well. So if a build >> process uses

Re: Help requested: Packages which FTBFS randomly

On Tue, 2017-02-21 at 14:18 -0700, Sean Whitton wrote: > On Tue, Feb 21, 2017 at 02:37:23AM +, Ben Hutchings wrote: > > > * with /tmp on tmpfs on some archs > > > > [...] > > > > You mean the 64-bit PowerPC architectures?  tmpfs allocates at > > least a > > page per file, and they have 64K

Re: Help requested: Packages which FTBFS randomly

On Tue, Feb 21, 2017 at 11:04:52PM +0100, Christoph Biedl wrote: > > > * using a qemu build chroot (Debian doesn't do this, other might) > > > > Is that because QEMU is slow, or some other reason? > > AIUI qemu(-static) cannot handle threading very well. So if a build > process uses such

Re: Help requested: Packages which FTBFS randomly

Ben Hutchings wrote... > > * when using eatmydata > > I can certainly think of a test case that would be broken by eatmydata > and I would not want to rule out such test cases. But still, I am > suprised by this. #667965 - don't know whether this still exists. I later decided to patch dpkg so

Re: Help requested: Packages which FTBFS randomly

Sean Whitton wrote... > I'm not sure why you're mentioned powerpc archs Because that's a surprising feature of that arch and once you've realized you were caught by this, you will not forget it. Bonus: Rebuilding on a porter box passes since /home is not a tmpfs. Christoph PS:

Re: Help requested: Packages which FTBFS randomly

On Tue, Feb 21, 2017 at 02:37:23AM +, Ben Hutchings wrote: > > * with /tmp on tmpfs on some archs > [...] > > You mean the 64-bit PowerPC architectures? tmpfs allocates at least a > page per file, and they have 64K pages... I'm not sure why you're mentioned powerpc archs, but as a hopefully

Re: Help requested: Packages which FTBFS randomly

On Tue, Feb 21, 2017 at 09:36:58PM +0100, Vincent Bernat wrote: > Accomodating for all build environments is a slippery slope. What if I > use a 128MB host with 64GB of swap? Timing-related tests will start to > fail. Is it Debian job to fix all the test suites? Should I be able to > build

Re: Help requested: Packages which FTBFS randomly

❦ 21 février 2017 09:48 -0800, Nikolaus Rath  : >> Your chosen build environment is not common [...] > > This has come up a few times now. Could someone explain what is so odd > about his envirnoment? It does not look unusual to me. Official buildd have several CPU. Most

Re: Help requested: Packages which FTBFS randomly

> Your chosen build environment is not common [...] This has come up a few times now. Could someone explain what is so odd about his envirnoment? It does not look unusual to me. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38

Re: Help requested: Packages which FTBFS randomly

On Tue, 2017-02-21 at 11:50 +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 then

Re: Help requested: Packages which FTBFS randomly

On Mon, Feb 20, 2017 at 04:42:49PM -0800, Russ Allbery wrote: > To say my opinion explicitly, since there's been a lot of discussion here, > some of which I've been involved in somewhat ambiguously: Thanks for writing this up, Russ. I fully agree with *everything* you said here: > I think this

Re: Help requested: Packages which FTBFS randomly

On Mon, Feb 20, 2017 at 01:12:33PM +0100, Santiago Vila wrote: > Believe me, this is also frustrating for me. If you absolutely need a > machine to reproduce this, contact me privately. If someone creates a patch, then the bug is much more likely to get fixed, whether it's RC or not. Any FTBFS

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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 >

Re: Help requested: Packages which FTBFS randomly

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)

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

Vincent Bernat writes ("Re: Help requested: Packages which FTBFS randomly"): > ❦ 20 février 2017 21:13 GMT, Ian Jackson <ijack...@chiark.greenend.org.uk> : > > With the correct infrastructure (which is not that hard) the causes > > can be completely eliminated.

Re: Help requested: Packages which FTBFS randomly

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

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 packages and if I did I would hunt them down > with

Re: aren't unreliable tests worse than none? (Re: Help requested: Packages which FTBFS randomly)

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

Re: aren't unreliable tests worse than none? (Re: Help requested: Packages which FTBFS randomly)

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

Re: Help requested: Packages which FTBFS randomly

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 bu

Re: Help requested: Packages which FTBFS randomly

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

Re: aren't unreliable tests worse than none? (Re: Help requested: Packages which FTBFS randomly)

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

Re: aren't unreliable tests worse than none? (Re: Help requested: Packages which FTBFS randomly)

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…

Re: aren't unreliable tests worse than none? (Re: Help requested: Packages which FTBFS randomly)

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

Re: aren't unreliable tests worse than none? (Re: Help requested: Packages which FTBFS randomly)

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

Re: aren't unreliable tests worse than none? (Re: Help requested: Packages which FTBFS randomly)

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

Re: Help requested: Packages which FTBFS randomly

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

Re: aren't unreliable tests worse than none? (Re: Help requested: Packages which FTBFS randomly)

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: aren't unreliable tests worse than none? (Re: Help requested: Packages which FTBFS randomly)

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: aren't unreliable tests worse than none? (Re: Help requested: Packages which FTBFS randomly)

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

Re: aren't unreliable tests worse than none? (Re: Help requested: Packages which FTBFS randomly)

❦ 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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

aren't unreliable tests worse than none? (Re: Help requested: Packages which FTBFS randomly)

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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 understandable that most packagers don't want to blindly disable them. Your chosen

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

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 them mysterious > trouble. It also causes trouble for stalwarts like Santiago,

Re: Bug#848063: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

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

Re: Help requested: Packages which FTBFS randomly

n't think we should do absolutely nothing in stretch > about this, so I'll continue to ask for help here in -devel: > > [...] Note, I did not intend to stop this thread on -devel. I did intend to inform Ian of the bug and the release team's view on it, since he involved -release. FTR,

Re: Help requested: Packages which FTBFS randomly

On Fri, Feb 17, 2017 at 08:54:54AM -0600, Jeff Epler wrote: > On Fri, Feb 17, 2017 at 12:16:16PM +0100, Santiago Vila wrote: > > Can anyone here reproduce any of the following *two* bugs? > > (Using sbuild in a single-CPU machine) > > > > 837067 1.000 libsecret > > Using a fresh 1CPU / 1GB

Re: Help requested: Packages which FTBFS randomly

On Fri, Feb 17, 2017 at 03:34:08PM +, Holger Levsen wrote: > https://tests.reproducible-builds.org/libsecret looks better: I forgot to mention this (kind of) URL: https://tests.reproducible-builds.org/debian/history/libsecret.html -- cheers, Holger signature.asc Description:

Re: Help requested: Packages which FTBFS randomly

On Fri, Feb 17, 2017 at 08:54:54AM -0600, Jeff Epler wrote: > On Fri, Feb 17, 2017 at 12:16:16PM +0100, Santiago Vila wrote: > > Can anyone here reproduce any of the following *two* bugs? > > (Using sbuild in a single-CPU machine) > > 837067 1.000 libsecret > > Using a fresh 1CPU / 1GB x86

Re: Help requested: Packages which FTBFS randomly

On Fri, Feb 17, 2017 at 12:16:16PM +0100, Santiago Vila wrote: > Can anyone here reproduce any of the following *two* bugs? > (Using sbuild in a single-CPU machine) > > 837067 1.000 libsecret Using a fresh 1CPU / 1GB x86 system on digitalocean's NYC region, upgraded to debian testing, I tried

Re: Help requested: Packages which FTBFS randomly

n I said "Ok, will do" in Bug #844264, it was a reply to your request to postpone this after the freeze, not after the release. I definitely don't think we should do absolutely nothing in stretch about this, so I'll continue to ask for help here in -devel: Let's consider only the

Re: Help requested: Packages which FTBFS randomly

Ian Jackson: > Santiago Vila writes ("Help requested: Packages which FTBFS randomly"): >> The following packages FTBFS for me randomly. First column is the bug >> number, second column is the estimated probability of failure in my >> build envir

Re: Help requested: Packages which FTBFS randomly

On Thu, Feb 16, 2017 at 10:32:04PM +, Jonathan Dowland wrote: > Thanks for doing this. ...despite alarming hostility from your fellow developers (as I read the bugs in more detail, in growing horror... #844264 in particular) -- Jonathan Dowland Please do not CC me, I am subscribed to the

Re: Help requested: Packages which FTBFS randomly

This is really intriguing. I suspected your build environment must have been weird, but it looks fine to me. The likely elephant in the room is the single processor. I'm pretty amazed that this seems to be a stumbling block, but there we go. Thanks for doing this. signature.asc Description:

Re: Help requested: Packages which FTBFS randomly

Santiago Vila writes ("Help requested: Packages which FTBFS randomly"): > 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: IMO all of thes

Re: Help requested: Packages which FTBFS randomly

On Wed, Feb 15, 2017 at 03:02:23PM -0500, Jeremy Bicha wrote: > On Wed, Feb 15, 2017 at 2:36 PM, Santiago Vila wrote: > > Allowing packages to fail 50% of the time is interpreting Release > > Policy in a somewhat twisted way. > > Except that your build system is far more limited

Re: Help requested: Packages which FTBFS randomly

o many of them that I had little time to debug them myself. That's why I'm asking for help. I can't do this alone anymore. The build logs are out there, just take a look at the bugs themselves. Thanks.

Re: Help requested: Packages which FTBFS randomly

On Wed, Feb 15, 2017 at 2:36 PM, Santiago Vila wrote: > Allowing packages to fail 50% of the time is interpreting Release > Policy in a somewhat twisted way. Except that your build system is far more limited than the average system used to build packages in 2017. Thanks, Jeremy

Re: Help requested: Packages which FTBFS randomly

On Wed, Feb 15, 2017 at 08:05:51PM +0100, Thibaut Paumard wrote: > Dear Santiago, > > Le 15/02/2017 à 18:26, Santiago Vila a écrit : > > Hello. > > > > The following packages FTBFS for me randomly. First column is the bug > > number, second column is the estimated probability of failure in my >

Re: Help requested: Packages which FTBFS randomly

Hi, > 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 did you try to diff the build

Re: Help requested: Packages which FTBFS randomly

Dear Santiago, Le 15/02/2017 à 18:26, Santiago Vila a écrit : > Hello. > > 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: > >

Help requested: Packages which FTBFS randomly

Hello. 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 Release Managers that they

Re: HELP - Español and English

On Thu, Jan 26, 2017 at 11:16 PM, Jeans Manuel Morell Veliz wrote: > Can you tell me what is happening to the Debian system? Please contact the Debian user support channels for help: https://www.debian.org/support -- bye, pabs https://wiki.debian.org/PaulWise

HELP - Español and English

hola he encontrado un problema y se lo voy a explicar! 1.Instalo debian 8.6 los 3dvd versión escritorio o versión consola. a)hago una repositorio local con los dvd en la dirección /var/repo. b)Instalo ntp y ntpdate, krb5-user libkrb5-3, squid3 ldap-utils, Samba and Winbind. 2.Configuro y logro:

<    1   2   3   4   5   6   7   8   9   10   >