Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Le mar. 7 mai 2024, 20:18, a écrit : > Even after a reboot, I would be upset to lose the debug files that I've > been accumulating for several days while trying to track down an > intermittent problem with this stupid VPN... > At reboot, /tmp isautomatically flushed. It's the default behaviour since years (at least on physical machines). -- Stephane
Bug#1070800: ITP: evremap -- keyboard input remapper for Linux/Wayland systems
Subject: ITP: evremap -- keyboard input remapper for Linux/Wayland systems Package: wnpp X-Debbugs-Cc: debian-devel@lists.debian.org Owner: Yifei Zhan Severity: wishlist * Package name: evremap Version : 0.1.0 Upstream Author : Wez Furlong * URL : https://github.com/wez/evremap * License : MIT Programming Lang: Rust Description : keyboard input remapper for Linux/Wayland systems evremap works by grabbing exclusive access to an input device and maintaining a model of the keys that are pressed. It then applies your remapping configuration to produce the effective set of pressed keys and emits appropriate changes to a virtual output device. Because evremap targets the evdev layer of libinput, its remapping is effective system-wide: in Wayland, X11 and the linux console. (^ from project readme) It works well on my machines and supports more complex mapping (e.g. dual role key based on tapping/holding and M <-> N mapping (F3 -> Ctrl-K / Shift-K -> F5)) while maintaining a simple configure syntax.
Re: Tool to build Debian packages not requiring root in containers ?
Hi Charles, * Charles Plessy [2024-05-08 07:27]: I want to leverage our cluster to automate as much of the rebuilds as I can, but could not find the right tool. I tried to run sbuild in a Singularity image and this failed. However, I do not need the whole power of engines like sbuild, as none of the packages involved require root priviledges to build. Have you tried the unshare backend for sbuild? It uses Linux namespaces instead of full-blown root privileges, and works really great for my regular packaging work. I have not tried running it inside a virtualization container, though. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1070817: ITP: rust-gstreamer-allocators -- rust bindings for libgstalloc
Package: wnpp Severity: wishlist Owner: Matthias Geiger X-Debbugs-Cc: debian-devel@lists.debian.org,, werdah...@riseup.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-gstreamer-allocators Version : 0.22.0 Upstream Contact: Sebastian Dröge * URL : https://gitlab.freedesktop.org/gstreamer/gstreamer-rs * License : MIT or Apache-2.0 Programming Lang: Rust Description : rust bindings for libgstalloc This ITP covers both the low-level and high-level rust bindings for libgstalloc. This is needed to enable the dmabuf feature for rust-gst-plugin-gtk4 which would allow offloading of videorendering directly to hardware with little overhead. This package will be maintained with the Debian Rust Team. best, werdahias -BEGIN PGP SIGNATURE- iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmY9Fg4VHHdlcmRhaGlh c0ByaXNldXAubmV0AAoJEBi9EGs7bFR169wP+wXxVmzzA5qqGAGsvohBndn80fV/ nm42/PCRTSSXO5HeKPXM13klbQulb1iBnQARbsGRra/TBujR9OX2aiSpHM/6P7wo yG3lBqcXplN18ScdDNl1ViJ2M28BJt29u5ZkGsVVLCYP3Evks+i14CDkan7CRKdk LQdo/aYiqpbSHs/qtpYxjRw1ZEMhPf6BOSzeaXubw5jUGfdypfaDXuSgdg8aNK/S jZ5MdIC+j6DSC8PJEuA8zLrksOqzPwU6Iath2HJRS3nAQJ37Ok5Xq6D7xbJZSrZJ /+JTPlQHtSgWVQCO3yzLlDaUufjEgbqpTZ91KaUtB2eQ81s5v65DcayNZtQoLr7D OmbdnYQVhARdetLZmBlR2j9V4b+ZHwTmYTBHMpuK0dPrdMShhO656/Ihc6OY7ZEu SvIaTV+49DKnFVrbdYceGPBdqNvQ/wvWz3yVTjFOt964n3n+xa3dKsf9PUhoJ1Oy /MUETmRTVKpn7Apz+DJccBD1aIw2voqimvT9wAfMngtFCFc7A9YUE1sHKwhOB80J nys+a+Wdhp2yA2S/qM88QHvJZjg8tax8nY5cpnqcQrBKpzaMSW1KahH8PH4TA97D dEe3N8FAnGao6IL2MuUxigQ3PfO0IQZkvBZDFo3HS/0t4S73TZ7uErI/GGRzhUOB CDGb2MzORAd2mbol =S7I1 -END PGP SIGNATURE-
Re: Any volunteers for lintian co-maintenance?
Hi, this mail is a private response from Niels to my mail to the Debian Perl team where I explicitly asked for people helping out with lintian. So far the answer from Niels is the only response. Since he gave explicit permission to quote him in public I'm doing so hereby. Niels assumed that his answer "will not help my case" - but well, I do not think that hiding problems will help anybody else. At Tue, May 07, 2024 at 15:59:21 +0200 Andreas Tille wrote > Hi Perl folks, > ... > --> see full mail at > https://lists.debian.org/debian-perl/2024/05/msg0.html > [ From here I simply quote Niels unchanged - I'll comment probably tomorrow in detail ] Hi Andreas You are welcome to quote me in public, though I feel it will not help your cause. This reply is in private to you, so you can choose whether you want to quote me. I agree with the sentiment that important Debian tools would ideally be co-maintained. However, in the passing years, I have started to feel a disconnect with lintian, its direction and what I would like to see. I no longer use lintian and I am fundamentally not interested in picking up lintian anymore - neither as a user nor as a contributor. I have even uninstalled it from my machines. For now, I still "allow" it in my salsa-ci pipeline but my patience with it is thin. For me, lintian fails in all roles it has. It is not a good tool for newbies to get help, since it can only test build artifacts. As an example, your feedback look is a full package build followed by unpacking the package just so lintian can tell you have a typo on line 4. That is a massive waste of resources - notably developer time and mental bandwidth. It also fails as an archive QA tool in my view since the FTP masters have been unwilling to upgrade to any recent version of lintian. I think FTP master's argument lies with the very poor performance in certain corner cases that adversely affects larger packages (like linux). As a consequence, people now get auto-rejects when uploading because lintian on the FTP master server does not produce the same output as current lintian in stable or newer. For the record, I support the FTP masters here since the performance was quite horrible at some point (might be fixed, might not be) and that would just block benign uploads. In fact, I would go so far as to say that the FTP masters should remove lintian from their upload checks (partly because of this, partly because only source packages are reliably checked which neuters the original point of adding lintian to the upload queue). The latter half (archive-wide qa + performance + trust) might be fixable with a dedicated effort and then a lot of lobbying to restore's people trust in lintian. But that is a lot of work, and it will not solve the former (feedback cycles). The former requires a completely different mindset and scope for the tooling. To that end, I have decided to put my effort into `debputy` where I recently added support for linting *with* quickfixes, reformatting and editor support (the latter via LSP). I think that a much better approach to half of the issues that lintian emits and helps both newcomers and long term contributors to be much more productive. Especially for the editor support related parts, where people get instant feedback both on issues and the fix, automatic reformatting on save and completion suggestions. None of which lintian or wrap-and-sort are capable of. If I am successful, then lintian can specialize its efforts into issues only visible in packaged artifacts and thereby reduce it scope a bit. In that sense, my work might be a (minor) help to the Lintian team on the assumption they are willing to specialize more. But even if I am not successful with `debputy`, I cannot imagine I would consider returning to lintian. It does not scratch my itch and years of issues (some of which are still unfixed) have made me not want to have anything to do with the tool. Best of luck to Axel and anyone joining him to stop the bleeding. I do hope they are successful, since lintian still have valuable features for Debian as a whole that can be salvaged. But I am not going to be the "hero" that salvages that mess. If I am going to do heroics in this area, then it will be related to `debputy` with the aim to enable us to spend less mental bandwidth on daily packaging work. Best regards, Niels PS: In my view, the bleeding of lintian's quality started long before Axel joined the lintian maintenance team and I do not fault Axel for being unable to stop the bleeding. In my view, only a hero could have "managed" that at the expense of their mental health.
Re: Any volunteers for lintian co-maintenance?
I would like to respectfully disagree will some of the opinions expressed in this email. First, I should say that I am painfully aware of how long it takes to run lintian on large packages. When working on qtwebengine-opensource-src it takes my system (Ryzen 7 5700G) about 2 hours to build the package and about half an hour to run lintian against it. I would be completely in favor of any efforts that could be made in the direction of making lintian more efficient, either within lintian itself or in other packages that replicate some or all of lintain’s functionality in more efficient ways. However, I personally find lintian to be one of the most helpful tools in Debian packaging. When going through the application process I found lintian to be a very useful tool in helping me learn how to produce packages that conform to Debian’s standards. The integration of lintian into mentors.debian.net was very helpful to me when I first started submitting packages to Debian, and it is still helpful to me when reviewing other people’s packages that have been submitted to mentors.debian.net. As I type this email I am building an update to qtwebengine-opensource-src. So far, lintian has caught two problems with this release that I would have otherwise missed. I admit that I am fairly new as a Debian Developer, and perhaps as I gain greater experience I would get to the point where lintian never catches things I miss. But I don’t personally expect that to ever happen, because there are too many corner cases or opportunities for typos that computers are much better at catching than humans. I do understand that lintian is in need of a lot of work. I personally have an open MR against the package that fixes a check that is wrong more often than it is right (with both false positives and false negatives). The fix is relatively simple and makes the check 100% accurate as far as I can tell. However, after over a year, it has yet to be reviewed. https://salsa.debian.org/lintian/lintian/-/merge_requests/461[1] I must admit that I have been sorely tempted to get involved with maintaining lintian because I feel it is so important. So far, I have resisted that temptation because I am already involved in a decade-long effort to clean up Qt WebEngine in Debian and get it to the point where it has proper security support. I haven’t wanted to spread myself too thin and end up accomplishing nothing because I tried to do too much. But if lintian’s need increases or if my existing commitments decrease I would be happy to find myself involved with lintian maintenance. Soren On Thursday, May 9, 2024 12:27:49 PM MST Andreas Tille wrote: > Hi, > > this mail is a private response from Niels to my mail to the Debian Perl > team where I explicitly asked for people helping out with lintian. So > far the answer from Niels is the only response. Since he gave explicit > permission to quote him in public I'm doing so hereby. Niels assumed > that his answer "will not help my case" - but well, I do not think that > hiding problems will help anybody else. > > At Tue, May 07, 2024 at 15:59:21 +0200 Andreas Tille wrote > > > Hi Perl folks, > > ... > > --> see full mail at > > https://lists.debian.org/debian-perl/2024/05/msg0.html > [ From here I simply quote Niels unchanged - I'll comment probably tomorrow in > detail ] > > signature.asc Description: This is a digitally signed message part.
Bug#1070827: ITP: libdata-fake-perl -- module for generating fake structured data for testing
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libdata-fake-perl Version : 0.006 Upstream Author : David Golden * URL : https://metacpan.org/release/Data-Fake * License : Apache-2.0 Programming Lang: Perl Description : module for generating fake structured data for testing Data::Fake generates randomized, fake structured data using declarative syntax. Data::Fake is built on higher-order programming principles. It provides users with "factory" functions, which create "generator" functions for specific pieces of data. Wherever randomized, fake data is desired, a generator code reference is used as a placeholder for the desired output. Each time the top-level generator is run, nested generators are recursively run to turn placeholders into the desired randomized data. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#1070829: ITP: wprs -- rootless remote desktop access for remote Wayland and x11 applications like xpra
Package: wnpp Subject: ITP: wprs -- rootless remote desktop access for remote Wayland and X11 applications like xpra X-Debbugs-Cc: debian-devel@lists.debian.org Owner: Yifei Zhan Severity: wishlist * Package name: wprs Version : 0.1.0 Upstream Contact: Nicolas Avrutin * URL : https://github.com/wayland-transpositor/wprs * License : Apache 2.0 Programming Lang: Rust Description : rootless remote desktop access for remote Wayland (and X11, via XWayland) applications like xpra wprs implements rootless remote desktop access for remote Wayland (and X11, via XWayland) applications with supports for session resumption (running applications will survive wprsc disconnection and later reconnection and wprsc restarts). Currently only the the Core and XDG shell protocols are implemented and hardware rendering/dmabuf support is not yet implemented. Generally, wprs will aim to support as many protocols as feasible, it's a question of time and prioritization.
Re: Any volunteers for lintian co-maintenance?
On 09/05/24 at 13:57 -0700, Soren Stoutner wrote: > First, I should say that I am painfully aware of how long it takes to run > lintian on large > packages. When working on qtwebengine-opensource-src it takes my system > (Ryzen 7 > 5700G) about 2 hours to build the package and about half an hour to run > lintian against it. > I would be completely in favor of any efforts that could be made in the > direction of making > lintian more efficient, either within lintian itself or in other packages > that replicate some or > all of lintain’s functionality in more efficient ways. If someone wants to work on lintian performance: the runtimes for the UDD lintian importer (behind https://udd.debian.org/lintian/ ) are available in the lintian_logs table: udd=> select distinct ts, source, version, duration from lintian_logs order by duration desc limit 30; ts | source | version | duration +-+---+-- 2024-04-05 16:54:20.437828 | acl2| 8.5dfsg-5 |32879 2024-04-26 06:20:59.082471 | linux | 6.7.12-1 |16472 2024-02-29 10:39:52.6379 | gcc-14-cross-ports | 4 |14616 2024-02-29 10:39:16.350521 | gcc-14-cross-ports | 5 |14580 2024-02-29 10:35:17.939875 | gcc-11-cross-mipsen | 6+c1+nmu1 |14341 2024-02-29 10:35:06.549735 | gcc-13-cross-mipsen | 2+c1 |14330 2024-02-29 10:34:54.908736 | gcc-14-cross| 4 |14318 2024-02-29 10:34:44.720364 | gcc-12-cross-mipsen | 4+c1 |14308 2024-02-29 10:33:50.035058 | gcc-10-cross-mipsen | 3+c6 |14253 2024-05-09 11:24:34.446854 | llvm-toolchain-17 | 1:17.0.6-12 |13086 2024-02-29 10:04:42.241127 | gcc-14-cross| 3 |12505 2024-05-03 23:10:27.416567 | libreoffice | 4:24.2.3-1 |12238 2024-02-29 09:59:52.604453 | gcc-9-cross-mipsen | 4+c2 |12216 2024-05-07 01:51:54.054889 | llvm-toolchain-16 | 1:16.0.6-27 |11180 2024-04-25 10:31:07.753175 | llvm-toolchain-snapshot | 1:19~++20240421021844+e095d978ba47-1~exp1 | 9881 2024-05-05 04:30:01.133898 | llvm-toolchain-18 | 1:18.1.5-2 | 9811 2024-02-29 12:48:09.931447 | gcc-arm-none-eabi | 15:13.2.rel1-2 | 9773 2024-02-29 13:22:32.331297 | gcc-10-cross| 23 | 9118 2024-05-06 22:16:07.781017 | llvm-toolchain-15 | 1:15.0.7-15 | 8976 2024-04-30 10:12:54.498582 | openblas| 0.3.27+ds-2 | 8787 2024-04-04 10:04:55.49545 | gcc-14 | 14-20240330-1 | 8307 2024-05-07 10:03:49.089649 | ghc | 9.6.5-1~exp1 | 8246 2024-05-02 10:03:49.545502 | gcc-14 | 14-20240429-1 | 8242 2024-02-29 12:54:28.975384 | gcc-13-cross-ports | 17 | 7753 2024-04-14 21:54:48.554806 | ghc | 9.4.7-5 | 7702 2024-02-29 14:38:08.333028 | gcc-13-cross| 14 | 7321 2024-02-29 15:22:27.15095 | gcc-10-cross-ports | 24 | 7192 2024-04-14 09:46:15.411926 | gcc-11 | 11.4.0-9 | 7186 2024-02-29 15:22:21.577515 | gcc-9-cross-ports | 27 | 7156 2024-05-06 09:45:44.77244 | llvm-toolchain-14 | 1:14.0.6-20 | 7155 (30 rows) That's the time for testing the source and all binary packages on all architectures. Lucas
Bug#1070831: ITP: python3-nxtomo -- Python API to edit NXtomo application
Package: wnpp Severity: wishlist Owner: Yadd X-Debbugs-Cc: debian-devel@lists.debian.org, y...@debian.org * Package name: python3-nxtomo Version : 1.2.3 Upstream Contact: , Pierre Paleo , Alessandro Mirone , Jérôme Lesaint * URL : https://gitlab.esrf.fr/tomotools/nxtomo * License : Expat Programming Lang: Python Description : Python API to edit NXtomo application NXtomo is a application definition for x-ray or neutron tomography raw data. See https://manual.nexusformat.org/classes/applications/NXtomo.html python3-nxtomo provide a friendly API to create and edit NXtomo application. This package will be maintained under Debian PAN Team.
