Re: Proposed build profile: noinsttests
On Thu, 05 Sep 2019 at 06:30:34 +0200, Guillem Jover wrote: > «noinstcheck» would also map equally to autotools «make installcheck», > in the same way «nocheck» maps to «make check». To me, "check" would imply actively checking something - most likely by *running* the tests - rather than merely building/installing some test-cases so that we can run them (use them to check the package) later. If anything, I would expect a noinstcheck profile to be about whether to run `make installcheck DESTDIR=$(CURDIR)/debian/tmp`, or other build systems' equivalents if they have one, during build (but in practice we don't do that anyway). GNOME-style installed-tests are not quite the same thing as Autotools `make installcheck`: they have similar goals (improving test coverage of the installed code), but different constraints. GNOME-style installed-tests test the package under more realistic conditions, so they are less prone to false positives and false negatives than either `make check` or `make installcheck`. The price they pay for that is that to set up those more realistic conditions, they require the package under test to be "properly installed" in its final location, and for example cannot be run within the constraints we place on buildds. In Debian terms, `make check` has to happen during build, GNOME-style installed-tests have to be an autopkgtest, and `make installcheck` could be used for either. A few packages like dbus do use the same code for installed-tests and installcheck, but it takes additional effort to make the same tests work for both (similar to the additional effort needed to make a build-time test usable as an installed test). installcheck has access to the built source tree (like autopkgtest with the needs-build restriction), but needs to cope with the installed package having been installed to a DESTDIR rather than to its final location (so for example it needs to set LD_LIBRARY_PATH to pick up any newly-installed libraries - which can prevent genuine bugs from being noticed). smcv
Re: Proposed build profile: noinsttests
On Thu, 05 Sep 2019 at 07:19:30 +0200, Johannes Schauer wrote: > I agree that it can be confusing but I think it is just as confusing as any > other doubly negated boolean expression. It usually helps me to draw the truth > table when I'm unsure. Your example of is probably not > what you meant to express because then the source package would still build > depend on libglib2.0-dev unless *both* profiles are active. That's actually what I want. A `make check` with full test coverage runs tests that require GLib, for which we obviously need to build those tests first. Building the dbus-tests package requires building (but not necessarily running) those same tests, so that we can copy them into debian/tmp. Either way, we need GLib. So the truth table I want is that dbus build-depends on: | !noinsttests| noinsttests | ---+-+-+ !nocheck | libglib2.0-dev | libglib2.0-dev | (so we can build the tests we will run) ---+-+-+ nocheck | libglib2.0-dev | (nothing) | ---+-+-+ (so we can build the tests we will install) > While we are talking about splitting up packages and thus increasing the size > of our Packages file, let me also point out, that estimating where it makes > sense to split a binary package into two for the sake of cutting dependency > cycles very often not obvious and that splits of existing packages for the > sake > of better bootstrappability should probably not happen without a bootstrapper > having claimed that a given package causes problems as it is. Sure, I'm not saying that maintainers of a libfoo-bin package containing both "useful binaries to depend on" and examples or installed-tests (like librsvg2bin in buster) should split it just because this profile exists. (However, if the examples or installed-tests are large or have significantly "heavier" dependencies, then the package should probably be split anyway.) smcv
Bug#939680: ITP: golang-github-disintegration-gift -- Go Image Filtering Toolkit
Package: wnpp Severity: wishlist Owner: Dr. Tobias Quathamer * Package name: golang-github-disintegration-gift Version : 1.2.1-1 Upstream Author : Grigory Dryapak * URL : https://github.com/disintegration/gift * License : Expat Programming Lang: Go Description : Go Image Filtering Toolkit Package gift provides a set of useful image processing filters. This package is a dependency for the new upstream version of hugo. Regards, Tobias signature.asc Description: OpenPGP digital signature
EQUITY FUNDING
Hello Hope your business is prospering 2019 we are one of the big funding services in Singapore,We operate a project credit financing program. We finance all international business people and project owners who are interested in a business partnership and finance your projects,We always provide highy and equity funding for start up projects Please contact us, we look forward to providing you with the services required and to discuss further business with you Thanks & Regards, Diana Rowe
BUSINESS PARTNERSHIP REQUEST
TO THE MANAGING DIRECTOR/CHIEF EXECUTIVE OFFICER Hello Sir/madam I want to notify you of my client's interest to invest in your company as a SILENT /ANGEL INVESTOR Please if you wish to proceed get back to me on my email as soon as possible for contact details and further proceeding Thanks william caldwell Investment advert Agent (megabills uk)
Bug#939689: ITP: golang-github-maruel-panicparse -- Crash your app in style (Golang)
Package: wnpp Severity: wishlist Owner: Dr. Tobias Quathamer * Package name: golang-github-maruel-panicparse Version : 1.3.0-1 Upstream Author : Marc-Antoine Ruel * URL : https://github.com/maruel/panicparse * License : Apache-2.0 Programming Lang: Go Description : Crash your app in style (Golang) Parses panic stack traces, densifies and deduplicates goroutines with similar stack traces. Helps debugging crashes and deadlocks in heavily parallelized processes. This package is a dependency of the new upstream version of syncthing. Regards, Tobias signature.asc Description: OpenPGP digital signature
