Bug#1036903: ITP: node-pure-rand -- Fast pseudorandom number generator for Node.js
Package: wnpp Severity: wishlist Owner: Yadd X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: node-pure-rand Version : 6.0.2 Upstream Contact: Nicolas DUBIEN * URL : https://github.com/dubzzz/pure-rand * License : Expat Programming Lang: JavaScript Description : Fast pseudorandom number generator for Node.js node-pure-rand is a fast pseudo random number generator with purity in mind. Pure means that the instance "rng" will never be altered in-place. It can be called again and again and will always return the same value, but it will also return the next "rng". node-pure-rand is a new dependency of jest 29.5. It will be maintained under JS Team umbrella.
Fwd: Dynamic linker support for FPC.
Link loadbalance Registre you free https://www.linkedin.com/in/michel-de-cerqueira-96b20a233 -- Mensagem encaminhada -- De: *Andrey Rakhmatullin* Data: domingo, 28 de maio de 2023 Assunto: Dynamic linker support for FPC. Para: debian-devel@lists.debian.org On Sun, May 28, 2023 at 06:53:51PM +0200, Abou Al Montacir wrote: > One year ago, glibc 2.32 2.32 was released in 2020 though? Unless you mean some Debian-specific changes, happened in 2021, in which case please be more specific? > introduced a change in the dynamic linker removing the functions > calloc/malloc/realloc/free. What do you mean by this?
Re: Bug#932957: Please migrate Release Notes to reStructuredText
Hi, Stéphane Blondon wrote (Sun, 28 May 2023 13:16:24 +0200): > > > Richard Lewis wrote (Fri, 19 May > > 2023 00:58:26 +0100): > > > > > - are the red hyphens in eg the 'deb...' line near the top of > > > > > > https://people.debian.org/~holgerw/release-notes_sphinx/en/html/issues.html > > > > meant to be red? (maybe it is a syntax error?) > > > > > > > Sphinx uses Pygments to highlight source code. I guess no language is > defined so Sphinx uses a wrong lexer. We should force Sphinx to use > 'SourceListLexer' with: > .. code-block :: sources.list The highlighting feature is great, thanks for pointing this out! However, we cannot use it here in most cases for sources.list entries, since resolving substitutions does not work within such lines :-( like in deb https://deb.debian.org/debian |RELEASENAME| main contrib But in many cases the highlighting gives us a great benefit, so I will merge your MR and adapt the rare cases, where it does not work. Thanks again! Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Re: Dynamic linker support for FPC.
On Sun, May 28, 2023 at 08:27:16PM +0200, Ansgar wrote: > I think this entry from the changelog is meant: > > +--- > | 2020-02-15 Florian Weimer > | > | COMMIT: 3a0ecccb599a6b1ad4b149dc569c0080e92d057b > | ld.so: Do not export free/calloc/malloc/realloc functions [BZ > #25486] > +--- > > Which is an incompatible ABI change. ld.so is not a library. For various reasons it technically is a shared object and also can export symbols (which is used to share stuff between glibc and it's interpreter). But it is not a library and you need to properly link with libc.so for any implementation stuff. ld.so contains it's own minimal malloc and friends implementation, which is now incompatible with the one in libc.so itself. In the end this a bug in FPC, which tries to link to ld.so, which is broken. See https://sourceware.org/bugzilla/show_bug.cgi?id=25486 for the glory details. And also there is no way to do a transition for it without moving every binary built on Debian on a private ABI. Bastian -- Killing is stupid; useless! -- McCoy, "A Private Little War", stardate 4211.8
Re: 64-bit time_t transition for 32-bit archs: a proposal
Hi Steve, On Wed, May 17, 2023 at 10:39:21PM -0700, Steve Langasek wrote: > > I note that this may pose problems with intra-library interaction. Say > > we need to enable time64 on a higher level library and a lower level > > library does not use time_t, but uses off_t. As such, you'd opt out of > > lfs on the lower level library, but the upper one uses it with lfs by > > having enabled time64. How do you intend to deal with such cases? > > In such a case the lower-level library should opt in to lfs and have a > package name change as well. Up to this point I've casually assumed there > weren't any such packages, but this can also be detected via static analysis > of the archive. Did you encounter such cases in your updated analysis? > > Something that would help with this transition would be a > > checker-as-a-service kind of thing that indicates: > > * Is my package affected by time64? > > * Does my package enable time64? > >+ On i386? > > * Do time64 changes affect downstream packages? > >+ Which? > > > I understand that answering these questions on a per-package basis is > > far from trivial. That much is evident from your analysis. I think this > > is ok. Even if such a service says "unknown" 10% of the time, that'd > > still be very useful. Do you think you could turn your analysis into a > > continuous checking service? > > This sounds like a substantial amount of work (and computing resources, to > enable this to "continuously" check) and I don't think I understand how it > would help the transition, if all of the library transitions are being > coordinated centrally. Could you elaborate? I'm not sure how this would look like exactly. I see some options: + The lists that already exist describe the second level of affectedness (changes ABI) already. + A double-rebuild varying time64 could employ reproducible builds to judge affectedness (generally) and we would get a list of unaffected packages in particular. + If we enable this via dpkg, .buildinfo files can be used to track how many packages have been rebuilt with time64 (given that ben will not always see a difference). + Finally the benfile you proposed may also help to judge this. I don't yet quite see how this transition can accurately be tracked using ben, but I'm hoping for a positive surprise here. Failing that, fusing some of these information sources into a continously updated view would improve our understanding of how far this went. I agree that the amount of work to spend on such tracking needs to be balanced. In effect, we practically do want to rebuild much of the archive here and while some of that will cause dependency changes, there are enough examples that will be invisible to ben to justify a bit more tracking effort here in my view. I hope you can agree with this view. Helmut
Re: Dynamic linker support for FPC.
On Sun, 2023-05-28 at 20:23 +0200, Andrey Rakhmatullin wrote: > On Sun, May 28, 2023 at 06:53:51PM +0200, Abou Al Montacir wrote: > > One year ago, glibc 2.32 > 2.32 was released in 2020 though? Unless you mean some Debian-specific > changes, happened in 2021, in which case please be more specific? > > > introduced a change in the dynamic linker removing the functions > > calloc/malloc/realloc/free. > What do you mean by this? I think this entry from the changelog is meant: +--- | 2020-02-15 Florian Weimer | | COMMIT: 3a0ecccb599a6b1ad4b149dc569c0080e92d057b | ld.so: Do not export free/calloc/malloc/realloc functions [BZ #25486] +--- Which is an incompatible ABI change. Ansgar
Re: Dynamic linker support for FPC.
On Sun, May 28, 2023 at 06:53:51PM +0200, Abou Al Montacir wrote: > One year ago, glibc 2.32 2.32 was released in 2020 though? Unless you mean some Debian-specific changes, happened in 2021, in which case please be more specific? > introduced a change in the dynamic linker removing the functions > calloc/malloc/realloc/free. What do you mean by this?
Dynamic linker support for FPC.
Dear All, One year ago, glibc 2.32 introduced a change in the dynamic linker removing the functions calloc/malloc/realloc/free. This was motivated by the fact that libC is always in the way and provides these functions. However, this is not always true, because other compilers, FPC for instance, does not require libC for its generated programs. This resulted in all programs that use FPC and need to deal with SOL to link with libC, or fail to start. Of course, this may be an acceptable workaround for now, but there are case, where one don't want to link with libC and thus will fail to run in Debian. Is it possible to get this change reverted, or to have a way to workaround it? -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Re: Bug#932957: Please migrate Release Notes to reStructuredText
> > Richard Lewis wrote (Fri, 19 May > 2023 00:58:26 +0100): > > > - are the red hyphens in eg the 'deb...' line near the top of > > > > https://people.debian.org/~holgerw/release-notes_sphinx/en/html/issues.html > > > meant to be red? (maybe it is a syntax error?) > > Sphinx uses Pygments to highlight source code. I guess no language is defined so Sphinx uses a wrong lexer. We should force Sphinx to use 'SourceListLexer' with: .. code-block :: sources.list
Bug#1036863: ITP: perlnavigator -- language server (LSP) for Perl
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Javascript Maintainers , Debian Perl Group -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: perlnavigator Version : 0.5.5 Upstream Contact: bscan * URL : https://github.com/bscan/PerlNavigator * License : Expat Programming Lang: JavaScript, Perl Description : language server (LSP) for Perl Perl Navigator Language Server provides syntax checking, autocompletion, perlcritic, code navigation and hover for Perl. . Implemented as a Language Server in NodeJS using the Microsoft LSP libraries along with Perl doing the syntax checking and parsing. This package will be maintained collaboratively in the JavaScript team (since build framework is NodeJS), but with conventional "node-" prefix only in provided virtual package name as it is mainly an application. Cc'ing Perl team since its use relates there. It will be maintained at Salsa, here: https://salsa.debian.org/js-team/perlnavigator -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmRy+yAACgkQLHwxRsGg ASGsmhAAiDJ/2pYjjJhsUPly4nl3vracp7pIECwiq+mhVoHqbjyQc54BFm+kSznn ijDmdbpYWcSMkW5esQkAwNj6c6DFLQqDgVcDSHSPr6NJrh0yLMSBg5uveXsO11Aj a3N/uHt6Iq9m1yppS2B/yqffWfqFCn6CAWHV7Kfb+LIDniczExA0Kq5Gpk+v+/Y+ /gYj+qP0Y6dLrRt/DGVbH2dPuWiQb89EBShha3VZHE106REr4Xin5sqm0LRWvk3O TcDg/3bq1xkYcyMX3pi/mXiue1ewF2Udi3sKlHbH3NWwMF8S0TAzaNlF6ZhmKJlJ w+nRXGp83EqOrrsWRxhDh7pfWE2+y0p6PM+03Iq8eH9JDFRx8+dgUoOG6fUF6un1 Oa+i6uqCt15HHkENlf/iH8ChsIQxgaUM664AGe2MyqhTLIkaYX3VJd8WaptZ+x1h eODF4VZaS/27V4gaBMKiHnr+ugEVXQWQsxv6QmzmxedNAXdY6aeqEDFkL0PhBdL8 Fn4C3kG+I2mPnxa/GhFu/D1i/k1Xw+HLc+sDu02zBYzvxKOn3HddUvyr5UFjqN8s 7r6nPYGSbpAJs5dqYZvWPCUhqsrFmi3BGkVa6ZoFjrBln6VBWguhrGFWBmw+uZL8 hBbPgci53rA3jEgdZ8Pj/RgpExHCCBivKeYp1/sl0XrClKcQGJU= =hcck -END PGP SIGNATURE-
