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

2017-02-20 Thread Russ Allbery
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

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

2017-02-20 Thread Ian Jackson
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. R

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

2017-02-20 Thread Santiago Vila
a to decide about RC-ness as some people seem to do. This will make bugs not RC "because my computer is too slow" or "because my computer is too fast" or "because my computer is already running the kernel of stretch", or "because I didn't installed this package

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

2017-02-20 Thread Russ Allbery
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

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

2017-02-20 Thread Holger Levsen
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

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

2017-02-20 Thread Holger Levsen
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

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

2017-02-20 Thread Russ Allbery
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

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

2017-02-20 Thread Santiago Vila
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

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

2017-02-20 Thread Vincent Bernat
❦ 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

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

2017-02-20 Thread Holger Levsen
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,

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

2017-02-20 Thread Vincent Bernat
❦ 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

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

2017-02-20 Thread Holger Levsen
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: none

2015-01-01 Thread Tollef Fog Heen
]] Ludovico Cavedon > I could have ntopng include a ntop transitional package, but: > - ntop has version 3:5.0.1, ntopng 1.2.1. I would need to bump the ntopng > version to 4, and I am not very excited by that > - there is no migration path from ntop to ntopng. All settings and data would > be

Bug#759294: ITP: gcc-arm-none-eabi -- GCC cross compiler for ARM Cortex-A/R/M processors

2014-08-25 Thread Agustin Henze
Package: wnpp Severity: wishlist Owner: Agustin Henze X-Debbugs-CC: debian-devel@lists.debian.org, debian-cr...@lists.debian.org Package name: lm4tools Version: 20140816+a565880 Upstream Author: 2011-2012 Texas Instruments Incorporated URL: https://launchpad.net/gcc-arm-emb

Bug#728387: ITP: gdb-arm-none-eabi -- GNU debugger for ARM Cortex-A/R/M processors

2013-10-31 Thread Agustin Henze
Package: wnpp Severity: wishlist Owner: Agustin Henze X-Debbugs-CC: debian-devel@lists.debian.org, debian-cr...@lists.debian.org Package name: gdb-arm-none-eabi Version: 7.4.1 with mainline backports, without target sim support git://sourceware.org/git/gdb.git commit

Bug#728388: ITP: gcc-arm-none-eabi -- GCC cross compiler for ARM Cortex-A/R/M processors

2013-10-31 Thread Agustin Henze
Package: wnpp Severity: wishlist Owner: Agustin Henze X-Debbugs-CC: debian-devel@lists.debian.org, debian-cr...@lists.debian.org Package name: gcc-arm-none-eabi Version: ARM/embedded-4_7-branch revision 202601 http://gcc.gnu.org/svn/gcc/branches/ARM/embedded-4_7-branch/ (4.7

Bug#728386: ITP: binutils-arm-none-eabi -- GNU assembler, linker and binary utilities for ARM Cortex-M/R processors

2013-10-31 Thread Agustin Henze
Package: wnpp Severity: wishlist Owner: Agustin Henze X-Debbugs-CC: debian-devel@lists.debian.org, debian-cr...@lists.debian.org Package name: binutils-arm-none-eabi Version: 2.22 with mainline backports git://sourceware.org/git/binutils.git commit

Re: Mounts with fs type 'none'

2001-09-27 Thread wouter
On Wed, 26 Sep 2001, Steve Greenland wrote: > > mount -t none -o bind /somewhere /some/where/else > > Thanks. Does anything else use '-t none'? Swapspace. But that's hardly an issue... -- wouter dot verhelst at advalvas in Belgium This is Linux world. On a quie

Re: Mounts with fs type 'none'

2001-09-27 Thread Marco d'Itri
On Sep 27, Steve Greenland <[EMAIL PROTECTED]> wrote: >(And why does mount(8) document '--bind' but not '-t none' or '-o >bind'?) Because -o bind is the old API and you are not supposed to use it. -- ciao, Marco

Re: Mounts with fs type 'none'

2001-09-26 Thread Ethan Benson
On Wed, Sep 26, 2001 at 06:53:54PM -0500, Steve Greenland wrote: > > Thanks. Does anything else use '-t none'? i don't know, not that i know of, but i wouldn't rule it out in the future given `none' is pretty generic. > (And why does mount(8) document '

Re: Mounts with fs type 'none'

2001-09-26 Thread Steve Greenland
On 26-Sep-01, 18:31 (CDT), Ethan Benson <[EMAIL PROTECTED]> wrote: > On Wed, Sep 26, 2001 at 06:15:34PM -0500, Steve Greenland wrote: > > I've a request to have checksecurity skip searching filesystems with > > type 'none' (not device 'none'). A brie

Re: Mounts with fs type 'none'

2001-09-26 Thread Ethan Benson
On Wed, Sep 26, 2001 at 06:15:34PM -0500, Steve Greenland wrote: > I've a request to have checksecurity skip searching filesystems with > type 'none' (not device 'none'). A brief check leads me to believe that > these are result of mount --bind, which means t

Mounts with fs type 'none'

2001-09-26 Thread Steve Greenland
I've a request to have checksecurity skip searching filesystems with type 'none' (not device 'none'). A brief check leads me to believe that these are result of mount --bind, which means that the mount in question is either searched or skipped in its "real" lo

(None)

2001-09-22 Thread Cong ty Luat Gia Pham
Title: Cong ty Luat Gia Pham http://www.giapham.com  KÝnh göi: Quý b¹n hµng! C«ng ty LuËt Gia Ph¹m xin göi lêi chµo tr©n träng tíi quý doanh nghiÖp! C«ng ty LuËt Gia Ph¹m, mét C«ng ty chuyªn ho¹t ®éng trong lÜnh vùc t­ vÊn víi ®éi ngò luËt gia, t­ vÊn viªn chuyªn nghiÖp giµu kinh nghiÖm

Bug#1794: bin/sh is shell when none specified in /etc/passwd

1995-11-03 Thread Ian Jackson
Bruce Perens writes: > [EMAIL PROTECTED] said: > > [empty shell fields in /etc/passwd mean /bin/sh] > > This is common practice, and perhaps important if you are using > a Yellow Pages password database that originates on a different > system. I see. I don't really approve, but such things are to

Bug#1794: bin/sh is shell when none specified in /etc/passwd

1995-11-02 Thread Bruce Perens
[EMAIL PROTECTED] said: > [empty shell fields in /etc/passwd mean /bin/sh] This is common practice, and perhaps important if you are using a Yellow Pages password database that originates on a different system. Use "/dev/null" as the shell if you want to disable the login. Thanks

Bug#1794: /bin/sh is shell when none specified in /etc/passwd

1995-11-02 Thread Ian Jackson
Package: ? I recently created a special-purpose entry in /etc/passwd, with an empty shell field. I was surprised to see that `finger' reported the shell as `/bin/sh', and tried using `su' from a root shell to su to the account. Sure enough, I got a shell. This seems wrong to me, particularly in