Bug#1072724: RFH: ejabberd -- extensible realtime platform (XMPP server + MQTT broker + SIP service)
Package: wnpp Severity: normal X-Debbugs-Cc: ejabb...@packages.debian.org, debian-devel@lists.debian.org Control: affects -1 + src:ejabberd I request assistance with maintaining the ejabberd package. The package description is: ejabberd is a Jabber/XMPP + MQTT + SIP server written in Erlang, featuring: * distributed operation with load-balancing across a cluster; * fault-tolerant database replication and storage on multiple nodes, allowing nodes to be added or replaced "on the fly"; * virtual hosting (several virtual domains can be served using a single ejabberd instance); * XMPP compliance; * MQTT 5 compliance; * SIP service; * web-based administration; * SSL/TLS support; * conferencing via Multi-User Chat; * Jabber Users Directory, based on users' vCards; * service discovery; * shared roster. This package is NOT standalone, currently the set of packages to be maintained consists of 34 source packages. Check https://tracker.debian.org/teams/ejabberd-packaging-team/ for an up2date list. The packages are officially team maintained, but in reality I am the only active maintainer. Upstream is very supportive though! The packages are in good shape as I have a lot of the grunt work automated, but they still require more time than I can offer to stay current and well-cared for. In order to be able to help out effectively, you would need to be at least a Debian Maintainter, so I can trust you with updating and uploading packages. Regards Philipp Huebner
Re: Mandatory LC_ALL=C.UTF-8 during package building
On Thu, Jun 06, 2024 at 07:11:46PM +0200, Michael Biebl wrote: > I would prefer that dpkg-buildpackage provides a "sane" build environment by > default (which I think includes a LC_ setting pointing at a .UTF-8 locale) > and fewer packages explicitly setting those things via debian/rules. same here. like the rest of the world does in 2024. > Afaics, this would actually make efforts like reproducible builds *easier* > as settings provided by reproducible-builds wouldn't be overwritten by > debian/rules. it would make a lot of things easier. :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ No matter how many mistakes you make or how slow you progress, you are still way ahead of everyone who isn't trying. signature.asc Description: PGP signature
Bug#1072738: ITP: manif -- Lie theory library for state estimation
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: manif Version : 0.0.4 Upstream Author : Jeremie Deray * URL : https://github.com/artivis/manif * License : BSD-2-clause, CC0, Expat Programming Lang: Python, C++ Description : Lie theory library for state estimation manif is a Lie theory library for state estimation targeted at robotics applications. It is developed as a header-only C++11 library with Python 3 wrappers. The package will be team-maintained under the umbrella of the Debian Robotics Team at https://salsa.debian.org/robotics-team/manif -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZi2G8ACgkQzIxr3RQD 9MoEjQ//YlC8VOUto9V5su74dvEwivEoEDv8no2ZtcLvbMRA8dQVU7BwkEYjlyUf EHS9slB3U8etfi5LMPfjVNGsfVwrY9650ULOkf/zTkzPebIjWCx3ufLMRNfdA3MC HQE+k4ihk2jemFv7DHrUe8zuGbaN0Ka9g16xWpU/MakN0x6bUB2dWseVdFS63ldP H74wqVLFKq/91Ka9LkAB/g0mLKy5UOuMNDpuVeJ6wL4nQkNhPi2j0JKAJDjvvCXf /OO+LYmSBdhMQZqak7jf1pxhZXeP/eDQHOs3K2enZ08/A0/DX+BBgQeCgFG7fLcG rTpAfJ1Pxds6EkCuLhMj4x68MAb/R0lvJXo5XozizOQ3RGxGeVDd0B3SZT+RF1Ef ZZjdHdYq/wQCE8MnWy3OEmGj+5e0yh77l7f8lOss/T6jvUyyBEDQLcuZ5BKSoGCf bGOHqIzRAULy3EkcZBU3iJ2VIRDuzsA0DPIomIYmcA5npbWIcTT7TGEKjz+EFM5q WrLGvrqugY1hYFx7thP+Sp3IMraktbNDQedIvxfZLaI17bEVBWJITwsScurK7Ife r7YQvDp/YIhz3KPS6TFzbSSL4bHGOBtgos6FKictrFMDLCgaDlnxpXOUtg/8IMps ImvQ61/V10dR0yltO+DeCg7gRt+F+8a91XrQG2fuGn6LMzAf/Ag= =ydle -END PGP SIGNATURE-
Re: Mandatory LC_ALL=C.UTF-8 during package building
Hi! On Thu, 2024-06-06 at 15:31:55 +0100, Simon McVittie wrote: > On Thu, 06 Jun 2024 at 13:32:27 +0300, Hakan Bayındır wrote: > > C, or C.UTF-8 is not a universal locale which works > > for all. > > Sure, and I don't think anyone is arguing that you or anyone else should > set the locale for your interactive terminal session, your GUI desktop > environment, or even your servers to C.UTF-8. > > But, this thread is about build environments for our packages, not about > runtime environments. We have two-and-a-half possible policies: > 1. Status quo, in theory: > >Packages cannot make any assumptions about build-time locales. > >The benefits are: > >- Diagnostic messages are in the maintainer's local language, and > potentially easier to understand. I think this is way more important than the relative space used to mention it though. :) I'm a non-native speaker, who has been involved in l10n for a long time, while at the same time I've pretty much always run my systems with either LANG=C.UTF-8 or before that LANG=C, LC_CTYPE=ca_ES.UTF-8 and LC_COLLATE=ca_ES.UTF-8. And I think forcing a locale on buildds makes perfect sense, because we want easy access to build logs. But forcing LC_ALL from the build tools implies that no tool invoked will get translated messages at all, and means that users (not just maintainers) might have a harder time understanding what's going on, we make lots of l10n work rather pointless, and if no one is running with different locales then l10n bugs might easily creep in. >- If a mass-QA effort wants to assess whether the program is broken by > a particular locale, they can easily try running its build-time tests > in that locale, **if** the tests do not already force a different > locale. (But this comes with some serious limitations: it's likely > to have a significant number of false-positive situations where the > program is actually working perfectly but the **tests** make assumptions > that are not true in all locales, and as a result many upstream > projects set their build-time tests to force specific locales > anyway - often C, en_US.UTF-8 or C.UTF-8 - regardless of what we > might prefer in Debian.) I consider locale sensitive misbehavior as a category of "upstream" bugs (be that in the package upstream or the native Debian tools), that deserve to be spotted and fixed. I can understand though the sentiment of wanting to shrug this problem category off and wanting instead to sweep it under the carpet, but that has accessibility consequences. > The costs are: > - […] but if I'm expected to diagnose the > problem by reading Chinese error messages, as a non-Chinese-speaker I > am not going to get far.) Just as an aside, but while getting non-English messages makes for harder to diagnose bugs, I've never found it a big deal to deal with that kind of bug reports, as you can grep for (parts of) the translated message, and then get the original English string from the .po for example, or can translate the text back to know what it is talking about, or ask the reported to translate it for you. > 2½. Unwelcome compromise (increasingly the status quo): > >Whenever a package is non-reproducible, fails to build or fails tests >in certain locales (for example legacy non-UTF-8 locales like C or >en_GB.ISO-8859-15), we add `export LC_ALL=C.UTF-8` to debian/rules and >move on. > >This is just (2.) with extra steps, and has the same benefit and cost >for the affected packages as (2.) plus an additional cost (someone must >identify that the package is in this category and copy/paste the extra >line), and the same benefit and costs for unmodified packages as (1.). I agree though, that if we end up with every debian/rules unconditionally exporting LC_ALL, then there's not much point in not making the build driver do it instead. Related to this, dpkg-buildpackage 1.20.0 gained a --sanitize-env, which for now on Debian and derivatives sets LC_COLLATE=C.UTF-8 and umask=0022. But _iff_ we end up with dpkg-buildpackage being declared the only supported entry point, _and_ there is consensus that we'd want to set some kind of locale variable from the build driver, then I guess this could be done as a Debian vendor-specific thing, or via the dpkg-build-api(7) interface. Thanks, Guillem
Bug#1072745: ITP: gophian -- tools to help with Debianzing Go software
Package: wnpp Severity: wishlist Owner: Maytham Alsudany X-Debbugs-CC: debian...@lists.debian.org, debian-devel@lists.debian.org * Package name: gophian Version : 0.1.0 Upstream Contact: Maytham Alsudany * URL : https://codeberg.org/Maytha8/gophian * License : GPL-3+ Programming Lang: Python Description : tools to help with Debianzing Go software Gophian is a featureful and intelligent tool to assist developers in packaging Go software for the Debian distribution. . The currently recommended dh-make-golang tool is known to be unreliable and relies on various outdated and deprecated libraries to function. gophian seeks to change that, by replicating the functionality of "go get" in Python, and providing something that works out of the box, as well as adding on more features and more intelligence to improve the Go packaging experience. Will need a sponsor to upload to NEW. -- Kind regards, Maytham Alsudany signature.asc Description: This is a digitally signed message part
Re: Mandatory LC_ALL=C.UTF-8 during package building
On Fri, Jun 07, 2024 at 02:32:14PM +0200, Guillem Jover wrote: > And I think forcing a locale on buildds makes perfect sense, because > we want easy access to build logs. But forcing LC_ALL from the build > tools implies that no tool invoked will get translated messages at > all, and means that users (not just maintainers) might have a harder > time understanding what's going on, we make lots of l10n work rather > pointless, and if no one is running with different locales then l10n > bugs might easily creep in. absolutly agreed & thanks for bringing up this aspect! > Related to this, dpkg-buildpackage 1.20.0 gained a --sanitize-env, > which for now on Debian and derivatives sets LC_COLLATE=C.UTF-8 and > umask=0022. that's great news! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The past is over. signature.asc Description: PGP signature
Re: Mandatory LC_ALL=C.UTF-8 during package building
Maybe a compromise would be to at least mandate some UTF-8 locale.
Bug#1072754: ITP: golang-github-delthas-go-localeinfo -- Cross-platform library for extracting locale information
Package: wnpp Severity: wishlist Owner: Guilherme Puida Moreira * Package name: golang-github-delthas-go-localeinfo Version : 0.0~git20240607.b2e834f-1 Upstream Author : delthas * URL : https://github.com/delthas/go-localeinfo * License : Expat Programming Lang: Go Description : Cross-platform library for extracting locale information Rather than extracting the current locale name (e.g. en_US), this library enables clients to extract monetary/numeric/time formatting information. . On Linux, this library wraps nl_langinfo. This library is used by senpai (ITP #1072217). --puida
Re: Mandatory LC_ALL=C.UTF-8 during package building
On 07/06/24 14:32, Guillem Jover wrote: Related to this, dpkg-buildpackage 1.20.0 gained a --sanitize-env, which for now on Debian and derivatives sets LC_COLLATE=C.UTF-8 and umask=0022. That's great news! But _iff_ we end up with dpkg-buildpackage being declared the only supported entry point, [...] Personally, I really appreciate how dpkg-buildpackage more and more provides a standardized API to/for building Debian packages. However I would prefer to have this API explicitly described in Policy rather than hidden and implicitly defined by the code of a specific program. What I propose is a new section in Policy [1] that explicitly lists all these environment requirements (umask, LC_*, SOURCE_DATE_EPOCH, TMPDIR, /bin/sh = POSIX shell + -n, etc). Each builder would then be changed to be conformant by default, with the option to steer away if desired (for example `dpkg-buildpackage --with-env-var LC_ALL=fr_FR.UTF-8`). This would create an uniform environment while preserving the ability to run d/rules with user-specific settings. [1] Or any other similarly "binding" document. Regards, -- Gioele Barabucci
Re: Mandatory LC_ALL=C.UTF-8 during package building
Hi, On 6/7/24 22:40, Alexandre Detiste wrote: Maybe a compromise would be to at least mandate some UTF-8 locale. Having an UTF-8 locale available would be a good thing, but allowing packages to rely on the active locale to be UTF-8 based reduces our testing scope. Basically, we need to define the severity of locale bugs -- if we define that package builds can expect LC_ALL=C.UTF-8, and reproducible-builds testing finds out that passing a non-UTF-8 locale in causes a deviation or a build failure, is the maintainer free to close this "wontfix", or should this still be addressed? Besides locales, there are other things that might affect outcomes, and we need to find some reasonable position between "packages should be reproducible even if built from the maintainer's user account on their personal machine" and "anything that is not a sterile systemd-nspawn container with exactly the requested Build-Depends and no Recommended packages causes undefined behaviour." Personally my preference would be as close as possible to the former, because if I ever need to work on someone else's package, the chance is high that I will need incremental builds and a graphical debugger, and both of these are a major hassle in containers. Simon OpenPGP_0xEBF67A846AABE354.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Mandatory LC_ALL=C.UTF-8 during package building
On Fri, 07 Jun 2024 at 23:22:46 +0900, Simon Richter wrote: > On 6/7/24 22:40, Alexandre Detiste wrote: > > Maybe a compromise would be to at least mandate some UTF-8 locale. > > Having an UTF-8 locale available would be a good thing, but allowing > packages to rely on the active locale to be UTF-8 based reduces our testing > scope. I'm not sure I follow. Are you suggesting that we should build each package *n* times (in a UTF-8 locale, in a legacy locale, in locales known to have unique quirks like Turkish and Japanese, ...), just for its side-effect of *potentially* passing through those locales to the upstream test suite? If we want to run the test suite in each of those locales, then I think instead we should do just that: run the test suite (and only the test suite!) in each of those locales. dh_auto_test could grow a way to do that, if there's demand. Repeating the whole compilation seems like a sufficiently large waste of time and resources that, in practice, we are not going to be able to do this routinely for more than a couple of locales. Or, better, we should provide packages with a way to guarantee that certain locales are available[1], and then tests that are known to be testing locale-sensitive things should explicitly switch into the locales of interest, to make sure that they are tested every time, not just if the builder's locale happens to be the interesting one. For example, glib2.0's test suite temporarily switches to a Japanese locale in order to test its handling of formatting dates with an era (Japanese is one of the few locales where that concept exists), and it does this even when built by a non-Japanese-speaking developer like me. If it relied on the current locale for its test coverage, then we would never have discovered #1060735 unless it was coincidentally built by a Japanese developer who is using a big-endian machine, which seems quite unlikely to happen by chance! Or, when you say "testing", do you really mean "doing the build, for the side-effect of seeing whether it succeeds or fails"? (That's not really the same thing as running a test suite.) Realistically, several important tools require a UTF-8 locale and will not work reliably otherwise. Meson either is one of these, or was in the past, as a result of Python's Unicode behaviour; so debhelper sets LC_ALL=C.UTF-8 when it invokes Meson, ignoring any preference that might have been expressed by the caller of dpkg-buildpackage. [1] Build-Depends: locales-all does this, but is rather heavy. debian/tests/run-with-locales in e.g. src:glib2.0 is another implementation, but a more centralized version of this would probably be better. > Basically, we need to define the severity of locale bugs More than that, we need to define what is a locale bug and what is a non-bug - ideally based on what is genuinely useful, rather than on "this is something that could theoretically work". We should try to solve bugs, because that benefits our users and Free Software, but we should put zero effort into solving non-bugs. What we say is a bug, and what we say is not a bug, is a policy decision about our scope: we support some things and we do not support others. There's nothing magical or set-in-stone about the set of things that we do and don't support, and it can be varied if there is something close to consensus that it ought to be. When we're deciding what is in-scope and what is out-of-scope, we should make that decision based on comparing the costs and benefits of a wider/narrower scope: "this is in-scope because I say so" or "this is in-scope because we have traditionally said it is" are considerably weaker arguments than "this is in-scope because otherwise we can't access this benefit". As an analogy: we have chosen to define in Policy that /bin/sh is anything that supports the POSIX shell language, plus a few designated extensions like `echo -n`. A consequence of that is that "foobar fails to build when /bin/sh is bash" is considered to be a bug (which, in an ideal world, we would solve), because bash is a POSIX shell; but "foobar fails to build when /bin/sh is csh" is a non-bug (which we wouldn't even leave open as wontfix, we would just close it), because csh isn't a POSIX shell. In a different parallel universe, we might reasonably have declared that /bin/sh is required to be bash (like it is in e.g. Fedora), which would result in some things that are currently bugs becoming non-bugs - that's a narrower scope than then one that Debian-in-this-universe has, resulting in it being easier to maintain but less flexible. Or, conversely, in a different parallel universe, we might have said that /bin/sh can be literally any POSIX shell, which is a wider scope than Debian-in-this-universe: "FTBFS when /bin/sh doesn't support echo -n" is currently a non-bug, but in that hypothetical distribution it would be a bug, making the distribution harder to maintain but more flexible. I am, personally, a fan of setting a sco
Re: Mandatory LC_ALL=C.UTF-8 during package building
On Fri, 07 Jun 2024 at 14:32:14 +0200, Guillem Jover wrote: > I'm a non-native speaker, who has been involved > in l10n for a long time, while at the same time I've pretty much > always run my systems with either LANG=C.UTF-8 or before that LANG=C, > LC_CTYPE=ca_ES.UTF-8 and LC_COLLATE=ca_ES.UTF-8. So diagnostic messages in your non-English language are so important to you that you ... set your locale environment variables to values that result in you seeing diagnostic messages in English instead? I'm not sure I understand the point you're making here :-) If your point is that people-who-are-not-you place a higher value on having diagnostic messages come out in their non-English language than you personally do, then, yes, that's certainly a valid thing for those people to want. But I'm not sure that our current package set actually achieves that - increasingly many of our packages overwrite the locale with "C.UTF-8" in some layer of their build system, because they cannot guarantee that the locale they inherit from the environment is anything reasonable (in particular, it might be "C", which often breaks tools that want to work with non-ASCII filenames, inputs or outputs). In the enumeration from my earlier message, you want (1.), but increasingly, what you actually get is (2½.) instead, and that results in neither you nor Giole getting the results you would hope for. The compromise that Alexandre suggested elsewhere in the thread - requiring the locale to be *something* UTF-8, but leaving it unspecified exactly which UTF-8 locale, so that a French-speaking developer can ask for fr_FR.UTF-8 and get their compiler warnings in French - seems like something that might actually give you what you want in more cases than the status quo does? If we mandate a UTF-8 locale, then stack layers like debhelper's meson plugin could probably stop forcing C.UTF-8. > we make lots of l10n work rather pointless Surely only if that l10n work was done on tools that are only ever run from package builds, and never interactively? A lot of localization is done for end-user-facing tools (GUI, TUI or CLI) which are never relevant during a package build anyway. Even for compilers and similar non-interactive development tools, if a French-speaking developer runs gcc in the fr_FR.UTF-8 locale during their upstream development, they'll still benefit from its warnings being localized into French, even if they would never see those same warnings during a Debian package build of the same software. (Analogous: I similarly benefit from gcc having ANSI colour highlights in its output, even though my Debian package build logs don't have those.) > and if no one is running with different locales then l10n > bugs might easily creep in If no one is running (their interactive sessions) with a particular locale, why do we even support that locale? If a locale has users, and they find bugs, then of course those bugs are something to be fixed (subject to triaging and prioritization, because we have more bugs than time). But I'm not convinced that occasionally doing package builds in arbitrary locales is something that will find locale bugs more readily than real users' normal use of the software that we ship. The locale issues I've generally seen during package builds are more like "I've set up this artificial situation, and now the consequences of what I asked for are considered to be a bug", for instance "if I run this tool that wants to output UTF-8 in an ASCII-only locale, it fails with an error message" (well, of course it does, it's being put in a situation where it can't do its job as-designed). Or building HTML documentation in an arbitrary locale, and then having reproducible-builds act surprised that one build mentions the French translation of "table of contents" and the other mentions the German translation of "table of contents" (well, of course it does - "you asked for it, you got it"). > I can understand though the sentiment > of wanting to shrug this problem category off and wanting instead to > sweep it under the carpet, but that has accessibility consequences. I am not advocating sweeping this problem category under the carpet! I'm just not convinced that saying "we support building any package with an arbitrary locale at entry to the build system" is actually a good way to detect the sorts of locale issues that cause the sorts of concrete end-user-facing problems that have accessibility consequences. If we want to run test-suites under multiple locales, then we should maybe consider doing that, rather than using the locale of the build system as a proxy for the (single) locale in which tests will be run for this particular build. Saying "it's a bug if your test suite fails in tr_TR.UTF-8" doesn't do anything to guarantee that anyone will actually ever try that particular build scenario. And, even if your test suite passes in tr_TR.UTF-8, that doesn't necessarily mean that the right thing as expected by a Turkish spe
Re: Mandatory LC_ALL=C.UTF-8 during package building
Hi, On 6/8/24 00:42, Simon McVittie wrote: Having an UTF-8 locale available would be a good thing, but allowing packages to rely on the active locale to be UTF-8 based reduces our testing scope. I'm not sure I follow. Are you suggesting that we should build each package *n* times (in a UTF-8 locale, in a legacy locale, in locales known to have unique quirks like Turkish and Japanese, ...), just for its side-effect of *potentially* passing through those locales to the upstream test suite? To an extent, that is what reproducible-builds.org testing does. According to [1], they test LC_ALL unset vs LC_ALL set to one of et_EE.UTF-8, de_CH.UTF-8, nl_BE.UTF-8, or it_CH.UTF-8. They also test other locale variables. What I'm concerned about is not so much tests inside packages behaving differently depending on locale, because that is an upstream problem. Reproducibility outside of sterile environments is however a problem for us as a distribution, because it affects how well people are able to contribute to packages they are not directly maintaining -- so for me this hooks into the salsa discussion as well: if my package is not required to work outside of a very controlled environment, that is also an impediment to co-maintenance. What we say is a bug, and what we say is not a bug, is a policy decision about our scope: we support some things and we do not support others. Exactly, and a lot of the debates we've had in the past years is who gets to decide what is in scope, and what is "legacy" code that should be excised to reduce the workload of the people driving change forward. What Giole proposed at the beginning of this thread can be rephrased as declaring that "FTBFS when locale is not C.UTF-8" and "non-reproducible when locale is varied" are non-bugs, and therefore they are not only wontfix, but they should be closed altogether as being out-of-scope. Indeed -- however this class of bugs has already been solved because reproducible-builds.org have filed bugs wherever this happened, and maintainers have added workarounds where it was impossible to fix. Turning this workaround into boilerplate code was a mistake already, so the answer to the complaint about having to copy boilerplate code that should be moved into the framework is "do not copy boilerplate code." For locales and other facets of the execution environment that are similarly easy to clear/reset/sanitize/normalize, we don't necessarily need to be saying "if you do a build in this situation, you are doing it wrong", because we could equally well be saying "if you do a build in this situation, the build toolchain will automatically fix it for you" - much more friendly towards anyone who is building packages interactively, which seems to be the use-case that you're primarily interested in. No, automatic fixes are absolutely not friendly -- these *add* to my mental load because I need to be aware of them if I want to understand what is happening. This is already annoying enough for LC_ALL=C.UTF-8 inside a package, but at least that usually happens in prominent enough places that I can find it, and it is part of the package. Magic code inside the framework that performs an action automatically for me is extra debugging effort, because I need to either know the exact rules that the framework applies, or I need to debug into the framework. Simon [1] https://tests.reproducible-builds.org/debian/index_variations.html OpenPGP_0xEBF67A846AABE354.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1072781: ITP: python-cmake-build-extension -- Setuptools extension to build and package CMake projects
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-cmake-build-extension Version : 0.6.0 Upstream Author : Diego Ferigo * URL : https://github.com/diegoferigo/cmake-build-extension * License : BSD-3-clause, Expat Programming Lang: Python, C++ Description : Setuptools extension to build and package CMake projects This extension aims to simplify the integration of C++ projects based on CMake with Python packaging tools. CMake provides out-of-the-box support to either SWIG and pybind11, that are two among the most used projects to create Python bindings from C++ sources. If you have any experience with these hybrid projects, you know the challenges to make packaging right! This project takes inspiration from pre-existing examples (pybind/cmake_example, among many others) and provides a simple, flexible, and reusable setuptools extension with the following features: * Bridge between CMake projects and Python packaging * Configure and build the CMake project from setup.py * Install the CMake project in the resulting Python package * Allow passing custom CMake options * Allow creating a top-level __init__.py * Expose C++ executables to the Python environment * Provide a context manager to import CPython modules reliably on all major OSs * Disable the C++ extension in editable installations (requiring to manually call CMake to install the C++ project) The package will be team-maintained under the umbrella of the Debian Python Team at https://salsa.debian.org/python-team/packages/cmake-build-extension -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmZjY4YACgkQzIxr3RQD 9MqGvg//VlaEUgFyHvAoIv37IPVMvDRj3nUt+IO210T0sSeqowswdQC/qVPz2wj4 nk2WXEfjgPUO98caa/YYKjHCW68rg9KgAFu+Ypiizu5Tw5xQ4SFIf5gbonBqetSw acqmGzZPhh9VsI1cRICsRFsO8JDdZ6HNVbliWqRaFd3nQJFiLxeCh/5Rw5XxEmQU f86h23XdeMi9N/qiRhTNQsYIoxvXSpCvJLsn+u+yt7Xizz1k2ufGMHKJPe8EuO6F Mkh8hYLfCPugDpy6TGB/DCpxs4f7IG1/oUZBCWqRDGzK3uwyUrLFK6DRrMLigURT sqbhT/XzHn+4d8j/kGp1ZnV8Wm92W3gl3DPI6hRyM6qS8fmYiROU8F+eNDZJs8fk 6QxCQroesk6lJ9Be5Zx2DTvosAY2p9/ythUPXr+y44CBcu7MyZuHU1C3aeVVPDPx wOFPob8/ePLAM+vfVX7bgROt6ggwK9tEGwrjwtadtbSslIs/F1g54ScNfmqB1Zfm whubrSpbupFatEospoz9K6owVenVb4XDb2XCs9DPrsDnEr8iIpE9GxcV6JliAsPU 3+Xm8fjM0WGqJ+c/AhcUL7G0ff9CvkyDA5t+0qOt+7Jifpx4u+WASRh1F6tYsJa/ U6POUN7T9VpLrYdqu2m8Ld17XYWLFfqmbQfuePrcak2plipiDBU= =zIQr -END PGP SIGNATURE-
Bug#1072491: Dead keys stopped working in unspecified environment
Hi all, First: - DE is Cinnamon. - DM is lightdm. - Keyboard model is Generic 105-key PC - keyboard layout is Danish - AltGr function is default - Compose key is 'Meny key' I have now tried installing and uninstalling gnome-session-bin which have no effect so that cannot be the cause. Changing DE from Cinnamon to XFCE4 and dead key works. Creating a new user and using this user session in both Cinnamon and XFCE4 and dead key works in both DE. Conclusion: My Cinnamon DE using my old user must have gone haywire somehow so I have created a new user and therefore this bug can be closed with solution 'works here, must be user error' ;-) Sore to all for the noise. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc https://keys.openpgp.org/vks/v1/by-fingerprint/A1306C5094B5E31B7721A3A66F4844C7CA7501AA mir datanom net https://keys.openpgp.org/vks/v1/by-fingerprint/0C14CD9479667E848770C8F98417B6C5E1BB093F mir miras org https://keys.openpgp.org/vks/v1/by-fingerprint/5F71405B571CB8EE2A414A4FC77C11E049A06E66 -- 'During times of universal deceit, telling the truth becomes a revolutionary act.' -George Orwell Don't just echo the code with comments - make every comment count. - The Elements of Programming Style (Kernighan & Plaugher) This mail was virus scanned and spam checked before delivery. This mail is also DKIM signed. See header dkim-signature.
Bug#1072491: marked as done (Dead keys stopped working in unspecified environment)
Your message dated Fri, 07 Jun 2024 22:18:08 +0200 with message-id and subject line Re: Bug#1072491: Dead keys stopped working in unspecified environment has caused the Debian Bug report #1072491, regarding Dead keys stopped working in unspecified environment to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1072491: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072491 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libglib2.0-0t64 Version: 2.80.2-2 Severity: important Dear Maintainer, Exactly some bug as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070745 appears once again. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (600, 'unstable'), (500, 'unstable-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.8.12-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libglib2.0-0t64 depends on: ii libc6 2.38-12 ii libffi8 3.4.6-1 ii libmount1 2.40.1-4 ii libpcre2-8-0 10.42-4+b1 ii libselinux1 3.5-2+b2 ii zlib1g1:1.3.dfsg+really1.3.1-1 Versions of packages libglib2.0-0t64 recommends: ii libglib2.0-data 2.80.2-2 ii shared-mime-info 2.4-5 ii xdg-user-dirs 0.18-1 Versions of packages libglib2.0-0t64 suggests: pn low-memory-monitor -- no debconf information This mail was virus scanned and spam checked before delivery. This mail is also DKIM signed. See header dkim-signature. --- End Message --- --- Begin Message --- Closing then. Am 7. Juni 2024 22:01:56 MESZ schrieb Michael Rasmussen : >Conclusion: My Cinnamon DE using my old user must have gone haywire >somehow so I have created a new user and therefore this bug can be >closed with solution 'works here, must be user error' ;-) -- Sent from /e/ OS on Fairphone3--- End Message ---
Bug#1072801: ITP: lsix -- Show thumbnails in terminal using sixel graphics
Package: wnpp Severity: wishlist Owner: Blair Noctis X-Debbugs-Cc: debian-devel@lists.debian.org, n...@sail.ng * Package name: lsix Version : 1.8.2 Upstream Contact: b9 * URL : https://github.com/hackerb9/lsix * License : GPL-3 Programming Lang: Shell Description : Show thumbnails in terminal using sixel graphics Like "ls", but for images. . Features include: - Detects if your terminal can display SIXEL graphics inline. - Works great over SSH. - Non-bitmap graphics often work fine (.svg, .eps, .pdf, .xcf). - Automatically detects if your terminal, like xterm, can increase the number of color registers to improve the image quality and does so. - Automatically detects terminal's foreground and background colors. - In terminals that support `dtterm WindowOps`, the number of tiles per row will adjust appropriately to the window width. - If there are many images in a directory (>21), lsix will display them one row at a time so you don't need to wait for the entire montage to be created. - Filenames that are too long will be wrapped before passing into ImageMagick's montage to avoid jumbling on top of one another. - Easily change things like width of each tile in the montage, font family, and point size by editing simple variables at the top of the file. (Tip: try convert -list font to see what fonts you have on your machine.) - Unicode filenames work fine, as long as your font has the glyphs. It's a single shell script whose only dependency is ImageMagick's montage program. I intend to maintain it in the debian namespace, and am happy to have someone sponsor it. -- Sdrager, Blair Noctis pgprBZ2m_uFNh.pgp Description: OpenPGP digital signature
