Bug#922952: ITP: simdjson -- Parsing gigabytes of JSON per second
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: simdjson Version : git master Upstream Author : Daniel Lemire * URL : https://github.com/lemire/simdjson * License : Apache-2 Programming Lang: C++ Description : Parsing gigabytes of JSON per second Shocking speed improvement in json parsing has been achieved by using the AVX2 instruction set, and haswell (2013) is the lowest requiement of this software. This looks like an excellent candidate software for SIMDebian. Clearly by uploading this package to Debian I'll violate the ISA baseline, but I'll file RC bug by myself... So let's upload it to sid...
Re: Bug#922643: ITP: build-alternative -- helper to build Debian package with diet libc
[2019-02-21 00:00] Guillem Jover > On Mon, 2019-02-18 at 19:37:38 +, Dmitry Bogatov wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Dmitry Bogatov > > > > * Package name : build-alternative > > Version : 0.0.1 > > Upstream Author : Dmitry Bogatov > > * Url : https://salsa.debian.org/kaction/build-alternative > > * Licenses : GPL-3+ > > Programming Lang : shell > > Section : devel > > > > This package provide makefile snippet, that abstract away > > several issues, related to building package with diet libc. > > . > > * diet libc is not supported on every Debian architecture > > * code to check for build profiles is repetive > > . > > Regular users do not need to install this package, it is only > > useful to Debian Contributors. > > Hmm this package name looks extremely generic for what it is described > to be used for. Could you name it something else that includes either > dietlibc in its name or at least libc or similar? I do not exclude, that it may include support for musl for future. I am not sure, whether overly generic name now is worse then misleading source package name in future. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Re: Bug#922643: ITP: build-alternative -- helper to build Debian package with diet libc
On 22.02.19 12:44, Dmitry Bogatov wrote: > > [2019-02-21 00:00] Guillem Jover >> On Mon, 2019-02-18 at 19:37:38 +, Dmitry Bogatov wrote: >>> Package: wnpp >>> Severity: wishlist >>> Owner: Dmitry Bogatov >>> >>> * Package name : build-alternative >>> Version : 0.0.1 >>> Upstream Author : Dmitry Bogatov >>> * Url : https://salsa.debian.org/kaction/build-alternative >>> * Licenses : GPL-3+ >>> Programming Lang : shell >>> Section : devel >>> >>> This package provide makefile snippet, that abstract away >>> several issues, related to building package with diet libc. >>> . >>> * diet libc is not supported on every Debian architecture >>> * code to check for build profiles is repetive >>> . >>> Regular users do not need to install this package, it is only >>> useful to Debian Contributors. >> >> Hmm this package name looks extremely generic for what it is described >> to be used for. Could you name it something else that includes either >> dietlibc in its name or at least libc or similar? > > I do not exclude, that it may include support for musl for future. I am > not sure, whether overly generic name now is worse then misleading > source package name in future. then it's maybe premature to upload that package at all? Anyway, build-alternative is way too generic.
Re: Use of the Build-Conflicts field
So, I've only had a desire to use the build-conflicts field once in my time doing Debian packaging, but that one time it was such the right answer that I was really glad the field is there. I was packaging Moonshot, a GSS-API mechanism based on EAP. It depends heavily on the underlying capabilities of the GSS-API infrastructure, and has autoconf tests to detect what capabilities it needs. There are several gss-api implementations in Debian. The library depends on the one it wants, although you could easily choose for local needs to build against Heimdal rather than MIT if you liked. You shouldn't upload that package to the archive unless we've made a change to what we prefer for Moonshot. But there's one gss implementation that simply won't work: libgss-dev. It's antequated (or at least was) and missing critical features from modern GSS-API. If you try, you'll get obscure errors about missing capabilities. Build-Conflicts provided a way to give a very valid Debian-specific error describing what went wrong if you tried to build a debian package in that environment. Especially when I was doing both NFS and Moonshot builds, it really helped me avoid shooting myselfg in the foot. It also helped others. Unless we're going to go so far as to forbid developers from doing builds outside of chroots, it's useful to express this sort of thing. --Sam
Re: Bug#922643: ITP: build-alternative -- helper to build Debian package with diet libc
Dmitry Bogatov wrote: [2019-02-21 00:00] Guillem Jover On Mon, 2019-02-18 at 19:37:38 +, Dmitry Bogatov wrote: Package: wnpp Severity: wishlist Owner: Dmitry Bogatov * Package name : build-alternative Version : 0.0.1 Upstream Author : Dmitry Bogatov * Url : https://salsa.debian.org/kaction/build-alternative * Licenses : GPL-3+ Programming Lang : shell Section : devel This package provide makefile snippet, that abstract away several issues, related to building package with diet libc. . * diet libc is not supported on every Debian architecture * code to check for build profiles is repetive . Regular users do not need to install this package, it is only useful to Debian Contributors. Hmm this package name looks extremely generic for what it is described to be used for. Could you name it something else that includes either dietlibc in its name or at least libc or similar? I do not exclude, that it may include support for musl for future. I am not sure, whether overly generic name now is worse then misleading source package name in future. Reading the description and the objections, maybe a name like "alternate-libc-build-helpers"? -kgd
Bug#922983: ITP: libmodule-build-using-pkgconfig-perl -- Module::Build extension for using platform libraries provided by pkg-config
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libmodule-build-using-pkgconfig-perl Version : 0.02 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Module-Build-Using-PkgConfig * License : Artistic or GPL-1+ Programming Lang: Perl Description : Module::Build extension for using platform libraries provided by pkg-config Module::Build::Using::PkgConfig is a subclass of Module::Build that provides some handy methods to assist the Build.PL script of XS-based module distributions that make use of platform libraries managed by pkg-config. As well as supporting libraries installed on a platform-wide basis and thus visible to pkg-config itself, this subclass also assists with Alien::-based wrappers of these system libraries, allowing them to be dynamically installed at build time if the platform does not provide them. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Re: Unifying logging by default
On Thu, Feb 21, 2019 at 10:26:36PM +0100, Gabor Gombas wrote: > On Wed, Feb 20, 2019 at 02:44:37PM -0800, Josh Triplett wrote: > > > Both syslog and journald support multi-line log messages; I'd *love* to > > see /var/log/aptitude and /var/log/apt/history.log end up in syslog or > > journald. > > Both journald and syslog have problems with retention policies, Syslog implementations tend to have quite detailed policies and mechanisms what to store where and for how long. I like having a uniform ruleset and routing mechanism for that. Journald certainly has a much simpler approach there, and doesn't allow expiring "some but not all" old entries; I'd love to see that added. But in any case, it does have automatic expiration at a uniform time, and works well for in-memory logging as well. Also, I like that I can effectively say "keep things as long as you can, as long as I have enough disk space". > In a production environment, I want to keep package upgrade history > going back several months or even years - but I want to purge cron job > execution history after a week. I understand that. Would it work well for you if rsyslog's default configuration had a category for these kinds of long-term persistent messages and had a different policy for them by default, so that if you install rsyslog you get all the distinct logfiles you want by default? (That would then allow controlling all system messages with syslog configuration, rather than also having to individually configure services.)
Re: Use of the Build-Conflicts field
Sam Hartman writes ("Re: Use of the Build-Conflicts field"):
> Especially when I was doing both NFS and Moonshot builds, it really
> helped me avoid shooting myselfg in the foot.
> It also helped others.
Right.
Your example seems perfect to me because it demonstrates nicely the
difference between "having this package in your build environment will
cause a different .deb to the one the Debian maintainers would intend
to ship to all of Debian's users" and "it will make things actually go
wrong".
Building a nonstandard .deb is not wrong, it's just nonstandard :-).
We already pretty much insist that builds *for upload* are done in a
very controlled way (ideally on buildds) and that's fine, and good,
and should lead to the standard binaries that we expect.
ISTM that the purpose of Build-Conflicts is not to affect the standard
sbuild-style builds in Debian (which already have a much more
predictable build-dependency resolver), but to (i) assist developers
and users doing ad-hoc builds in less controlled environments
(ii) perhaps also to provide useful info for Debian derivatives.
> Unless we're going to go so far as to forbid developers from doing
> builds outside of chroots, it's useful to express this sort of thing.
Absolutely. I don't think anyone here is really arguing against the
value of Build-Conflicts.
The question Sean asked was whether a lack of an applicable
Build-Conflicts was considered RC; and the answer seems to be that
people think it isn't.
I also expect that subject to the constraint that this won't generate
RC bugs, people will be generally happy to have policy write down
roughly what the criteria are for putting in a Build-Conflicts.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
New GNU/kFreeBSD Porterbox
Hi, We have set up a new GNU/kFreeBSD porterbox, lemon.debian.net[0], kindly hosted by Gurkan Myczko, available to all DDs. The machine is set up to closely mirror many aspects of the standard Debian porterboxes, so you can use the usual dd-schroot-cmd workflow as described on the DSA website[1]. Both kfreebsd-amd64 and kfreebsd-i386 schroots are provided. As with all porterboxes, this machine should be used to debug issues, and not to perform binary uploads to the archive in place of the build daemons. If you have any issues or questions, please feel free to contact me on IRC (#debian-kbsd) or via email. Thanks for your future porting efforts! Regards, James [0] https://db.debian.org/machines.cgi?host=lemon [1] https://dsa.debian.org/doc/schroot/
