Bug#918448: ITP: jitterdebugger -- Real time response measurement tool
Package: wnpp Severity: wishlist Owner: SZ Lin (林上智) X-Debbugs-CC: debian-devel@lists.debian.org * Package name: jitterdebugger Version : 0.1 Upstream Author : Daniel Wagner * URL : https://github.com/igaw/jitterdebugger * License : Expat Programming Lang: C, Python Description: Real-time response measurement tool jitterdebugger measures wake up latencies and able to store all samples for post-processing. . This tool is a reimplementation of cyclictest. It doesn't have all the command line options as cyclictest which results are easy to get wrong and therefore an invalid latency report. . jitterdebugger is under Expat license. -- SZ Lin (林上智) , http://people.debian.org/~szlin Debian Developer 4096R/ 178F 8338 B314 01E3 04FC 44BA A959 B38A 9561 F3F9
Bug#793404: massive waste of CPU time in debian/rules by inline commands
Hi Niels, Thanks for your explanation :) On Sat, 05 Jan 2019 09:52:00 + Niels Thykier wrote: > We are very far from being able to flip the default. There are some > 800+ packages that need to be updated to follow latest policy > requirements plus explicitly declare their need for (fake)root. Okay, maybe we can achieve it as compat level 13, 14 or 15... but lg way to go, I agree with it. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Re: DEB_BUILD_OPTIONS vs DEB_BUILD_PROFILES: What is right and what is wrong?
Hi Johannes, thanks for the quick response. Johannes Schauer wrote: > > A) lintian by mixing up build tags and build profiles? (Maybe this > >mentioning of build profiles was overseen when fixing #889746.) > > I assume this to be the case. Would be happy to hear, if Mattia sees this the same way. > > B) dpkg-buildpackages by not setting nocheck in DEB_BUILD_OPTIONS? > > This could be brought to the dpkg maintainers. Guillem? (If you need the full context: https://lists.debian.org/debian-devel/2019/01/msg00039.html) > > If I want to build something with the build-profile nocheck, do I > > really have to set DEB_BUILD_OPTIONS myself separately to "nocheck" in > > addition to "-Pnocheck"? That sounds very counterintuitive to me… > > I fear you currently have to manually set DEB_BUILD_OPTIONS=nocheck in > addition > to -Pnocheck. The reason is, that currently no tool sets > DEB_BUILD_OPTIONS=nocheck if the nocheck build profile is active. This could > be > changed in the future but I know of no such efforts right now. Ok, this is really not what I expected to be the case, especially after #889746. > Also refer to the current documentation of the nocheck build profile under > [1]. > It says: > > > No test suite should be run, and build dependencies used only for that > > purpose should be ignored. Builds that set this profile must also add > > nocheck > > to DEB_BUILD_OPTIONS […] > [1] https://wiki.debian.org/BuildProfileSpec Thanks for that pointer! > The only alternative I see that would make this more convenient, would be if > we > rewrite all affected d/rules file to check DEB_BUILD_OPTIONS *and* > DEB_BUILD_PROFILES when deciding whether or not to run the test > suite. This is actually what I just implemented for the package with which I ran into that issue: override_dh_auto_test: ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS) $(DEB_BUILD_PROFILES))) […] > You already discovered that this would be *a lot* of them. *nod* So if this should be made easier, it's probably at dpkg-buildpackage or close-by. > There is a similar issue with the nodoc build profile where one must also > currently manually supply DEB_BUILD_OPTIONS=nodoc additionally. That was quiet likely, yes: different color, same issue. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Re: DEB_BUILD_OPTIONS vs DEB_BUILD_PROFILES: What is right and what is wrong?
Hi, Quoting Axel Beckert (2019-01-06 01:39:09) > while trying to get the nocheck build profile working, I stumbled over > some discrepancies between > > * Debian Policy §4.9.1, > * dpkg-buildflags (behaviour + man page), and > * lintian's long description of the tag > override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS. > > [...] > > So now I wonder: what is wrong and needs to be fixed? > > A) lintian by mixing up build tags and build profiles? (Maybe this >mentioning of build profiles was overseen when fixing #889746.) I assume this to be the case. > B) dpkg-buildpackages by not setting nocheck in DEB_BUILD_OPTIONS? This could be brought to the dpkg maintainers. > C) debian-policy (and #889746 + lintian as a followup issue) by >documenting DEB_BUILD_OPTIONS and DEB_BUILD_PROFILES both mixed >under DEB_BUILD_OPTIONS? > D) Something completely different like dh or so? > > Or am I just missing something totally essential and don't see the > forest for the trees? > > And a more general question, especially in case A: > > If I want to build something with the build-profile nocheck, do I > really have to set DEB_BUILD_OPTIONS myself separately to "nocheck" in > addition to "-Pnocheck"? That sounds very counterintuitive to me… I fear you currently have to manually set DEB_BUILD_OPTIONS=nocheck in addition to -Pnocheck. The reason is, that currently no tool sets DEB_BUILD_OPTIONS=nocheck if the nocheck build profile is active. This could be changed in the future but I know of no such efforts right now. Also refer to the current documentation of the nocheck build profile under [1]. It says: > No test suite should be run, and build dependencies used only for that > purpose should be ignored. Builds that set this profile must also add nocheck > to DEB_BUILD_OPTIONS The only alternative I see that would make this more convenient, would be if we rewrite all affected d/rules file to check DEB_BUILD_OPTIONS *and* DEB_BUILD_PROFILES when deciding whether or not to run the test suite. You already discovered that this would be *a lot* of them. There is a similar issue with the nodoc build profile where one must also currently manually supply DEB_BUILD_OPTIONS=nodoc additionally. Thanks! cheers, josch [1] https://wiki.debian.org/BuildProfileSpec signature.asc Description: signature
Partnership proposal
-- Hi, Located in the united kingdom, the famous brand John Lewis PLC, is UK's largest multi-channel retailer with over 45 shops furnished by European products. We are looking for new products to attract new customers and also retain our existing ones, create new partnerships with companies dealing with different kinds of goods. Please send us your catalog through email to speed up and to learn more about your company's products and wholesale quote. We hope to be able to order with you and start long-term friendly, respectable and solid business partnership. We count on the reliability for both sides. We commit ourselves to a successful and professional processing for a good cooperation in all ranges. Could you also send to us all information required to become one of your regular distributors in Europe and worldwide? Please, we would appreciate if you could send us your stock availability via email. We will also pleased to receive any offers or proposals from other product available and ready (Stocks and rates). Payment: Our Payment Terms is within 15 days net in Europe and 30 days net in UK as we operate with all our suppliers. Best Regards, PATRICK LEWIS PURCHASING DIRECTOR PURCHASING DEPARTMENT customer service: 08006112981 Directline: +44 (0) 7417446994 Fax : +44 020 7629 7711 www.johnlewis.com Registered in England and Wales Registered No: 0233462 - VAT No : GB 232457280 This e-mail is confidential and intended only for the addresses shown. If you are not an intended recipient, please be advised that any use, dissemination, forwarding or copying of this e-mail is strictly prohibited. Internet e-mails are not necessarily secure and John Lewis Plc Uk does not accept responsibility for changes made to this message after it was sent. Please note that incoming and outgoing electronic mail messages may be monitored. Should you receive this transmission in error, notify the sender immediately.
DEB_BUILD_OPTIONS vs DEB_BUILD_PROFILES: What is right and what is wrong?
Hi, while trying to get the nocheck build profile working, I stumbled over some discrepancies between * Debian Policy §4.9.1, * dpkg-buildflags (behaviour + man page), and * lintian's long description of the tag override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS. lintian recommends, e.g. at https://lintian.debian.org/tags/override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS.html: > The debian/rules file for this package has an override_dh_auto_test > target that does not appear to check DEB_BUILD_OPTIONS against > nocheck. > > As this check is not automatically performed by debhelper(1), the > specified testsuite is run regardless of another maintainer using the > nocheck build profile. > > Please add a check such as: > > override_dh_auto_test: > ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) > ./run-upstream-testsuite > endif Please note that lintian explicitly mentions the "nocheck build _profile_". (Emphasis is mine.) The Debian Policy says at §4.9.1 respectively at https://www.debian.org/doc/debian-policy/ch-source.html#debian-rules-and-deb-build-options: > 4.9.1. debian/rules and DEB_BUILD_OPTIONS > > Supporting the standardized environment variable DEB_BUILD_OPTIONS is > recommended. This variable can contain several flags to change how a > package is compiled and built. Each flag must be in the form flag or > flag=options. If multiple flags are given, they must be separated by > whitespace. [14] flag must start with a lowercase letter (a-z) and > consist only of lowercase letters, numbers (0-9), and the characters - > and _ (hyphen and underscore). options must not contain whitespace. > The same tag should not be given multiple times with conflicting > values. Package maintainers may assume that DEB_BUILD_OPTIONS will not > contain conflicting tags. > > The meaning of the following tags has been standardized: > > nocheck > > This tag says to not run any build-time test suite provided by the package. Please note that the Debian Policy talks about "tags" and not about "profiles". And dpkg-buildpackage(1) says: > -P, --build-profiles=profile[,...] > >Specify the profile(s) we build, as a comma-separated >list (since dpkg 1.17.2, long option since dpkg 1.18.8). >The default behavior is to build for no specific >profile. Also sets them (as a space separated list) as >the DEB_BUILD_PROFILES environment variable which >allows, for example, debian/rules files to use this >information for conditional builds. DEB_BUILD_OPTIONS is primarily (if not only) mentioned for parallel building: > -j, --jobs[=jobs|auto] > >[…] Also adds parallel=jobs or parallel to the >DEB_BUILD_OPTIONS environment variable which allows >debian/rules files to use this information for their own >purposes. […] So if I now use the code recommended by lintian to check for the nocheck build _profile_ and build with "dpkg-buildpackage -Pnocheck", my build fails, because DEB_BUILD_OPTIONS (as used by Lintian and documented in the Debian Policy at 4.9.1) does _not_ contain "nocheck" but just some "parallel=" as documented by dpkg-buildpackage(1). But the build profile name can be found in DEB_BUILD_PROFILES as documented by dpkg-buildpackage(1). To make easier to understand where my problem lays, here's a (more or less real-world) example: Given this code in debian/rules: > override_dh_auto_test: > ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) > echo "$(DEB_BUILD_OPTIONS)" > echo "$(DEB_BUILD_PROFILES)" > exit 2 > endif The first two lines and the last line are copy and paste from the mentioned lintian tag's long description. If I now build this package with "dpkg-buildpackage -Pnocheck", it should IMHO build fine without running the tests, but it fails as follows: > debian/rules override_dh_auto_test > make[1]: Entering directory '/home/abe//' > echo "parallel=4" > parallel=4 > echo "nocheck" > nocheck > exit 2 > make[1]: *** [debian/rules:50: override_dh_auto_test] Error 2 > make[1]: Leaving directory '/home/abe//' > make: *** [debian/rules:24: binary] Error 2 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 Please note that nocheck and parallel=4 are not echoed by the same echo statement, i.e. are in separate DEB_BUILD_* variables. So my first guess was that lintian's documentation and tag name was wrong and that DEB_BUILD_PROFILES should have been meant. That would affect 1135 source packages: https://codesearch.debian.net/search?q=nocheck%2C%5C%24%5C%28DEB_BUILD_OPTIONS%5C%29 Ugh. (65 are using DEB_BUILD_PROFILES instead.) But then I found https://bugs.debian.org/889746 which exactly demanded earlier this year the opposite of what I had in my mind to fix this: to rename override_dh_auto_test-does-not-check-DEB_BUILD_PROFILES to override_dh_auto_test-does-not-check-DEB_BUILD_OPTI
Re: deduplicating jquery/
Sean Whitton, le sam. 05 janv. 2019 19:48:35 +, a ecrit: > Forgive my ignorance of the specifics of this package, but why can't you > add symlinks to the files shipped by libjs-jquery? That is the standard > solution. openjdk's javadoc not only includes libjs-query, but also jszip, jszip-utils, some images, etc. It'd be better to have a central provider for whatever javadoc needs to have its search functionality working, rather than each package maintainers doing it. Samuel
Re: deduplicating jquery/
Hello Samuel, On Fri 04 Jan 2019 at 08:16pm +0100, Samuel Thibault wrote: > Quite a few packages have jquery/ embedded in documentation generated by > javadoc. This yields to > > « > libfoo-java shares 1.2 MB of similar files with package > liblizzie-java-doc, please investigate whether it is possible to reduce > the duplication. > » > > e.g. most of the libbrlapi-java size comes from it, and > liblucene3-java-doc contains a couple dozens copies. > > Could openjdk perhaps build a package that would ship jquery/ in a known > place, and packages would just depend on it and the generated jquery/ > directory be replaced with a symlink to the known place? Forgive my ignorance of the specifics of this package, but why can't you add symlinks to the files shipped by libjs-jquery? That is the standard solution. -- Sean Whitton signature.asc Description: PGP signature
Bug#793404: massive waste of CPU time in debian/rules by inline commands
Hideki Yamane: > Hi, > > On Thu, 03 Jan 2019 11:11:00 + > Niels Thykier wrote: >> * Migrating to "Rules-Requires-Root: no" where possible. > > Is there any plan to set "Rules-Requires-Root: no" for default? > It seems that most of the packages doesn't require root privilege > to be built, so "default no" is better to reduce work, IMHO. > > Hi, I would love to make "Rules-Requires-Root: no" the default and I agree with you that it is a better default, but I have no plans to drag/spearhead this effort. We are very far from being able to flip the default. There are some 800+ packages that need to be updated to follow latest policy requirements plus explicitly declare their need for (fake)root. Known blockers include: * https://lintian.debian.org/tags/debian-rules-missing-recommended-target.html * https://lintian.debian.org/tags/should-specify-rules-requires-root.html ... and my understanding is that it will require NMU'ing a large amount of these 800 packages of the lot to get there (the build-arch|build-indep transition has been going on for years and will probably take 5-8 more years to completely finish if left on its own). I ran out of gas on finishing build-arch+build-indep, so I am not really feeling up for dragging that to the goal line. I have been doing an NMU here and there plus added MR requests on salsa for setting "R³: binary-targets" to fix a few up them but this the level I can motivate myself to do. In case, you are wondering why build-arch/build-indep is related to this problem: One of the reasons why Rules-Requires-Root can reduce the number of debian/rules runs is because we 1) disable dpkg's probing for build-arch and 2) we just call the binary target directly and let the debian/rules file handle that gracefully. Maybe older packages do not do this and just fail to build properly (despite the policy requirement that mandates otherwise) - among other dh before compat 9 (or 10?) does not handle dependencies between rules targets correctly either. In summary: I do not think we can flip the default before those two lintian tags are close to zero and I am not up for that challenge (but I hope someone is). Thanks, ~Niels
Bug#793404: massive waste of CPU time in debian/rules by inline commands
Hi, On Thu, 03 Jan 2019 11:11:00 + Niels Thykier wrote: > * Migrating to "Rules-Requires-Root: no" where possible. Is there any plan to set "Rules-Requires-Root: no" for default? It seems that most of the packages doesn't require root privilege to be built, so "default no" is better to reduce work, IMHO. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
