[Salsa CI] stop building dbgsym packages by default?
Dear Debianites, TL;DR: does anybody object about stop building dbgsym packages in the pipeline's build jobs by default? Aiming to reduce the space used in the salsa infrastructure by the salsa-ci artifacts, and to avoid exceeding the size limit in build jobs, we (Salsa CI Team) are planning to stop building dbgsym packages: https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/382 We are aware some fellows have pipelines based on salsa-ci's, and we would like to avoid breaking their stuff, in case something depends on the dbgsym packages. The question is: should `DEB_BUILD_OPTIONS=noautodbgsym` be opt-in or enabled by default? For the Salsa CI Team, -- Santiago P.S. If you are interested on the development of Salsa CI, don't hesitate to subscribe to https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-salsa-ci signature.asc Description: PGP signature
Bug#1023736: ITP: dotdrop -- Save your dotfiles once deploy them everywhere
Package: wnpp Severity: wishlist Owner: Guilherme de Paula Xavier Segundo X-Debbugs-Cc: debian-devel@lists.debian.org,, guilherme@gmail.com * Package name: dotdrop Version : 1.11.0 Upstream Author : deadc0de6 * URL : https://github.com/deadc0de6/dotdrop * License : GPL-3 Programming Lang: Python Description : Save your dotfiles once deploy them everywhere Makes the management of dotfiles between different hosts easy. It allows you to store your dotfiles in Git and automagically deploy different versions of the same file on different setups. It also allows to manage different sets of dotfiles. For example, you can have a set of dotfiles for your home laptop and a different set for your office desktop. Those sets may overlap, and different versions of the same dotfiles can be deployed using different predefined profiles. Or you may have a main set of dotfiles for your everyday host and a subset you only need to deploy to temporary hosts (cloud VM etc.) that may be using a slightly different version of some of the dotfiles. Features: Sync once every dotfile in Git for different usages Allow dotfile templating Dynamically generated dotfile contents with pre-defined variables Comparison between deployed and stored dotfiles Handling multiple profiles with different sets of dotfiles Easily import and update dotfiles Handle files and directories Support symlinking of dotfiles Associate actions to the deployment of specific dotfiles Associate transformations for storing encrypted/compressed dotfiles Provide solutions for handling dotfiles containing sensitive information
Transition: pkg-config to pkgconf: 2022-11-11
Hi, Just a small update: I’m now confident we’re ready to go ahead with the actual transition. I’m still rebuilding some heavy packages that failed to build because of lack of disk space or RAM, but most of the other failures are unrelated to pkgconf, while remaining issues can be resolved later. I will perform a deeper analysis of the failures and will file bugs where appropriate. I will upload pkgconf = 1.8.0-10 + pkg-config = 1.8.0-10 this Friday, 2022-11-11. [1]: http://pkgconf-migration.debian.net/ [2]: https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=andrewsh%40debian.org&tag=pkgconf-rebuild-ftbfs -- Cheers, Andrej
TMPDIR behaviour in maintainer scripts [was: Re: Bug#1023778: mysql-server-8.0: fails to restart on upgrade with libpam-tmpdir]
Thank you for the report. Adding debian-devel@ and the libpam-tmpdir maintainer for wider discussion. On Thu, Nov 10, 2022 at 12:54:34AM +, brian m. carlson wrote: > On my systems, I use libpam-tmpdir, which provides each user with a > private temporary directory owned and accessible only by them under > /tmp/user/UID (e.g., /tmp/user/1000). PAM sets the TMPDIR variable to > this value upon creating a session. > > When I upgrade mysql-server-8.0, it is obviously as root, so TMPDIR is > set to /tmp/user/0. This value does not work since MySQL doesn't run as > root, and so MySQL fails to start after upgrade in such a configuration, > like so: I think I understand the problem. But are you in essence saying that libpam-tmpdir requires that *every maintainer script* that runs things as non-root, or starts processes that do that, unset TMPDIR first? Wouldn't ignoring TMPDIR make it less useful for users who wish to set it for other purposes, since maintainer scripts would stop respecting this? Or, if this universally is the right thing to do, then maybe dpkg should be doing it rather than individual maintainer script? I'd be happy to unset TMPDIR if there's clear consensus that this is what such maintainer scripts should always do, but it isn't clear to me that this is correct. Note that in this case it's the database initialization that's affected, which happens to be done by mysqld running as a daemon, but in a way that is equivalent to it not being a daemon - the task will be complete, with no lingering processes, before the maintainer script exits. In searching all I could find was https://lists.debian.org/debian-devel/2005/02/msg00374.html which is a similar question but doesn't look like it ever concluded. I think the answer to this should probably be established by the libpam-tmpdir maintainer and documented first, for fear of someone else later coming along and saying that the maintainer script incorrectly ignores TMPDIR because we started ignoring it to resolve this bug. So I copied debian-devel@ for comment. Thanks, Robie signature.asc Description: PGP signature
