Bug#1102093: ITP: tree-sitter-asm -- tree sitter grammar for ASM
Package: wnpp Severity: wishlist Owner: Matthias Geiger X-Debbugs-Cc: debian-devel@lists.debian.org, werdah...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: tree-sitter-asm Version : 0.24.0 Upstream Contact: RubixDev * URL : https://github.com/RubixDev/tree-sitter-asm * License : MIT Programming Lang: C/JS/Rust Description : tree sitter grammar for ASM tree-sitter-asm is a tree-sitter grammer for ASM. It's a prerequisite for asm-lsp which I also ITP. . Will be maintained with the tree-sitter team. best, werdahias -BEGIN PGP SIGNATURE- iIsEARYIADMWIQQUWTv/Sl6/b+DpcW7svtu2B7myvgUCZ/BhkRUcd2VyZGFoaWFz QGRlYmlhbi5vcmcACgkQ7L7btge5sr5nlAEAkMqVIP5M5uwmeUhm4GUyy5S26g/S mGHC89QwibyJR88A/iIFrCxnzpOsyb/oXlRXpS5KUPgwROF+s6pw0io+gJUC =OW8a -END PGP SIGNATURE-
Re: Help with Dillo package (attempt 2)
On Friday, April 4, 2025 3:50:13 PM Mountain Standard Time Rodrigo Arias wrote: > On Fri, Apr 04, 2025 at 03:26:14PM -0700, Soren Stoutner wrote: > >Rodrigo, > > > >It looks like dillo is maintained by Axel Beckert . > > > >https://tracker.debian.org/pkg/dillo > > > >He would be the first person you should probably ask about updating > >the package. > > TL;DR: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022726 > > https://chaos.social/@xtaran/112905124915743612 If you have already made an effort to contact the maintainer without satisfaction, then what you are really looking for is someone to salvage the package. https://www.debian.org/doc/manuals/developers-reference/ pkgs.en.html#package-salvaging debian-devel isn’t the best place to make a package salvaging request. Realistically, if you really care about the package, your best option is probably to become the maintainer of the package yourself. If you have any interest, I would recommend you read: https://mentors.debian.net/intro-maintainers/ Questions about how to package should be directed to debian- ment...@lists.debian.org. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1101936: ITP: nam-files -- Unicode ranges used to subset fonts in the Google Fonts CSS API
Package: wnpp Severity: wishlist Owner: Bastian Germann X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: nam-files Version : 2024.09.25 * URL : https://github.com/googlefonts/nam-files * License : Apache-2 Programming Lang: Rust, Python Description : Unicode ranges used to subset fonts in the Google Fonts CSS API This is the collection of nam files (codepoint subsets) that are used to subset fonts before serving on the Google Fonts CSS API. This also includes the Python module gfsubsets which provides an interface to these subset definitions.
key packages RC bugs of the month April
Dear all, During the preparation phase of bookworm, I was running an awareness campagne on RC bugs [1] in package in the key package set [2]. As those packages are exempted from being auto-removed, their RC bugs are ironically less exposed. Ideally we should get the number of RC bugs in trixie down to zero. We're now in the middle of the first freeze. Currently we have 183 RC bugs in key packages affecting trixie of which 133 are unresolved in unstable or experimental, aren't pending and don't have a patch. Here are 5 RC bugs in key packages to draw attention to this class of bugs. Remember, resolving these bugs is a collective effort. #994274 syslinux FTBFS with gnu-efi 3.0.13 https://bugs.debian.org/994274 #1064712 node-public-encrypt FTBFS: TypeError: RSA_PKCS1_PADDING is no longer supported for private decryption, this can be reverted with --security-revert=CVE-2023-46809 https://bugs.debian.org/1064712 #1065666 mesa Upgrading to mesa from testing breaks compiz https://bugs.debian.org/1065666 #1069553 xsd FTBFS on armel: dh_auto_test: error: make -j4 test returned exit code 2 https://bugs.debian.org/1069553 #1071316 infinipath-psm FTBFS: ips_proto_dump.c:142:15: error: static declaration of âstrlcatâ follows non-static declaration https://bugs.debian.org/1069553 I am asking for help with investigating RC bug reports, judging severity, reproducing the issue, clarifying the problem, i.e. bug triaging of all RC bugs that haven't seen activity for a while and that are still affecting trixie. Of course ideally the bug gets fixed. Remember, if you really think a bug shouldn't be RC (particularly if you are the maintainer), downgrade it with an explanation. If in doubt, leave your note in the bug report, that's already a great help. Paul [1] https://udd.debian.org/dev/cgi-bin/rcblog7.cgi [2] https://release.debian.org/key-packages.html OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Help with Dillo package (attempt 2)
Hi, On Fri, Apr 04, 2025 at 03:59:24PM -0700, Soren Stoutner wrote: If you have already made an effort to contact the maintainer without satisfaction, then what you are really looking for is someone to salvage the package. https://www.debian.org/doc/manuals/developers-reference/ pkgs.en.html#package-salvaging debian-devel isn’t the best place to make a package salvaging request. Realistically, if you really care about the package, your best option is probably to become the maintainer of the package yourself. If you have any interest, I would recommend you read: https://mentors.debian.net/intro-maintainers/ Questions about how to package should be directed to debian- ment...@lists.debian.org. I'm not very familiar with Debian to do it myself, but there are some Debian Maintainers that offered their efforts to help. However, given this: I currently have 3 issues with the current situation: 1) It's a new upstream, so all code should be reviewed. 2) On several channels I get urged to follow one of multiple new upstreams from quite some people I've never heard before. This is suspicious, especially after the xz fuckup 4 months ago. So I have to be extra cautious in choosing a new upstream. 3) It's not so high on my TODO list. Help from well-known DDs is very welcome! And this: (Axel) is the current maintainer and not absent, and I’ve already said I’ll provide a fix in time. In fact, sponsorship requests for a package that has a maintainer are hostile takeover attempts. We wouldn’t want anyone to do these. (From https://chaos.social/@xtaran/112905124915743612) I was under the assumption that the Debian Developers were the only group suitable to perform the update. If this is not the case, I can ask around in case someone is interested in helping with the salvage process. Thanks, Rodrigo.
Re: Help with Dillo package (attempt 2)
On Fri, Apr 04, 2025 at 03:26:14PM -0700, Soren Stoutner wrote: Rodrigo, It looks like dillo is maintained by Axel Beckert . https://tracker.debian.org/pkg/dillo He would be the first person you should probably ask about updating the package. TL;DR: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022726 https://chaos.social/@xtaran/112905124915743612
Bug#1102094: ITP: asm-lsp -- Language server for NASM/GAS/GO assembly
Package: wnpp Severity: wishlist Owner: Matthias Geiger X-Debbugs-Cc: debian-devel@lists.debian.org, debian-r...@lists.debian.org, werdah...@debian.org Control: block -1 by 1102093 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: asm-lsp Version : 0.10.0 Upstream Contact: bergercookie * URL : https://github.com/bergercookie/asm-lsp * License : BSD-2-Clause Programming Lang: Rust Description : Language server for NASM/GAS/GO assembly Provide hovering, autocompletion, signature help, go to definition, and view references for assembly files written in the GAS/NASM or GO assembly flavors. It supports assembly files for the x86, x86_64, ARM, RISCV, z80, AVR, and 6502 instruction sets. Supported assemblers include the Gas, Go, Masm, Nasm, ca65, and AVR assemblers. . This provides a language server to be used with an editor supporting the LSP. Co-maintainers welcome; no Rust packaging experience needed. best, werdahias -BEGIN PGP SIGNATURE- iIsEARYIADMWIQQUWTv/Sl6/b+DpcW7svtu2B7myvgUCZ/BkVxUcd2VyZGFoaWFz QGRlYmlhbi5vcmcACgkQ7L7btge5sr6t7QD8CoPSLUNrbpe5c61iwzRJM/fuW5qB 2YluFUcYP13y3eEBAP5zYiAlXXae5cbJ2b32o2h9CVN5MS1bnjMlGdPbFNYG =N4b9 -END PGP SIGNATURE-
Re: Help with Dillo package (attempt 2)
On Friday, April 4, 2025 4:14:23 PM Mountain Standard Time Rodrigo Arias wrote: > I was under the assumption that the Debian Developers were the only > group suitable to perform the update. If this is not the case, I can > ask around in case someone is interested in helping with the > salvage process. I suggest you read over the salvaging criteria I linked to earlier. Note that salvaging a package is not a fast process and the current maintainer has plenty of opportunities to stop it by committing to actively maintain it themselves. Smaller problems can be handled by an NMU (Non-Maintainer Upload). Indeed, the last upload of dillo was an NMU. However, switching the upstream of a package is beyond the scope of something that an NMU normally handles. Any Debian Contributor or Debian Maintainer can salvage a package. They do need a Debian Developer to sponsor the upload. https://mentors.debian.net/sponsors/ -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1102103: ITP: python-friendly-traceback -- Friendlier tracebacks in any language
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com * Package name: python-friendly-traceback Version : 0.7.62 Upstream Contact: Andre Roberge * URL : https://github.com/friendly-traceback/friendly-traceback * License : MIT/Expat Programming Lang: Python Description : Friendlier tracebacks in any language Friendly-traceback analyzes and reformats Python error messages, providing detailed explanations about the cause of the error and possible solutions. It is useful for developers, students, and debugging tools, making error analysis more accessible and educational. . Main features: - Detailed and educational explanations for Python exceptions. - Support for multiple languages. - Can be integrated into other debugging projects.
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
Bug#1102045: ITP: rt-extension-authen-oauth2 -- OAuth2 authentication extension (for Request Tracker)
Package: wnpp Severity: wishlist Owner: Andrew Ruthven X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rt-extension-authen-oauth2 Version : 0.13 Upstream Contact: Best Practical Solutions, LLC * URL : https://metacpan.org/dist/RT-Authen-OAuth2 * License : GPL v2 Programming Lang: Perl Description : OAuth2 authentication extension (for Request Tracker) This extension provides functionality to login to Request Tracker (request-tracker5 pacakge) using OAuth2. This package will be maintained by the Requester Tracker Maintainers Team.
Bug#1102043: ITP: rpicam-apps -- A small suite of libcamera-based applications to drive the cameras on a Raspberry Pi platform.
Package: wnpp Severity: wishlist Owner: Pragyansh Chaturvedi X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rpicam-apps Version : 1.5.3 Upstream Contact: Serge Schneider * URL : https://github.com/raspberrypi/rpicam-apps * License : BSD-2-Clause Programming Lang: C++ Description : A small suite of libcamera-based applications to drive the cameras on a Raspberry Pi platform. Raspberry Pi supplies a small set of example rpicam-apps. These CLI applications, built on top of libcamera, capture images and video from a camera. These applications include: - rpicam-hello: A "hello world"-equivalent for cameras, which starts a camera preview stream and displays it on the screen. - rpicam-jpeg: Runs a preview window, then captures high-resolution still images. - rpicam-still: Emulates many of the features of the original raspistill application. - rpicam-vid: Captures video. - rpicam-raw: Captures raw (unprocessed Bayer) frames directly from the sensor. This package is already accepted into Ubuntu (https://launchpad.net/ubuntu/+source/rpicam-apps), and will be maintained by ubuntu-devel.
Re: utmp in trixie
Michael Stone writes: > I'm the one who gets the complaints that who isn't working right, and > there isn't a solution to that problem, since the systemd facility > doesn't provide the same information. I'd argue that a lot of people > didn't realize how screwed up things were going to be, because the > change didn't impact normal use until after a reboot. I think if a fix is not possible, who(1) should at least terminate with an error code (and possibly display an error message) rather than failing silently as it currently does. Of course, some forms like "who -b" still work.
Bug#1102056: ITP: libhash-merge-extra-perl -- Collection of extra behaviors for Hash::Merge
Package: wnpp Owner: Andrew Ruthven Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name : libhash-merge-extra-perl Version : 0.06 Upstream Author : Michael Samoglyadov * URL : https://metacpan.org/release/Hash-Merge-Extra * License : Artistic or GPL-1+ Programming Lang: Perl Description : Collection of extra behaviors for Hash::Merge Provide behaviors for Hash::Merge to modify how hashes are merged, these are: - Hashes merged, arrays joined, undefined scalars overridden. Left and right precedence. - Hashes merged, arrays and scalars overridden. Left and right precedence. - Nothing merged. One thing simply replaced by another. Left and right precedence. This package will be a dependency for the next version of Request Tracker (I'm not sure when it'll be released, but I'd like to make backports of RT to Trixie easier by having this package in Trixie). 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. -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: utmp in trixie
On Fri, Apr 04, 2025 at 03:43:03PM +0200, Marc Haber wrote: Can your package handle the classic on-disk format when it is compiled with 64 bit time_t? I remember there was some discussion about that back then. If you touch /run/utmp you'll see it is still working fine with any packages that haven't ripped out support.
Re: utmp in trixie
On Thu, 3 Apr 2025 17:41:46 -0400, Michael Stone wrote: >On Thu, Apr 03, 2025 at 07:52:12PM +0200, Marco d'Itri wrote: >>On Apr 03, Michael Stone wrote: >>>The issue isn't making a change, the issue is what change is the >>>right thing to do. IMO, dropping utmp without any kind of a >>>transition or deprecation period is the wrong thing to do. Hence >>>this thread. >>I think it's a bit late now to disagree with the plan implemented last >>year by multiple maintainers. > >Except, of course, for the primary consumer of utmp... > >I'm the one who gets the complaints that who isn't working right, and >there isn't a solution to that problem, since the systemd facility >doesn't provide the same information. I'd argue that a lot of people >didn't realize how screwed up things were going to be, because the >change didn't impact normal use until after a reboot. So people have >slowly been finding out over time that a decades-old interface is no >longer available, and the answer "well, we decided to drop it" falls a >little flat since there seems to be no actual reason to not just support >both mechanisms. Can your package handle the classic on-disk format when it is compiled with 64 bit time_t? I remember there was some discussion about that back then. Greetings Marc -- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: Bits from the Release Team: trixie freeze started
Hallo Paul, De unsubsribe werkt niet goed. Ik krijg elke keer nog mailtjes. Hoe kan ik mij hier uitschrijven? Groet Joop Op za 29 mrt 2025 om 09:13 schreef Paul Gevers : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi all, > > === trixie Transition and Toolchain freeze === > > We're pleased to announce that the freeze for Debian 13 'trixie' has > begun. On March 15th we stopped accepting transition requests and we are > working to complete the transitions in progress. We ask the maintainers > of packages that are part of the toolchain to stop uploading those > packages [1] without prior approval from us. We remind everybody to stop > uploading large or disruptive changes to unstable, from here on > experimental is the place to do that. > > Further details of the freeze are available in the freeze policy [2]. > The freeze contains 3 more milestones: > * 2025-04-15 - Milestone 2 - Soft Freeze >no new packages, delayed migration > * 2025-05-15 - Milestone 3 - Hard Freeze - key packages and packages >without autopkgtests need a manual unblock for migration > * TBA- Milestone 4 - Full Freeze >all packages need a manual unblock for migration > > === RC bugs === > > The current list of Release Critical bugs for trixie [3] is > progressively looking better. Thanks to everybody who is helping > out. That said, we're not there yet, ideally the number of RC bugs goes > down to zero. And autoremoval has done it's job, there's a large set of > packages that are currently *not* in trixie, so this is your last chance > to bring them back. > > Don't forget to organize your bug squashing parties: > https://wiki.debian.org/BSP/ There's one planned for the end of April. > > === release notes === > > We like to draw your attention to the release notes. We have hardly > received any proposals (or even ideas), don't forget to file things > worth mentioning against the release-notes pseudo package in the bts or > prepare your MR on salsa [4]. The release notes editors will be helping > you to shape the text, so don't be shy and submit those rough ideas > already. > > === testing upgrades === > > If you are in the position to already upgrade some hosts from bookworm > to trixie, we like to hear from you if you run into issues. If you > don't know which package is to blame, please don't be shy and report it > against the upgrade-reports pseudo package and people following that > package will try and help find the right package (help wanted for the > triaging). > > === your packages === > > Please take this opportunity to check packages are in their final shape > and stay vigilant for release-critical bugs. > > On behalf of the Release Team, > Paul > > [1] https://release.debian.org/testing/essential-and-build-essential.txt > [2] https://release.debian.org/testing/freeze_policy.html > [3] https://udd.debian.org/bugs.cgi > [4] https://salsa.debian.org/ddp-team/release-notes/ > > > > -BEGIN PGP SIGNATURE- > > iQEzBAEBCgAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmfnqfwACgkQnFyZ6wW9 > dQo5RQf6AuEPvHQpueKMm9Md+yCQB5BW0LFN8pcZtIHkpeuGKu5K4Dz2rpx983kP > FmLU7o3nqxEuuIvc6XQKC/YL7MboY9moGD4fl6ozRvaLOGQRM3KGc0aTuPQG5NWU > 4ec7hg+Dp2XZchiAWlas4OnLMsCCqKMFy5ZHY4Wf5fhY4Vln91czmxhdozKrATqb > 0FlVZ8+NCqcosjGBpIeRlZO7nyOaNjUMbDQu9zzSONmQmHEXAy1Tkka7M8mhUds1 > P44wEtv+dAvgXWqkoStz9LJm99WWGZu3bDBXmRxS8HORoHTULd1bR3G3jjji4m82 > NTQQfZTgL/HoIWZmJVKi4hM3uuMzGA== > =TvxU > -END PGP SIGNATURE- > >
Re: utmp in trixie
On Thu, Apr 03, 2025 at 12:47:07AM +0200, Marco d'Itri wrote: On Apr 02, Bill Allombert wrote: Does that breaks the usual unix commands like 'who' ? If yes this is who(1) specifically, yes. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079575 . Maybe the coreutils maintainer is already working to backport this simple patch in time for trixie, or else you could help him. The issue isn't making a change, the issue is what change is the right thing to do. IMO, dropping utmp without any kind of a transition or deprecation period is the wrong thing to do. Hence this thread.
Bug#1101930: ITP: python-ttfautohint-py -- Python wrapper for ttfautohint
Package: wnpp Severity: wishlist Owner: Bastian Germann X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-ttfautohint-py Version : 0.5.1 * URL : https://github.com/fonttools/ttfautohint-py * License : Expat Programming Lang: Python Description : Python wrapper for ttfautohint ttfautohint-py is a Python wrapper for ttfautohint, a free auto-hinter for TrueType fonts. It uses ctypes to load the libttfautohint shared library and call the TTF_autohint function.
Re: Bug#1101376: ITP: package-assembler -- CLI tool to create necessary files for a Debian package
On Mon Mar 31, 2025 at 10:56 PM BST, CrypticVerse wrote: I am sorry if this was said earlier and I did not catch it, but I cannot find the reasoning behind the closure of this ITP. Can someone tell me just a bit more about that? Again, I am sorry if this was already mentioned I've re-opened it for you now. -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: Bug#1102018: utmp in trixie
Holger Levsen writes: > package: releasenotes > x-debbugs-cc: debian-devel@lists.debian.org > > On Tue, Apr 01, 2025 at 03:27:05PM -0400, Michael Stone wrote > Message-ID: <70ba7152-0f2e-11f0-9b6a-00163eeb5...@msgid.mathom.us> > to debian-devel@l.d.o stating: > >> /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. > > this should be filed as bug in the BTS, at the very least against the > releasenotes, so doing that now. Is this different to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1083102 and, more importantly, is https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/214 missing anything frm this thread?
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
Re: utmp in trixie
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) could be a well alternative to who(1), as the discussed alternatives wtmp goes with last, utmp goes with who; they have different semantics
Re: utmp in trixie
Hi Dirk, 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. 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). Andrew signature.asc Description: PGP signature
Re: utmp in trixie
On Wed, Apr 02, 2025 at 05:52:13PM +1100, Craig Small wrote: Yes, there is definitely a Y2038 issue *for trixie*? there are also issues with utmp not being handled consistently and some security issues around who can do what to the file. Stuff that has been true literally decades. If someone can turn off utmp if they want to, does this matter?
Help with Dillo package (attempt 2)
Hi, I'm trying again to reach debian-devel, this time by subscribing first to the list. I have also contacted your #debian-lists IRC channel for more information on what happened, but I didn't got any reply. I'll write a slightly shorter email here, the full email is forwarded below (some typos corrected about dates). The version of the Dillo web browser that you currently distribute with Debian (3.0.5) is 10 years old. Since that version, a lot of changes were done by the original developers, but they never got into a release before the project was abandoned around 2017 (last email from Jorge was from 2019). Among those changes was the support for floats or the switch to mbedTLS instead of OpenSSL. The 3.0.5 version has several issues on the network side, as it is unable to properly handle TLS alerts. On the rendering side, there are problems with floats, image ratios and with the lack of CSS units among others. You can easily see those yourself if you browse a bit: $ dillo https://api.invidious.io/ ... Nav_open_url: new url='https://api.invidious.io/' 40178B7AD370:error:0A000438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:../ssl/record/rec_layer_s3.c:1590:SSL alert number 80 In 2024 I decided to resurrect the project and fix those and many other problems. You can try by yourself and see the difference on the sites side by side. Here is the new website and changelog: https://dillo-browser.github.io/ https://raw.githubusercontent.com/dillo-browser/dillo/refs/heads/master/ChangeLog Our latest release 3.2.0 fixes A LOT of problems in the rendering side and introduces new features like SVG support for Wikipedia math equations. It also includes the unreleased changes from the original developers. I presented some features and the overall state at FOSDEM this year: https://www.youtube.com/watch?v=sFJp8JDg8Yg Dillo is designed to run on very old computers and/or low power devices like Raspberry Pi. Given that newcomers to Linux often begin with Debian based distros, it is unlikely that they know how to build an updated Dillo browser from source, so I'm interested in distributing already built binaries. Do you have any interest in updating Dillo in the Debian repository, or should I invest my time in finding other ways to distribute a binary package to users? Thanks, Rodrigo. - Forwarded message from Rodrigo Arias Mallo - Date: Sat, 29 Mar 2025 22:23:29 +0100 From: Rodrigo Arias Mallo To: debian-devel@lists.debian.org Cc: Axel Beckert Subject: Help with Dillo package User-Agent: Mutt/2.2.14 (516568dc) (2025-02-20) Hi, The Dillo web browser stopped its development in 2017, so I decided to continue the development on my own in early 2024, even though I have not previously contributed to the project. My current goal is to continue with the original plan of keeping the browser fast and simple, so it can be used in old computers and on slow networks. I'm doing this in my free time, so the development is slow but steady. You can read my announcement in the HN post: https://news.ycombinator.com/item?id=38847613 I have contacted all previous developers via email, and some of them replied and helped me retrieve some missing parts that I have archived, but I have been unable to reach Jorge (the lead developer). None of them seem to be interested in developing it further. Here is the new website and git repository: https://dillo-browser.github.io/ https://github.com/dillo-browser/dillo The old dillo.org site was lost in 2022 and is now mostly serving AI-generated SPAM: https://dillo-browser.github.io/dillo.org.html https://dillo.org/post-sitemap.xml Here is an archived copy of the original old website: https://dillo-browser.github.io/old/index.html http://web.archive.org/web/20220508022123/https://www.dillo.org/ We also have a new mailing list (with the recovered old archives), an IRC channel and mastodon account: https://lists.mailman3.com/hyperkitty/list/dillo-...@mailman3.com/latest irc://irc.libera.chat/#dillo https://fosstodon.org/@dillo I did a FOSDEM presentation this year talking about the resurrection process as well as new features that we added with a live demo in an old netbook: https://fosdem.org/2025/schedule/event/fosdem-2025-4100-resurrecting-the-minimalistic-dillo-web-browser/ Here is the color corrected video, as I forgot to turn off my blue filter: https://www.youtube.com/watch?v=sFJp8JDg8Yg Debian currently distributes the last 3.0.5 release from 2015 before the project development ceased, which is known to have several TLS issues (among many others) that we have already fixed and we track the ones people reported here: https://github.com/dillo-browser/dillo/issues/305 You can see all the issues that we fixed here for each release we did, they are organized in milestones: https://github.com/dillo-browser/dillo/milestones?state=closed Here is the changelog: https://g
Re: Help with Dillo package (attempt 2)
Rodrigo, It looks like dillo is maintained by Axel Beckert . https://tracker.debian.org/pkg/dillo He would be the first person you should probably ask about updating the package. On Friday, April 4, 2025 2:33:22 PM Mountain Standard Time Rodrigo Arias wrote: > Hi, > > I'm trying again to reach debian-devel, this time by subscribing > first to the list. I have also contacted your #debian-lists IRC > channel for more information on what happened, but I didn't got any > reply. > > I'll write a slightly shorter email here, the full email is > forwarded below (some typos corrected about dates). > > The version of the Dillo web browser that you currently distribute > with Debian (3.0.5) is 10 years old. Since that version, a lot of > changes were done by the original developers, but they never got > into a release before the project was abandoned around 2017 (last > email from Jorge was from 2019). Among those changes was the > support for floats or the switch to mbedTLS instead of OpenSSL. > > The 3.0.5 version has several issues on the network side, as it is > unable to properly handle TLS alerts. On the rendering side, there > are problems with floats, image ratios and with the lack of CSS > units among others. > > In 2024 I decided to resurrect the project and fix those and many > other problems. You can try by yourself and see the difference on > the sites side by side. Here is the new website and changelog: > >https://dillo-browser.github.io/ > > https://raw.githubusercontent.com/dillo-browser/dillo/refs/heads/ma > ster/ChangeLog > > Our latest release 3.2.0 fixes A LOT of problems in the rendering > side and introduces new features like SVG support for Wikipedia > math equations. It also includes the unreleased changes from the > original developers. I presented some features and the overall > state at FOSDEM this year: > >https://www.youtube.com/watch?v=sFJp8JDg8Yg > > Dillo is designed to run on very old computers and/or low power > devices like Raspberry Pi. Given that newcomers to Linux often > begin with Debian based distros, it is unlikely that they know how > to build an updated Dillo browser from source, so I'm interested in > distributing already built binaries. > > Do you have any interest in updating Dillo in the Debian repository, > or should I invest my time in finding other ways to distribute a > binary package to users? > > Thanks, > Rodrigo. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
