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. R
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
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
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 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
❦ 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
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: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
]] 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
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
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
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
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
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
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
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 '
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
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
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
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
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
[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
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
27 matches
Mail list logo