Re: Should GPU shaders be considered firmware?
Hell Stephan =)
On 3/15/25 12:52 PM, Stephan Verbücheln wrote:
Am Donnerstag, dem 13.03.2025 um 02:37 +0100 schrieb Dirk Lehmann:
GPU shaders should be clearly respected as software (and not
hardware). Therefore, `intel-media-va-driver-non-free` is rightly in
the Debian archive `non-free`.
First of all, I completely agree that:
1. shaders are computer programs
2. the shaders in that package are unfree
okay, I have looked a bit into the sources of the upstream repository.
And I have good news!
All source files I checked in
* media_driver/agnostic/*/kernel{,isa}/*/*.c
which you listed at begin of this thread looks like as they are
* EITHER SHADERS NOR FIRMWARE !
These datasets are looking more like n-dimensional arrays.
Kernels in image- and video processing are mathematical matrices.
I.e. on images they will be scrolled (mathematical operation:
"symmetric convolved") through the images as (real-time)-filter for
anti-aliasing, sharpening, etc. In this `intel-media-va-driver`-case
they are seeming to be used to interpolate frames. I would assume,
for example if the video footage has a frame-rate of 60 fps and the
rendering-context (i.e. display) 144 fps then additional frames will
be generated/interpolated.
Here a Wiki link for the case of image processing:
* https://en.wikipedia.org/wiki/Kernel_(image_processing)#Convolution
Yes, such tasks are usually done by shaders from GPU, but I'm quite
sure that the data above are just the Kernel-Matrices itself. Would
be nice, if somebody can verify that the exported symbols in the
corresponding header files are really no executable code containing.
Question of licensing
*
I'm not a lawyer, but just want to start a discussion about a possible
sublicensing. Even in my last post I had data explicitly excluded
from the general case
On 3/13/25 2:37 AM, Dirk Lehmann wrote:
> [...]
>
> As you expect, in detail from technical point of view, firmware is a
> special kind of software. It is not data -- and it is executable in
> the sense that it changes the state of "physical hardware" in time.
>
> [...]
From technical point of view, I would
* consider these kernel-matrices as binary images
As like images are painted with tools like Gimp, the kernel-matrices
were generated by the `KernelBinToSource.exe` tool (see source
comments), whose sources are available in the upstream repository,
too.
But I'm not a lawyer and don't know in detail how to deal with it. I
would try do something like this:
The license of sources itself grants to the kernel-matrices-images
besides copy, modify, merge, publish, distribute also explicity
* sublicensing
For me as not-lawyer it is a license of the class
attribution-share-alike license. The question should be if it is
allowed to sublicense the kernel-matrices-images as
* CC BY-SA
(Creative Commons Attribution-ShareAlike Licenses) ?
as this license should be better for datasets -- and if so, if the CC
BY-SA is compliant to our DFSG. But I really have to less knowledge
about that topic, and which formalities are needed to be respected for
sublicensing.
Greets,
Dirk =)
OpenPGP_0xE2A3766F21F02BD5.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: utmp in trixie
Hello Andrew, On 4/4/25 11:13 PM, Andrew Bower wrote: On Fri, Apr 04, 2025 at 09:10:42PM +0200, Dirk Lehmann wrote: On 4/3/25 2:58 PM, Antonio Terceiro wrote: I never cared about /run/utmp in itself, but I got used to last(1). FWIW, a new implementation of last is now provided by wtmpdb. +1 great, it looks like that * wtmpdb(8) [...] The program arguments are not fully compatible with Unix equivalent last(1). I.e. it seems not to be possible to just filter out all current still active sessions, which should be provided by `last -p` in the Unix world. Presumably you used 'last -p now' for this? It looks like this would be satisfied by a richer range of accepted time specifications by wtmpdb. `last -p now` does not work. I've reported this under * #1102101: Argument `last -p ` not working (UTC / local-time?) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102101 Do you want to raise a bug? Worth adding if there is anything else defective (it looks to me that crashed sessions get included, which seems unhelpful). Additionally, I run into some other issues reported here * #1102102: Argument `last -t ` not working https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102102 * #1102105: Argument combination `last -x -s ` not working https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102105 Greets, Dirk =) OpenPGP_signature.asc Description: OpenPGP digital signature
Should be wtmp considered as successor of who(1)?
Hi curl's and boys =D in relation to the discussion of 'utmp in trixie' * https://lists.debian.org/debian-devel/2025/04/msg00011.html It looks like, that wtmp is an well alternative to who(1). For that the command $> last -p now should be able to use in the future. But the developers at upstream of wtmpdb persist in the opinion that wtmp has nothing to do with utmp before merging PR#36. * https://github.com/thkukuk/wtmpdb/issues/33 Now, I have not the guts to ask them, if they would like to implement an own who(1) utility. I think it should not be an security issue, if by default who(1) logs every libpam-login without an installed autitd or selinux extension. What do you think ??? But please, before writing: Calm down! It makes no sense to discuss that frantically. Please think before writing! I know such mailing lists. Dirk. OpenPGP_signature.asc Description: OpenPGP digital signature
ITP: python-qutip-{qip,qtrl,qoc}, python-qutip -- QuTiP packages
Hello Devel Mailing List, I have requested 4 ITPs to WNPP. Below is following a concluded summary. Greets, Dirk =) ** Bug#1101791: ITP: python-qutip-qip -- QuTiP package - Quantum Information Processing Package: wnpp Severity: wishlist Owner: Dirk Lehmann X-Debbugs-Cc: debian-scie...@lists.debian.org * Package name: python-qutip-qip Version : 0.4.0 Upstream Contact: https://github.com/qutip/qutip-qip/discussions * URL : https://github.com/qutip/qutip-qip * License : BSD-3-Clause Programming Lang: Python Description : QuTiP package - Quantum Information Processing The qutip-qip package, QuTiP quantum information processing, aims at providing basic tools for quantum computing simulation both for simple quantum algorithm design and for experimental realization. Compared to other libraries for quantum information processing, qutip-qip puts additional emphasis on the physics layer and the interaction with the QuTiP core package `python3-qutip`. The package offers two different approaches for simulating quantum circuits, one with `QubitCircuit` calculating unitary evolution under quantum gates by matrix product, another called `Processor` using open system solvers in QuTiP to simulate noisy quantum device. ** Bug#1101792: ITP: python-qutip-qtrl -- QuTiP package - Quantum Optimal Control Package: wnpp Severity: wishlist Owner: Dirk Lehmann X-Debbugs-Cc: debian-scie...@lists.debian.org * Package name: python-qutip-qtrl Version : 0.1.5 Upstream Contact: https://github.com/qutip/qutip-qtrl/issues * URL : https://github.com/qutip/qutip-qtrl * License : BSD-3-Clause Programming Lang: Python Description : QuTiP package - Quantum Optimal Control The qutip-qtrl package, QuTiP quantum optimal control, aims at providing advanced tools for the optimal control of quantum devices. Compared to other libraries for quantum optimal control, qutip-qtrl puts additional emphasis on the physics layer and the interaction with the QuTiP core package `python3-qutip`. The package offers support for both the CRAB and GRAPE methods. ** Bug#1101793: ITP: python-qutip-qoc -- QuTiP package - Advanced Quantum Optimal Control Package: wnpp Severity: wishlist Owner: Dirk Lehmann X-Debbugs-Cc: debian-scie...@lists.debian.org * Package name: python-qutip-qoc Version : 0.1.1 Upstream Contact: https://github.com/qutip/qutip-qoc/issues * URL : https://github.com/qutip/qutip-qoc * License : BSD-3-Clause Programming Lang: Python Description : QuTiP package - Advanced Quantum Optimal Control The qutip-qoc package builds up on the `python3-qutip-qtrl` package. . It enhances it by providing two additional algorithms to optimize analytically defined control functions. The first one is an extension of Gradient Optimization of Analytic conTrols (GOAT). The second one (JOPT) leverages QuTiPs version 5 new diffrax abilities to directly calculate gradients of JAX defined control functions using automatic differentiation. . The package also aims for a more general way of defining control problems with QuTiP and makes switching between the four control algorithms (GOAT, JOPT, and GRAPE and CRAB implemented in qutip-qtrl) very easy. ** Bug#1101794: ITP: python-qutip -- QuTiP: Quantum Toolbox in Python Package: wnpp Severity: wishlist Owner: Dirk Lehmann X-Debbugs-Cc: debian-scie...@lists.debian.org * Package name: python-qutip Version : 5.1.1 Upstream Contact: https://github.com/qutip/qutip/discussions * URL : https://github.com/qutip/qutip * License : BSD-3-Clause Programming Lang: Python Description : QuTiP: Quantum Toolbox in Python QuTiP is open-source software for simulating the dynamics of open quantum systems. The QuTiP library depends on the excellent Numpy, Scipy, and Cython numerical packages. In addition, graphical output is provided by Matplotlib. QuTiP aims to provide user-friendly and efficient numerical simulations of a wide variety of Hamiltonians, including those with arbitrary time-dependence, commonly found in a wide range of physics applications such as quantum optics, trapped ions, superconducting circuits, and quantum nanomechanical resonators. ** OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion
Hello Debian-Devel mailing list =D imho, an interesting topic. In conjunction with [1] my first notion was: We should not guide that proprietary software is insecure. That's not correct, i.e. in the case of non-free-firmware it is nearly equivalent to say that the usage of proprietary hardware is insecure. Instead we need begin to define, what is hardware in a philosophic way and then define an clear interface (or policy) between hard- and software. I.e. in that interface it should be defined how software is verifying that it runs on the correct hardware, like TPMs it do. Or I could imagine that an verification-chain beginning from firmware-blobs (loaded by driver) through the hardware which ends in the kernel-module driver (back to driver, means the chain makes a round-trip). It is correct that also in that case it is not possible to understand what is going on in the firmware itself. But from my knowledge, it is an logistic issue to make firmware open source. Imagine you are developing classical mainboards (equivalent to current SoC development), then you need to provide the firmware of the chipset in your mainboard driver. But you can imagine that the most chipset companies don't like to provide the sources of the blobs, they just specify how to load these into the chipset. In my opinion this is the most relevant issue why most firmware is not available as open source. In practice it means: If you have an favorite mainboard company, would you like that these are able to modifying the blobs of the chipset vendors? My clearly opinion is no. Okay we could say: It is just required, that the chipset company needs to sign it's blobs and then it can provide the sources of the firmware. But 1. also in that case we need an verify-mechanism between soft- and hardware. 2. it need's a kind of "Open Hardware" infrastructure. Now we can go back to the philosophic point of view: If we have such an interface between hard- and software then the open source software is just one layer of a full-stack machine. You can install proprietary software upon an purely open-source-system, also you can have proprietary hardware blow an purely open-source-system. The question is at which point begins hardware below such an purely open-source-system. If we really think, that firmware is software then need adapt our vision (or policy, interface) at which point begins the hardware layer. Also, if we have such a well defined vision then this is not enough. The next step needs to be to develop a vision (or policy) of "Open Hardware" on which hardware companies can act. Reference: [1] https://www.gnu.org/philosophy/compromise.html End Of Opinion, Dirk =D On 3/7/25 6:35 PM, pan...@disroot.org wrote: Dear Debian Community, I am Deep Pandya from Gujarat, India, and a long-time Debian user. I migrated from Windows to Ubuntu in 2013 and later explored the philosophy of the GNU project and the history of the free software movement. After trying GNU-endorsed Trisquel and PureOS, I finally landed on Debian (Stretch release) in 2019 and have been actively using it since (Buster, Bullseye, Bookworm). In 2020, I even wrote a blog post, “Reasons to choose Debian among GNU/Linux distributions” (https:// lignuxblog.wordpress.com/2020/08/27/reasons-to-choose-debian/). Though I am not a programmer or software developer, I deeply care about Debian’s values. In 2022, the General Resolution to officially include non-free firmware in the installation images shocked me because it signified a move away from Debian’s conceptual roots. I fully believe in the GNU philosophy and its uncompromising commitment to freedom. Without that, we might not have had the Linux kernel under GPL or even the open-source movement. However, when it comes to practical usability, I acknowledge that some users—myself included—may need to install non-free firmware for WiFi, Bluetooth, or graphics drivers. But in the past, when I made such a compromise, I was aware of it. Debian used to perfectly balance software freedom and usability— until 2022. I understand that users need proprietary drivers to run certain hardware, and Debian should not ignore this reality. That is why I am not asking Debian to become a fully GNU-endorsed distro like Trisquel, which rejects all non-free software in every case. However, at the same time, Debian should not readily promote non-free firmware to the point where it loses its philosophical distinction and becomes just another convenience-focused distribution like Ubuntu or Linux Mint. *[A Ruinous Compromise]* After compromising a byte, our goal should be to find/develop libre alternatives so that, in the future, Debian users are less (bit) dependent on non-free firmware. Instead, we did the opposite— compromising more, from a byte to a kilobyte, for the sake of convenience. If this trend continues, what stops us from reaching a megabyte of compromise? Debian’s official inclusion
Re: General Questions about Translations and what a package maintainer has to do
Hello Marc,
I am currently new as Debian Maintainer, but I have more experience
from upstream-side.
As I understand your question about a general workflow of translations
in all your email-cases correct, I think the short answer maybe to use
`quilt` to patch the .PO files instead of committing them directly via
Git. Also consider `gbp-pq`, could be useful, but not sure.
The reason is, that you can merge (aka. apply) your patch-series
(patch-series: something like a branch in Git) at any time during
source-package building. As I'm new to Debian packaging I'm not sure
if it is possible to use "debian/patches"; but I think no, because the
step is hard-coded during `dpkg-buildpackage` -- and that is not what
we want.
I would recommend to use another quilt directory, like
`debian/patches-intl`. I don't know if there exist some other
recommended directory in any Debian Policy or Debian Guide. Then you
can call in `debian/rules` at the time you wish to apply your patch
series
```
$> QUILT_PATCHES=debian/patches-intl quilt push -a
```
The manual call in `debian/rules` ensures that you can decide yourself
at which step to apply your patches -- and decide if the
`dpkg-buildpackage` should break with an error on fail-patching, or
not. If the package maintainer changes, it should be easy to comment
out the one `quilt` command in `debian/rules` and remove the
patch-series `debian/patches-intl` from the package-repository.
To commit your changes to upstream you just need to apply (or ask to
apply) the patch-series into theres repository. Make sure to have
many small patches, then the chance is greater that some patches are
going to upstream, and maybe others not.
If these patches coming down from upstream `quilt push -a` stops with
a message like:
```
Applying patch debian/patches-intl/.patch
patching file
Hunk #1 FAILED at .
1 out of 1 hunk FAILED -- rejects in file
Patch debian/patches-intl/.patch can be reverse-applied
```
Quilt detects with the message 'can be reverse-applied' that it was
already applied by third-party. Then you can delete the patch in the
patch series with:
```
$> QUILT_PATCHES=debian/patches-intl quilt delete -nr
```
followed by completing to apply the patch series with a second `quilt
push -a` -- and repeatly so on, if more than one patches where
accepted by upstream.
Quilt also allows adapting your patches, in contrast to Git, at which
commits are forever or are needed to be reverted with a revert-commit
(see backport work-flows). That was also an issue you reported.
This workflow should also work if upstream already have translations
committed -- and/or you begin a fresh one. Maybe, not sure, that it
also solve the issue of the multiple calls of `msgmerge`; as I
understand, `msgmerge` was used as a kind of `patch`.
Hopefully this helps you for progression,
Dirk =)
On 3/11/25 12:03 PM, Marc Haber wrote:
tl;dr: We need more docs about best practices to handle translations as
a package maintainer
My fellow developers,
there are two things in being a DD that I truly despise. The one is
keeping the machine readable debian/copyright up to date, the other is
handling of translations, regardless of whether it's po-debconf, manpage
translations or program translations (when I am also the upstream).
I might rant about debian/copyright when I blow my fuse next time, but
today it's going to be translations. For me, it seems impossible to
support translator's work without putting a significant burden of
additional work to put on oneself. Especially when one uses version
control and does not do all development in Mast^wdebian/latest, dealing
with translations is a nightmare when it comes to merge. As the Newbie¹
DD I am, I keep running into either nightmare merges, or unnecessarily
fuzzed or even destroyed translations, in all cases feeling even more
stupid and incompetent when some translator points out my mistakes. I
have felt being sent back and forth between different workflows (all of
them wrong) by following random advice without being able to find
authoritative explanation.
I might have a fundamantal misunderstandig of procedures, but all
documentation one finds, including Chapter 8 in the Developer's
Reference (which links to a document by Tomohiro KUBOTA which is no
longer there), elaborate on how one would do actual translations, but
doesn't go as far as giving best practice documentation about what a
package maintainer is supposed to do to make translation blend into a
normal packaging workflow without being a nuisance ("put them into the
po directory and build the package" doesn't fit a modern packaging
workflow using version control).
My example package is adduser, but I think that my questions might apply
to other packages as well. adduser has both its program messages and the
manual pages translatable, the latter being done with po4a. I am aware
that there are also translations for debconf templates, but adduser
doesn't have those (
Re: Should GPU shaders be considered firmware?
Hello Stephan, On 3/12/25 12:10 PM, Stephan Verbücheln wrote: Hello everyone The “drivers” for hardware video decoders on Intel GPUs have been split into free and non-free packages. https://packages.debian.org/en/sid/intel-media-va-driver https://packages.debian.org/en/sid/intel-media-va-driver-non-free The difference between the two is that the Intel source code contains blobs (byte arrays in the C source) with pre-compiled GPU shaders. The source code for the pre-complied shaders is not included and does not appear to be available under a free license. great pragmatic question! First of all my answer: The answer ** GPU shaders should be clearly respected as software (and not hardware). Therefore, `intel-media-va-driver-non-free` is rightly in the Debian archive `non-free`. Model of free software systems ** As I described in * https://lists.debian.org/debian-devel/2025/03/msg00196.html for me is a computer machine a stack of three layers: Machine/Computer ,-, | optional non-free/proprietary software | |-| | Free and open-source software | |-| | Hardware (maybe non-free/proprietary) | '-' If we remove the optional `non-free` layer on the top then we have a fully free software system. I would assume that also GNU would not refute this model of a fully free software system. The question must be: Is firmware to be considered as hardware or software? I.e. in your case of GPU shaders the question is: * Should be GPU shaders considered as hardware or software? The reason for the answer above *** We should unite us in the point that we do not accept non-free software between the bottom two layers. Means there should be no non-free software directly above the hardware layer. As I pointed out in the thread linked above, that we need to consider firmware as hardware in the sense that: 1. Firmware needs to be developed by the chip-vendor itself. (Hardware from companies point of view) 2. Firmware needs to be deployed between hardware companies, i.e. SoC companies, PCB companies, etc. (Hardware from logistic point of view) Now GPU shaders: 1. GPU shaders will not be developed exclusively by the chip vendor itself. In contrast, they providing SDKs for development. 2. GPU shaders will be deployed between software companies, and not exclusively by hardware companies. I.e. 3D engine developers to Game design companies. From technical point of view not clear ** As you expect, in detail from technical point of view, firmware is a special kind of software. It is not data -- and it is executable in the sense that it changes the state of "physical hardware" in time. Physically stored as * a mapped table of commands on, we don't know: flashable EPROM, Solid-State-Device, RAM, ... * an array/matrix of programmable basic gates on: FPGA, ... From this point of view, it makes no sense to differentiate between firmware and software by the media on which it will be stored -- or the format how it changes the state-machine. If someone do so then they are cheating themselves. BUT!: This point of view is wrong in our current situation. From companies-/logistic- ->to-> technical- point of view * Okay, someone would say: * "What? My point of view, the technical one, is wrong? wtf!" The answer is: The path is the goal. The 3-layer machine/computer model we agree all, hopefully. We can map the companies-/logistic- point of view very well to that 3-layer model, imho. We need to go a path! The goal of the path is the technical point of view. Otherwise we become shizo ;P ... What is the path? Imho, I recognize exactly 3 possible paths in the 3-layer machine/computer model. With the border between layer 'Free software' and 'Hardware' * path 1: ... we can soften/remove it and create a flowed merge of both. * path 2: ... we can insert an additional layer, called 'non-free-firmware'. * path 3: ... we describe it very precisely, as accurately as possible. Path 1 is brain-dead, who contradicts? xD ... Path 2 is that what we do not want; not to be confused with path 2 is the current actual-state! We try to find a path, and path 2 is very trivial: Map the current Debian archives structure to the 3-layer machine/computer model. Okay, then we need to go path 3, we need to describe the border between layer 'Free software' and 'Hardware' very precisely, as accurately as possible. Therefore, in my opinion we have something like an homogeneous system: If our path needs to be go from companies-/logistic- |--> technical- point of vi
Re: General Questions about Translations and what a package maintainer has to do
Hey Marc, On 3/11/25 12:03 PM, Marc Haber wrote: Basically the same applies for this step than for the POT generation step, with the additional hardship that the PO files are generated, being written to by a program AND STILL contain a significant part of human work. I never know how much work of other people I am destroying by calling msgmerge out of line. In which stage of package build do I do msgmerge? Do I commit the merged po files, when do I commit them, what do I do with them during git merge when a feature branch is merged? I have a bit played around with `msgmerge` and found a way to display a `diff` which contains the translations which will be destroyed if you merge a .po file from a translator * test-de_DE-transl.po into your maintained one * test-de_DE.po in conjunction with the current generated .pot file * test.pot The essential code snippet looks like this ** * * msgmerge -q -C test-de_DE-transl.po test-de_DE.po test.pot \ * > test-de_DE-maint+transl.po * msgmerge -vv -q -C test-de_DE.po test-de_DE-transl.po test.pot \ * > test-de_DE-transl+maint.po * * # Print out the new merged .po file * cat test-de_DE-transl+maint.po * * # Show the diff of destroyed translations (including comments) * diff -u test-de_DE-maint+transl.po test-de_DE-transl+maint.po * ** The order of the `msgid`s are not necessary in the .po files and will be defined in the .pot file. Also comments and headers diffs will be printed out. For all of my test cases (I could imagine) it works very well. You can try it out: I put an example implementation in a Makefile and put it together with a small test-translation into a tarball attachmented to this email. You just need to run $> make all With `make clean` you can delete the two temporary files. The output of the makefile in the tarball is appended to this email. Hopefully it helps for progression, Dirk =) ** * msgmerge-show-overridden.tar.gz * * Begin of output ** make all msgmerge -q -C test-de_DE-transl.po test-de_DE.po test.pot > test-de_DE-maint+transl.po msgmerge -vv -q -C test-de_DE.po test-de_DE-transl.po test.pot > test-de_DE-transl+maint.po test.pot:11: this message is used but not defined in test-de_DE-transl.po test.pot:32: this message is used but not defined... test-de_DE-transl.po:21: ...but this definition is similar Read 1 old + 1 reference, merged 9, fuzzied 1, missing 1, obsolete 1. New test-de_DE.po cat test-de_DE-transl+maint.po msgid "" msgstr "" "Language: German\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" "X-Generator: PhraseApp (phraseapp.com)\n" msgid "boolean_key" msgstr "" msgid "pluralized_key" msgid_plural "" msgstr[0] "" msgstr[1] "" # Translator: Overridden comment msgid "key_with_description" msgstr "" msgid "empty_string_translation" msgstr "" msgid "nested.key" msgstr "Fuzzy" msgid "null_translation" msgstr "" #, fuzzy msgid "nested.deeply.key" msgstr "Fuzzy" msgid "sample_collection" msgstr "" msgid "unverified_key" msgstr "" msgid "simple_key" msgstr "Einfacher Translator Stirng" Overridden by translator diff -u test-de_DE-maint+transl.po test-de_DE-transl+maint.po || true --- test-de_DE-maint+transl.po 2025-03-19 14:52:18.567974496 +0100 +++ test-de_DE-transl+maint.po 2025-03-19 14:52:18.571974539 +0100 @@ -4,7 +4,7 @@ "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" -"Plural-Forms: nplurals=3; plural=(n > 2);\n" +"Plural-Forms: nplurals=2; plural=(n != 1);\n" "X-Generator: PhraseApp (phraseapp.com)\n" msgid "boolean_key" @@ -15,7 +15,7 @@ msgstr[0] "" msgstr[1] "" -# Maintainer: I'm a very important description for this key! +# Translator: Overridden comment msgid "key_with_description" msgstr "" @@ -39,4 +39,4 @@ msgstr "" msgid "simple_key" -msgstr "Einfacher Maintainer Stirng" +msgstr "Einfacher Translator Stirng" ** * End of output * * msgmerge-show-overridden.tar.gz ** msgmerge-show-overridden.tar.gz Description: application/gzip OpenPGP_0xE2A3766F21F02BD5.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: utmp in trixie
On 4/3/25 2:58 PM, Antonio Terceiro wrote: On Tue, Apr 01, 2025 at 03:27:05PM -0400, Michael Stone wrote: /run/utmp is no longer provided in trixie, which means that the mechanisms used to show active sessions in unix for several decades no longer work. There's a replacement mechanism provided by systemd, but it's not 1:1. I propose that for trixie *both* mechanisms are active, so a person can choose between them (and compare the output, to better identify gaps between the historic utmp mechanism and the new and improved systemd facility). I've been told that the reason this can't be done is that utmp isn't y2038 compliant, but it seems to me that we won't be supporting trixie in y2038, so who cares? Are there any factors to consider that I've missed? I never cared about /run/utmp in itself, but I got used to last(1). FWIW, a new implementation of last is now provided by wtmpdb. +1 great, it looks like that * wtmpdb(8) could be a well alternative to who(1), as the discussed alternatives w(1) and loginctl(1) are not listing su(1) sessions. The program arguments are not fully compatible with Unix equivalent last(1). I.e. it seems not to be possible to just filter out all current still active sessions, which should be provided by `last -p` in the Unix world. Here an example output ``` $> last -S | grep -- '- still' root pts/0 su Fri Apr 4 21:06 - still logged in dirk pts/2 su Fri Apr 4 21:05 - still logged in dirk tty1 loginFri Apr 4 21:04 - still logged in dirk tty7 :0 lightdm Fri Apr 4 20:26 - still logged in reboot system boot 6.12.20-amd64 Fri Apr 4 20:25 - still running ``` Additionally, I fount a Debian-Wiki entry for that topic * https://wiki.debian.org/pam_lastlog2%20and%20wtmpdb Greets, Dirk =) OpenPGP_signature.asc Description: OpenPGP digital signature
