Bug#793404: massive waste of CPU time in debian/rules by inline commands
Hideki Yamane: > 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. > > Sorry, but this cannot be done via a compat level. If it could have, I would have done it in compat 12 and moved on. Please see #884999 for the reasons why debhelper cannot change this default for us. Thanks, ~Niels
Bug#918474: ITP: libmojo-ioloop-readwriteprocess-perl - Execute external programs or internal code blocks as separate process
Package: wnpp Owner: Hideki Yamane Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libmojo-ioloop-readwriteprocess-perl Version : 0.23 Upstream Author : Ettore Di Giacinto * URL : https://metacpan.org/release/Mojo-IOLoop-ReadWriteProcess * License : Artistic or GPL-1+ Programming Lang: Perl Description: Execute external programs or internal code blocks as separate process Mojo::IOLoop::ReadWriteProcess is yet another process manager. The package will be maintained under the umbrella of the Debian Perl Group. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Re: DEB_BUILD_OPTIONS vs DEB_BUILD_PROFILES: What is right and what is wrong?
On Sun, Jan 06, 2019 at 02:55:30AM +0100, Axel Beckert wrote: > 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. Yes, it's an oversight. ISTR you have commit rights for lintian, I think you should just commit an s/profile/option/ in that description. > > > 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. The reason for referring to _OPTIONS is that that's the one defined by policy, and what everybody has been accustomed for many years. But josch explained quite a few things already… :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#918513: ITP: soupsieve -- A modern CSS selector implementation for BeautifulSoup
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: soupsieve Version : 1.6.2 Upstream Author : Isaac Muse * URL : https://github.com/facelessuser/soupsieve * License : MIT/Expat Programming Lang: Python Description : A modern CSS selector implementation for BeautifulSoup Soup Sieve is a CSS selector library designed to be used with Beautiful Soup 4 (python-bs4 in Debian). It aims to provide selecting, matching, and filtering using modern CSS selectors. Soup Sieve currently provides selectors from the CSS level 1 specifications up through the latest CSS level 4 drafts (though some are not yet implemented). Soup Sieve was written with the intent to replace Beautiful Soup's builtin select feature, and as of Beautiful Soup version 4.7.0, it now is 🎊. Soup Sieve can also be imported in order to use its API directly for more controlled, specialized parsing.
Re: DEB_BUILD_OPTIONS vs DEB_BUILD_PROFILES: What is right and what is wrong?
Hi Mattia, Mattia Rizzolo wrote: > On Sun, Jan 06, 2019 at 02:55:30AM +0100, Axel Beckert wrote: > > 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. > > Yes, it's an oversight. ISTR you have commit rights for lintian, I > think you should just commit an s/profile/option/ in that description. Thanks! Done now. 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: deduplicating jquery/
On Sat, Jan 05, 2019 at 09:20:34PM +0100, Samuel Thibault wrote: > 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. Similar with doxygen... And then there's "jquery but not really jquery" appearing the wild or stuff which will not work with newer/older jquerys, ttbomk. Short: the JS mess. Regards, Rene
Bug#918523: ITP: appimagelauncher -- Helper application for Linux distributions serving as a kind of "entry point" for running and integrating AppImages
Package: wnpp Severity: wishlist Owner: Scarlett Moore * Package name: appimagelauncher Version : 1.0.0 Upstream Author : TheAssassin * URL : https://github.com/TheAssassin/AppImageLauncher * License : (MIT/X) Programming Lang: (C++) Description : Helper application for Linux distributions serving as a kind of "entry point" for running and integrating AppImages I intend on maintaining this.
Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
[ Please note the cross-post and respect the Reply-To... ] Hi folks, This has taken a while in coming, for which I apologise. There's a lot of work involved in rebuilding the whole Debian archive, and many many hours spent analysing the results. You learn quite a lot, too! :-) I promised way back before DC18 that I'd publish the results of the rebuilds that I'd just started. Here they are, after a few false starts. I've been rebuilding the archive *specifically* to check if we would have any problems building our 32-bit Arm ports (armel and armhf) using 64-bit arm64 hardware. I might have found other issues too, but that was my goal. The logs for all my builds are online at https://www.einval.com/debian/arm/rebuild-logs/ for reference. See in particular https://www.einval.com/debian/arm/rebuild-logs/armel/FAIL/FAIL.html https://www.einval.com/debian/arm/rebuild-logs/armhf/FAIL/FAIL.html for automated analysis of the build logs that I've used as the basis for the stats below. Executive summary = As far as I can see we're basically fine to use arm64 hosts for building armel and armhf, *so long as* those hosts include hardware support for the 32-bit A32 instruction set. As I've mentioned before [1] that's not a given on *all* arm64 machines, but there are sufficient machine types available that I think we should be fine. There are a couple of things we need to do in terms of setup - see "Machine configuration" below. [1] https://lists.debian.org/debian-arm/2018/06/msg00062.html Methodology === I (naïvely) just attempted to rebuild all the source packages in unstable main, at first using pbuilder to control the build process and then later using sbuild instead. I didn't think to check on the stated architectures listed for the source packages, which was a mistake - I would do it differently if redoing this test. That will have contributed quite a large number of failures in the stats below, but I believe I have accounted for them in my analysis. I built lots of packages, using a range of machines in a small build farm at home: * Macchiatobin * Seattle * Synquacer * Multiple Mustangs using my local mirror for improved performance when fetching build-deps etc. I started off with a fixed list of packages that were in unstable when I started each rebuild, for the sake of simplicity. That's one reason why I have two different numbers of source packages attempted for each arch below. If packages failed due to no longer being available, I simply requeued using the latest version in unstable at that point. I then developed a script to scan the logs of failed builds to pick up on patterns that matched with obvious causes. Once that was done, I worked through all the failures to (a) verify those patterns, and (b) identify any other failures. I've classified many of the failures to make sense of the results. I've also scanned the BTS for existing bugs matching my failed builds (and linked to them), or filed new bugs where I could not find matches. I did *not* investigate fully every build failure. For example, where a package has never been built before on armel or armhf and failed here I simply noted that fact. Many of those are probably real bugs, but beyond the scope of my testing. For reference, all my scripts and config are in git at https://git.einval.com/cgi-bin/gitweb.cgi?p=buildd-scripts.git armel results = Total source packages attempted: 28457 Successfully built: 25827 Failed: 2630 Almost half of the failed builds were simply due to the lack of a single desired build dependency (nodejs:armel, 1289). There were a smattering of other notable causes: * 100 log(s) showing build failures (java/javadoc) Java build failures seem particularly opaque (to me!), and in many cases I couldn't ascertain if it was a real build problem or just maven being flaky. :-( * 15 log(s) showing Go 32-bit integer overflow Quite a number of go packages are blindly assuming sizes for 64-bit hosts. That's probably fair, but seems unfortunate. * 8 log(s) showing Sbuild build timeout I was using quite a generous timeout (12h) with sbuild, but still a very small number of packages failed. I'd earlier abandoned pbuilder for sbuild as I could not get it to behave sensibly with timeouts. The stats that matter are the arch-specific failures for armel: * 13 log(s) showing Alignment problem * 5 log(s) showing Segmentation fault * 1 log showing Illegal instruction and the new bugs I filed: * 3 bugs for arch misdetection * 8 bugs for alignment problems * 4 bugs for arch-specific test failures * 3 bugs for arch-specific misc failures Considering the number of package builds here, I think these numbers are basically noise. The vast majority of the failures I found were either already known in the BTS (260), unrelated to what I was looking for, or both. See below for more details about hos
