Re: Validating tarballs against git repositories
On 2024-04-02 11:05, Russ Allbery wrote: Meson honestly sounds great, and I personally love the idea of using a build system whose language is a bit more like Python, since I use that language professionally anyway. (It would be nice if it *was* Python rather than yet another ad hoc language, but I also get why they may want to restrict it.) If Python is what you want, you could use waf, but there is one big downside... You have to repack the upstream tarball: https://wiki.debian.org/UnpackWaf -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Another take on package relationship substvars
On 2024-02-22 12:32, Niels Thykier wrote: I am omitting Breaks, Conflicts, and Replaces because I am not aware of any users of these at the moment. I am open to adding them, if there is a strong use-case. I think you should include them (and Enhances as Sam Hartman mentioned) for consistency. It seems potentially confusing if some of the relationships fields are included and some are not. This proposal sounds generally good. I'll have to defer to others who know more about potential corner cases. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Re: systmd-analyze security as a release goal
On 2023-07-03 14:21, RL wrote: Russell Coker writes: https://wiki.debian.org/ReleaseGoals/SystemdAnalyzeSecurity I think we should make it a release goal to have as many daemons as possible running with systemd security features to aim for a low score from "systmd- analyze security". It would be great if we could get a lintian check for this. The wiki page says, "systemd-analyze now supports working offline" (i.e. it can operate on files in the filesystem rather than talking to systemd about only installed services). Lack of that was previously a blocker for such a lintian check. This repos from Trent Buck has a lot of research - https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/tree/main/systemd/system/0-EXAMPLES Indeed. -- Richard
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
I know I haven't thought about this as much as others, so I might be
naively missing something here.
Is the broader context here that this is an alternative to teaching dpkg
about aliasing? That is, we just arrange the transition correctly such
that we get out of the aliased situation as part of upgrading to trixie?
On 2023-06-09 13:47, Helmut Grohne wrote:
I caution that this protection mechanism of symlinks is a property of
the installation and not of dpkg. Depending on what dpkg is operating
on, we expect it to handle this or not. So we'd need a way to tell
whether an installation needs this kind of special handling.
Because you want to support non-usr-merged systems, e.g. for
derivatives? They aren't going to want to delete /bin either, so I don't
see how a special-case preventing deletion of /bin would be problematic.
On amd64, we'd upgrade libc6 before dpkg and then /lib64 would go
missing, because libc6 already is the last package that ships files in
/lib64.
Am I understanding the problem correctly?
1. src:libc "moves" /lib64/ld-linux-x86-64.so.2 to
/usr/lib64/ld-linux-x86-64.so.2, i.e. it builds bin:libc6:amd64 such
that it ships the latter path.
2. bin:libc6:amd64 gets upgraded before dpkg. The normal unpacking
behavior of dpkg results in /lib64/ld-linux-x86-64.so.2 being deleted
and since /lib64 is now empty, dpkg deletes /lib64.
3. Everything breaks, because /lib64/ld-linux-x86-64.so.2 is special in
the ELF ABI.
What would happen if, for trixie only, bin:libc6 shipped two identical
copies of ld-linux-x86-64.so.2, one in each of /lib64 and /usr/lib64?
Then at step 2, /lib64 does not get deleted and nothing breaks.
Later, whatever replaces /lib64 with a symlink needs to deal with this,
but that's not significantly different than whatever it was going to do
anyway, right? Just do this:
1. Whatever safety checks are appropriate.
2. Unless already verified to be identical by #1, hardlink
/lib64/ld-linux-x86-64.so.2 to /usr/lib64/ld-linux-x86-64.so.2. This
might be just a particular instance of the more general case of hardlink
everything from /lib64 into /usr/lib64.
3. Unlink everything from /lib64.
4. Unlink /lib64.
5. Symlink /lib64 to /usr/lib64
However, note that this cannot be a shell script, as then step 3 would
delete /lib64/ld-linux-x86-64.so.2 and everything after that would fail.
At that point, everything is fine, EXCEPT that dpkg now thinks it has a
/lib64/ld-linux-x86-64.so.2 file installed, but really that is aliasing
/usr/lib64/ld-linux-x86-64.so.2. When bin:lib6:amd64 is later upgraded
(e.g. in forky) to a version that stops shipping
/lib64/ld-linux-x86-64.so.2, dpkg will unlink
/lib64/ld-linux-x86-64.so.2 and then everything breaks.
The fix to that is either whatever separate general case fix is being
done for aliasing, or if the whole point is we are trying to avoid
having that sort of thing at all, then just put in a special case that
dpkg will not unlink /lib64/ld-linux-x86-64.so.2.
So we end up with something roughly like this in dpkg (please excuse
syntax/pointer errors):
Wherever file deletions are handled, make this change:
- unlink(pathname);
+ special_unlink(pathname);
to use this:
char *SPECIAL_PATHS[] = {
"/bin",
"/lib",
"/lib64",
"/lib64/ld-linux-x86-64.so.2",
"/sbin",
NULL,
}
void special_unlink(const char *pathname) {
const char **special;
for (special = SPECIAL_PATHS ; *special ; special++) {
if (strcmp(pathname, special) == 0) {
return;
}
}
unlink(pathname);
}
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
On 2023-06-09 11:26, Helmut Grohne wrote: When upgrading (or removing that package), dpkg will attempt to remove /bin (which in its opinion is an empty directory and the last consumer is releasing it). However, since dpkg has no clue about file types, it doesn't actually know that this is a directory and takes care of the /bin -> /usr/bin symlink using unlink(). And this is where /bin vanishes. Oops. This might be a dumb question, but could we just special-case this? That is, dpkg would simply not remove /bin specifically? If the list of directories is small, known, and relatively fixed (e.g. /bin, /usr/bin, /lib), that might be workable. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: 64-bit time_t transition for 32-bit archs: a proposal
I support transitioning to 64-bit time_t. Thank you for taking this on! Gentoo has a similar migration: https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration They mention, "We likely have to complete Modern C porting first to remove any instances of -Wimplicit-function-declaration otherwise the redirects in glibc for e.g. time->time64 won't actually work." That links to: https://inbox.sourceware.org/libc-alpha/874js2iqlg@oldenburg.str.redhat.com/ Has that issue been considered here? (I can't speak intelligently on it at this time. I just want to make sure it's on your radar.) On 2023-05-16 23:04, Steve Langasek wrote: * For a small number of packages (~80) whose ABI is not sensitive to time_t but IS sensitive to LFS, along with their reverse-dependencies, filter out the above buildflags with DEB_BUILD_MAINT_OPTIONS=future=-lfs[1]. Maintainers may choose to introduce an ABI transition for LFS, but as this is not required for time_t, we should not force it as part of*this* transition. My gut feeling is that this is a mistake. I think Debian should just bite the bullet and force the LFS transition too. First off, it seems that would simplify the planning, as you don't need to determine "[i]f there is a package that depends on both a time_t-sensitive library and an LFS-sensitive but time_t-insensitive library". Furthermore, that state could change in the future. In other words, someone could upload a new package that meets that criteria, which would then force a library to transition at that point. But would that requirement to transition get noticed, or would we end up with subtle breakage? Also, how many separate times would someone have to do those LFS transitions vs just doing it all now in one shot? I know it's not my place to volunteer you/others to do more work. But I worry about doing something half-way rather than just pulling the thread now. Doubly so since it's a relatively small set of additional packages compared to the size of the rest of the transition already being planned. Back to time_t... Application-level workarounds can complicate things... Upstream NTPsec and gpsd had some conversations about the optional 64-bit time_t. They (and other projects) can have a shared-memory connection where the size and layout of the struct varies depending on sizeof(time_t). The glibc optional 64-bit time_t makes that complicated, as it's possible for the two applications to be mismatched. The conclusion we came to (which has been implemented in gpsd, but has not yet been implemented in NTPsec) is to split the time_t and put the high bits into a spot that was reserved/padding, but only in the case where we have optional 64-bit time_t and 32-bit ints. This provides compatibility between modified and unmodified applications until 2038, and modified applications work together thereafter. If you're curious, the relevant subthread is: https://www.mail-archive.com/devel@ntpsec.org/msg09645.html With the Debian transition, we could end up with a mismatch where one side (gpsd) is sized with 32-bit fields and doing the split thing and the other (NTPsec) will be sized with 64-bit time_t, which is incompatible. Whether that happens is dependent on how exactly the applications implement the check to decide to do the split thing. I've raised that question on the gpsd bug: https://gitlab.com/gpsd/gpsd/-/issues/152#note_1395291465 There are certainly solutions to that. In no way am I suggesting that should block the transition. By all means, transition and we will sort things out. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Upgrade package from init script to Systemd, move config folder
On 4/20/23 14:48, Perry Naseck wrote: Hello! I am in the process of updating/upgrading a package from an init.d service to a Systemd service. Are there any recommended guidelines for this process? My generic advice would be: start your thinking from a perspective of "how should this work in systemd anew", not "how do I 1:1 convert the init.d unit". That is, start in a "systemd native" approach. You may need to pull back from that for backwards compatibility reasons, or consistency with the init.d unit or whatever (and I maintain a package that is that way), but make those decisions intentionally. Looking through some current packages I see that a lot of them have both an init script and a Systemd service in their debian folder. Do dh_installsystemd and dh_installinit handle this smoothly by default if both files exist? In my experience, if the files are name the same (i.e. /etc/init.d/foo and /lib/systemd/system/foo.service), everything should Just Work, both in terms of the Debian bits and the systemd bits (discussed below). When upgrading the package on a machine will it stop the init service and start the Systemd service? There is no such thing as an "init service" on a systemd machine. If you have only /etc/init.d/foo, systemd is dynamically generating a foo.service unit. You can see this with e.g. "systemctl status foo". For example, on my system: $ systemctl status openipmi × openipmi.service - LSB: OpenIPMI Driver init script Loaded: loaded (/etc/init.d/openipmi; generated) When you install a foo.service unit file, that will take precedence over the generated one. So (assuming they have the same name), they are the same service. This package also stores its configuration in /var/lib/packagename and it should really be in /etc/packagename. Where is the best place to deal with auto-migration? Should this go in postinst or is there a debhelper that I should use? Take this with a grain of salt, and defer to more knowledgeable folks, but... If I were in that situation, I'd start with the idea of moving it in a preinst script. I would probably also guard it with version checks (as opposed to only checks for the existence of the folder). So something like (where the "2" in version-2~ is the package version one _higher_ than the version where you made the change, i.e. if you changed in -1, use -2~): #!/bin/sh set -e if [ "$1" = "upgrade" ] && [ -n "$2" ] then if dpkg --compare-versions "$2" le-nl "version-2~" then if [ -e /var/lib/packagename ] && ! [ -e /etc/packagename ] then mv /var/lib/packagename /etc/packagename fi fi fi That said, I'm not sure what Policy has to say about this. It seems to me that you want the package to do things right moving forward, and you want to support clean upgrades, so this seems like the approach that gets both of those. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Yearless copyrights: what do people think?
I maintain a package where upstream has dropped the years. I was told that multiple big tech companies with serious lawyers looked at this and felt it was fine. I fully support: - upstreams dropping years from copyright notices - Debian not requiring maintainers to preserve years in debian/copyright files. On 2/22/23 08:39, Sam Hartman wrote: I think our users are better served by knowing when the Debian packaging would enter the public domain. In theory, I agree with you. In practice, copyright lengths are so long in many countries that software effectively never enters the public domain (at least not while it is still of useful/non-historical value). -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Enabling branch protection on amd64 and arm64
On 10/26/22 13:20, Moritz Mühlenhoff wrote: Wookey wrote: So the immediate issue now is whether or not to enable this by default in bookworm? The majority of packages will not be rebuilt until the release How hard would it be to rebuild everything? I don't actually know what facilities Debian has for that. Would it be a binNMU of everything? -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: application tool
On 9/8/22 23:07, Qx wrote: 1)i have coded a tool which I would like to release for ubuntu. Can someone please advice as to how this is correctly done? You sent this to a Debian list. If you want to package the software for Debian (which will then flow downstream into Ubuntu), start with the Debian New Maintainer's Guide: https://www.debian.org/doc/manuals/maint-guide/ 2)I would like to become a motu member/contributor. That's a question for the Ubuntu folks. But, as some general suggestions, you will probably want to A) package software, and/or B) contribute fixes to existing packages. -- Richard
Re: Python installation paths
On 6/2/22 14:15, Alec Leamas wrote: Hi Audrey On 02/06/2022 20:16, Andrey Rahmatullin wrote: On Thu, Jun 02, 2022 at 07:19:56PM +0200, Alec Leamas wrote: Dear list, I try handle a package which installs a partly compiled, architecture-dependent python module. Until now this has been done in /usr/lib/triplet/python3.10/site-packages. This scheme has basically worked fine. However, here is an Ubuntu bug [1] where a user runs into problems because this installation path is not in sys.path by default. I have been trying to look in the python policy docs, but cannot find the exact way to install code like this, in the policy [2] parlance an "extension module". Not sure where is this documented but you can easily check on your system. It should be /usr/lib/python3/dist-packages/*.cpython-3*-x86_64-linux-gnu.so Hm...this is not what I have. Did I get get the term "Extension module" wrong? There are a couple different ways to do Python to C. I think the terms are CFFI (or FFI or ctypes, maybe some of those are different though?) vs CPython extension, but I'm not 100% certain of that. I maintain the ntpsec package. IIRC, upstream is transitioning (but I think still supports both at the moment). On an older version, I had this (from the python3-ntp binary package): /usr/lib/python3/dist-packages/ntp /usr/lib/python3/dist-packages/ntp/__init__.py (other .py files omitted) /usr/lib/python3/dist-packages/ntp/ntpc.cpython-38-x86_64-linux-gnu.so I believe that is the extension approach. I think the way this works is that if you import ntpc, it imports the .so. Note that there is no ntpc.py. On newer python3-ntp, using the FFI approach, I have this: /usr/lib/python3/dist-packages/ntp/__init__.py /usr/lib/python3/dist-packages/ntp/ntpc.py (other .py files omitted) /usr/lib/x86_64-linux-gnu/ntp/libntpc.so /usr/lib/x86_64-linux-gnu/ntp/libntpc.so.1 /usr/lib/x86_64-linux-gnu/ntp/libntpc.so.1.1.0 In this approach, ntpc.py has explicit code to load libntpc.so from /usr/lib/x86_64-linux-gnu/ntp/ (that path being subst'ed in to ntpc.py by the build process). I hope that helps. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Adding epoch to node-markdown-it to correct a wrong upstream version
On 5/19/22 05:42, Pirate Praveen wrote: So current version in the archive is 22.2.3+dfsg+~12.2.3-1 The fixed version we want is 10.0.0+dfsg+~cs16.6.17-1 I have no dog in this fight as they say, but... How fast does upstream bump versions? With a 10.x, I wonder if it might be relatively frequently. Would they likely exceed 22 in the near future? If so, you might just do 22.3+really10.0.0+dfsg+~cs16.6.17-1 and when they get to 23, it goes back to normal, without the epoch. -- Richard
Re: Advice for package needing stuff installed in /srv (node-shiny-server)
On 4/27/22 12:57, Nilesh Patra wrote: I am looking for more opinions. Patch every instance of /srv/shiny-server to /var/lib/shiny-server. The admin can customize from there. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
If you use ntp, I would appreciate if you could test the transition to ntpsec. ntpsec 1.2.1+dfsg1-5 has been uploaded to experimental and cleared the NEW queue. Bernhard Schmidt suggested and I used 1:4.2.8p15+dfsg-2~$(DEB_VERSION_UPSTREAM_REVISION) as the version for the transitional packages. The first part (before the ~) is the current src:ntp version, but with the Debian revision bumped from 1 to 2. This allows for potential security or stable fix uploads to existing Debian releases, if needed. Barring bugs, I believe the next steps are: 1. Upload to unstable. 2. Request ftpmaster removal of src:ntp? -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: proposed MBF: packages still using source format 1.0
On 3/15/22 10:36, Ian Jackson wrote:
Lucas Nussbaum writes ("Re: proposed MBF: packages still using source format
1.0"):
As explained in https://lists.debian.org/debian-devel/2022/03/msg00165.html
I proceeded with the MBF for packages that match
not (debian_x or (vcs and vcs_status != 'ERROR' and direct_changes))
or, maybe easier to read:
(not debian_x) and ((not vcs) or vcs_status == 'ERROR' or (not direct_changes))
I did not file bugs for packages that are likely to use a VCS-based
workflow (category (2) in the mail pointed above, or in
https://udd.debian.org/cgi-bin/format10.cgi)
At least the following packages of which I am the maintainer or
sponsor were includined in the MBF, despite the fact that they are 1.0
native packages with Debian revision:
its-playback-time
spigot
vm
vtwm
chroma
I picked one of these, spigot, at random.
Clearly the it aakes no sense to have filed bugs saying "please switch
to this other source format" when the other source format cannot
represent the package.
I don't see any reason that 3.0 can't represent the spigot package. It
looks like a straightforward package. It seems to have an upstream:
The top changelog entry says "Merge from upstream".
debian/control points me to:
http://www.chiark.greenend.org.uk/~sgtatham/spigot/
That site has a tarball available. The Debian package is NOT using that
as its .orig.tar.gz. It doesn't have a .orig.tar.gz, presumably
indicating it was built built as a native package (even though it has a
Debian revision), which is the issue under discussion. To be honest, had
I stumbled across this package outside of this conversation, I would
have been confused by this.
My understanding is that Debian values the idea of using the pristine
upstream tarball. Granted, sometimes that goal has to yield to higher
priority things, like DFSG compliance.
How do you feel about the pristine tarball concept?
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Re: Seeking consensus for some changes in adduser
On 3/9/22 23:47, Marc Haber wrote: On Wed, 9 Mar 2022 14:35:52 -0600, Richard Laager wrote: If the admin can change the default DIR_MODE that applies to system user home directories, then any postinst script doing `adduser --system` needs to also explicitly chmod its home directory if it needs anything more permissive than 700 or more restrictive than 755. This is true today and remains true whether or not the default DIR_MODE is changed. Anything that NEEDS to be written in postinst scripts is bad. I'd rather implement a SYSTEM_DIR_MODE setting that applies to directories created during creation of a --system user. Would that help with the issue? Yes that would _help_, as that would allow the system administrator to change DIR_MODE without changing SYSTEM_DIR_MODE. However, if SYSTEM_DIR_MODE is configurable, you end up with the same problem: unless a given package can work with _any_ reasonable mode (700 to 755), it must explicitly set its own mode. Otherwise, if the administrator sets SYSTEM_DIR_MODE to something too restrictive (scenario A below), some packages will break; if they set it too permissive, some packages will become insecure (scenario B). Having a hardcoded default for system users would at least allow packages certainty, and those that were happy with the default would not need to chmod. Further, my assumption is that there are two different scenarios: A) The system user's home directory needs to be open. For example, if there is a socket in there that needs to be world-writable, which I think you were talking about. B) The system user's home directory needs to be private. For example, there is sensitive data in there. (Another, perhaps better, answer is that the _files_ should have restricted permissions.) _If_ it is the case that both of these scenarios exist, then no single value (default or hardcoded) can satisfy both. So the default should either be the most common mode, or the most restrictive (reasonable) mode. This should probably be my last email on this subtopic. Hopefully I've conveyed my points for your consideration. I don't feel that I'm an expert on the use of system users in Debian. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Seeking consensus for some changes in adduser
On 3/9/22 14:00, Marc Haber wrote:
On Tue, 8 Mar 2022 17:02:06 -0600, Richard Laager
wrote:
On 3/8/22 10:49, Marc Haber wrote:
(1a) would it be necessary to handle --system accounts differently? I
think yes. > (1b) should we stay with 0755 for --system accounts?
I don't see why system accounts need to be different.
avahi-daemon has /var/run/avahi-daemon as its home directory and
places its socket there. I'd guess that having this directory not
accessible for the world will kind of influence the usability of the
daemon. We have many packages that are configured like that.
dnsmask even has /var/lib/misc as home, which is not even owned by the
account, so setting that one to 0750 would probably be even more
destructive.
Having thought about this some more:
If the admin can change the default DIR_MODE that applies to system user
home directories, then any postinst script doing `adduser --system`
needs to also explicitly chmod its home directory if it needs anything
more permissive than 700 or more restrictive than 755. This is true
today and remains true whether or not the default DIR_MODE is changed.
How would chown handle the dot case intelligently?
Something along the lines of see if the user exists.
If I was to take a stab at an implementation (Python-ish pseudocode
here; yes I know chown is C):
group = None
if ':' in arg:
(user, group) = arg.split(':')
elif '.' in arg:
# This could be:
# user.group
# us.er.group
# user.gr.oup
# us.er.gr.oup
# Or user and/or group could have multiple dots.
# Idea A) Exactly one dot can mean either user.group or us.er
arg_split = arg.split(',', 2)
if len(arg_split) == 3:
# There was more than one dot.
user = arg
else:
# Split on dot.
(user, group) = arg.split('.')
if not getent(user):
# Treat the whole thing as a username.
user = arg
group = None
# Idea B) Loop over each possible split and see if any work.
# Exercise for reader.
else:
user = arg
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Re: proposed MBF: packages still using source format 1.0
On 3/9/22 10:38, Ian Jackson wrote: This prohibition exists solely because of a doctrinal objection to native-format packages with Debian revisions. As I understood it, the idea was that you could just increment the "actual" version number. I'm failing to see the advantage of incrementing "a" vs "z" in something like x.y.z-a. There's not really a disadvantage either, if it all works (which you said it does). But the doctrinal issue, I think, is that definitionally a native package has no Debian revision (corollary: a package with a Debian revision is non-native). If we revise that definition, to allow Debian revisions in native packages, then what distinction is left between native and non-native packages? Could we only have "3.0 (quilt)" then, no "3.0 (native)"? Or, put differently, if you had a "native" package that is using a Debian revision and we allow that, what difference is left between "3.0 (native)" and "3.0 (quilt)"? To be clear: I genuinely don't know. I'm not implying that there isn't a remaining difference. IMO there is nothing wrong with native format packages with Debian revisions. They work just fine. For a small paockage, this is often a good choice, because it avoids dealing with patches at all. I don't follow the "avoid dealing with patches at all" piece here. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Seeking consensus for some changes in adduser
On 3/8/22 10:49, Marc Haber wrote: (1) #202943, #202944, #398793, #442627, #782001 The bug reporters are requesting the default for DIR_MODE to be changed from 0755 to 0700, making home directories readable for the user only. Policy 10.9 states that directories should be 0755, but the policy editors probably didn't have user home directories in mind when they wrote that. As a data point, Ubuntu moved to 750 a year ago: https://ubuntu.com/blog/private-home-directories-for-ubuntu-21-04 At my day job, we then followed that across the board (despite not yet being on an Ubuntu release where the change was made), and it was essentially fine. We already considered home directories on our file server to be "private", and on everything else, there are only accounts for admins (who can use sudo in the rare event they need a file from someone else's home directory). (1a) would it be necessary to handle --system accounts differently? I think yes. > (1b) should we stay with 0755 for --system accounts? I don't see why system accounts need to be different. (1c) does a change to 0700 for user accounts make sense? Yes. (1d) should it be 0751 (#398793)? Pro: That helps ~/public_html. Con: That seems like a trap for non-expert users. It _feels_ like other people can't get at things, but they actually can, if they know the next directory down. I (and probably everyone reading this list) understands the "1" in 751, but do end users? (1e) how about ~/public_html that would break with 0750? As a comment on the bug mentioned, public_html not a default thing. Changing DIR_MODE and/or ACLs are also options for those who want a ~/public_html concept. All those bugs referenced have more or less heated exchanges ranging from "it's fine" to "we should issue a DSA ASAP", most of them a decade old, so the times might have changed since then. Please note that the DIR_MODE _IS_ configurable in adduser, we're just discussing the default (which also applies for home directories created while still inside the Installer before a local admin can properly configure adduser). I think there is merit to defaulting to the most secure (but still reasonable) option, and letting people loosen it if desired. (2) #774046 #520037 Which special characters should we allow for account names? People demand being able to use a dot (which might break scripts using chown) and non-ASCII national characters in account names. The regex used to verify non-system accounts is configurable, so the policy can be locally relaxed at run-time. For system-accounts, I'd like to stick to ASCII letters, numbers, underscores. I support dashes, as was already discussed. That's already in use. I think the idea of dot in a username is perfectly reasonable on its own. For some people this is very desirable. My wife, for example, uses a dot in her email username as her first name plus my-now-her last initial makes a word that is awkward. (This sort of problem is not uncommon in usernames, especially at companies that make them via some algorithm.) I always use colon for chown, which is what is documented, but I'm aware it takes dot too. Is there any code in chown to handle the dot case intelligently? Non-ASCII does feel a little concerning to me (since those code paths won't be exercised very often). But to recognize my bias, I have no need for a non-ASCII username. I'd probably feel quite differently if my name wasn't correctly representable in ASCII. Put differently, if usernames were currently required to be Han or Cyrillic characters, I'd certainly be up in arms asking for Latin character support. On the other hand, Debian probably can't go it alone here. If, as people have mentioned, systemd isn't going to support those usernames, there's not much point in adduser allowing them. (3) #625758 --disabled-password just does not set a password for the newly created account (resulting in '*' in shadow) while --disabled-login places a '!' in shadow. On modern systems with PAM, both variants seem to be identical, allowing login via ssh. Aside from the documentation needing change to document reality Simon McVittie's explanation matches my understanding of what the current behaviors of '*' and '!' are (but I haven't tested the empty password nuance). While I get the general idea of locking in a way that allows unlocking later (and keeping the original password hash), I don't see --disabled-login as being particularly useful for adduser, since it leads to an identical result as --disabled-password. should we introduce a --no-set-password option and deprecate the two older options (to be removed in trixie+2)? I wouldn't add another option. I think --disabled-password is fine. Just keeping that reduces the amount of change people need to make. I'd probably just document --disabled-login as being deprecated and functionally equilvalent to --disabled-password. (4) #979385 #248130 The default f
Re: The future of src:ntp
On 1/19/22 15:04, Bernhard Schmidt wrote: On 19.01.22 20:34, Richard Laager wrote: 2. I create transitional binary packages in src:ntpsec: I got to thinking about this more. This won't work, because src:ntp is 1:4.2.8p15+dfsg-1 and src:ntpsec is 1.2.1+dfsg1-2. I would need an epoch (of 2, since ntp already has an epoch of 1) on ntpsec in order for src:ntpsec's transitional bin:ntp package to be newer than src:ntp's bin:ntp package. It might be technically possible to build a binary package with different versioning, but even if it is: 1) I don't know how, and 2) I'm not sure whether that's a good idea, especially compared to the alternatives. What do you think about the other approach of having src:ntp build the transitional packages? I think that looks like this: 1. I split out ntpdig, as suggested in #1003966. This is presumably ntpsec-ntpdig for consistency with the rest being ntpsec-*. 2. You (or I adopt and) create transitional binary packages in src:ntp, as 1:4.2.8p15+dfsg-2, 1:4.2.8p15+fake, 1:4.2.8p15+transitional, 1:4.2.8p16~transitional, or something else > 1:4.2.8p15+dfsg-1, with an empty upstream tarball: ntp -> ntpsec ntp-doc -> ntpsec-doc ntpdate -> ntpsec-ntpdate sntp -> ntpsec-ntpdig with an sntp -> ntpdig symlink 3. Upload that to experimental. People review. 4. Upload to unstable. 5. After bookworm releases, you (or I, if I adopted src:ntp) request removal of src:ntp. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: using epoch to repair versioning of byacc package
On 1/23/22 10:04, Thomas Dickey wrote: In #1003769, Andreas Metzler wrote: 1. The upload introduces an epoch because the upstream version went from mmdd to 2.0.mmdd. Given that the new version scheme seems to have found acceptance in e.g. Fedora /I/ do not see a better way. Could you ask about the epoch on debian-devel (as per policy https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly ) - TIA. As background, byacc was packaged by Dave Becket in 2005, switching to my ftp area as upstream. In doing that, the versioning of the package changed: from -- LaMont Jones Fri, 26 Nov 2004 18:49:09 -0700 byacc (1.9.1-1) unstable; urgency=low to -- Dave Beckett Sun, 14 Aug 2005 10:14:12 +0100 byacc (20050505-1) unstable; urgency=low I see no other way to correct this but to add an epoch. As we see in this case, switching from version numbers to date-based versions is dangerous because it's impossible to go back without an epoch. A better version would have been something like 1.9.1+20050505. Lintian flags on this, but (according to the name and description) only for new packages: https://lintian.debian.org/tags/new-package-uses-date-based-version-number Personally, I'd like to see that lintian check fire if the date-based versioning is new. That is, it should fire if the previous changelog entry did not have a date-based version. Even better would be a dak (or whatever ftp-master tool is relevant) hard fail if going from non-date-based to date-based at the front of the version string. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
On 1/20/22 8:04 AM, Thomas Goirand wrote:
On 1/19/22 20:34, Richard Laager wrote:
For people that want something more than systemd-timesyncd, e.g. to
get NTS, I think either are acceptable choices. It seems that the
consensus for new installs is towards chrony over ntpsec. But I don't
think we as the distro need to push either over systemd-timesyncd. For
people who don't care, systemd-timesyncd should be fine.
Do you disagree on that point (that systemd-timesyncd is fine for
people who don't care about NTP)? If so, can you elaborate?
Well, could you elaborate why you didn't write "chrony is fine for
people who don't care"?
Because that question is about changing the status quo, where
systemd-timesyncd is the default.
I fail to understand why you're having a
preference on systemd-timesyncd...
Let me separate the two scenarios:
A) Imagine we had no NTP support by default and we are considering
adding NTP support to the default install.
B) systemd-timesyncd is currently the default and we are discussing
whether it should be changed.
In both scenarios, I assume that most users don't particularly care
about their NTP daemon. They don't generally interact with it. They just
want their clock to be "accurate enough". (And for people who don't
care, "accurate enough" is pretty wide. If you need extremely precise
time, you presumably know that and thus care about things like NTP or
even PTP.) This is no different than other system components: some
people have preferences (sometimes strong ones) about certain
components, but essentially nobody cares about every single one.
In scenario A, any of chrony, ntp, ntpsec, or systemd-timesyncd will
achieve the desired objective of having an accurate enough clock by
default. So we would consider other things, for example:
One might say ntpsec > ntp, because ntpsec comes from the same history
(so has the same advantages) plus the codebase has been cleaned up
(which has security and maintainability advantages). Also, the ntp
maintainer wants to discontinue maintaining it.
One might say that chrony > {ntp, ntpsec, systemd-timesyncd?} because
chrony is more accurate. FWIW, I can't personally weigh in on that
argument, as I haven't researched it well enough myself.
One might say that systemd-timesyncd > {chrony, ntp, ntpsec} because
it's part of systemd, which we're already using by default.
One might say that {chrony, ntpsec} > systemd-timesyncd because they
support NTS. Of course, there are problems with configuring NTS by
default, as I mentioned.
These, and potentially other factors, would need to be weighed.
Different individuals might come to different conclusions.
In scenario B, it's the same calculation, PLUS we need to overcome the
inertia of the current default. The new default must be sufficiently
better to be worth the change.
Personally, my take is:
It's not practical to deploy NTS by default right now. If we had
multiple operators of geo-diverse, high-capacity, non-smeared (or
consistently smeared and a consensus that this was desirable by default)
NTS servers, that'd be different. So NTS is not currently a
consideration for the default.
systemd-timesyncd is good enough for people who don't particular care
about their NTP daemon. For people that do care, they are free to
install software of their choice, be that chrony or ntpsec.
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Re: The future of src:ntp
On 1/19/22 3:13 PM, Bernhard Schmidt wrote: I agree we should have a look at this (either ntpsec or chrony, both do NTS), but I think this should be done completely independently of the ntp.org->ntpsec migration. +1 that promoting NTS is orthogonal. If the bigger problems below are solved, it's also theoretically possible to add NTS support to systemd-timesyncd. - AFAIK there is no pool.ntp.org (or similar) service only containing NTS enabled timesources yet. This is the most serious problem. As the world stands right now, we'd have to do something like use CloudFlare's NTS service (and only them). I don't know how it would work either, since you need to verify the peer with a standard X.509 certificate and you don't know the expected CN from a DNS RR NTS does referrals, so it is theoretically possible for the NTS server to hand you off to a pool of NTP servers, with which it is coordinating keys. AFAIK, nobody has implemented this yet, outside of maybe CloudFlare's internal thing (but I don't recall off the top of my head). - Since NTS leverages X.509, how does it work with a broken clock on boot that is ticking outside of the certificate validity period? This is a concern too. I did some brainstorming about this on the NTPsec list a couple years ago, but neither I nor anybody else has implemented this (nor do I have plans to do so myself): https://lists.ntpsec.org/pipermail/devel/2019-February/007576.html -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
On 1/19/22 9:49 AM, Bernhard Schmidt wrote: AFAICT other than systemd-timesyncd being installed by default we don't have a "default" NTP daemon in Debian. I'm not sure how much more "default" it can be than installed by default. So I'd say we do have a default: systemd-timesyncd. So we should most probably decide on a "default" and have all of them changed to $newdefault | time-daemon +1, except that my position is we already have that answer: systemd-timesyncd | time-daemon As default both ntpsec and chrony are challengers. For people that want something more than systemd-timesyncd, e.g. to get NTS, I think either are acceptable choices. It seems that the consensus for new installs is towards chrony over ntpsec. But I don't think we as the distro need to push either over systemd-timesyncd. For people who don't care, systemd-timesyncd should be fine. Do you disagree on that point (that systemd-timesyncd is fine for people who don't care about NTP)? If so, can you elaborate? And then there is the migration from src:ntp. I think only ntpsec would be an option here Agreed (as I stated already; just agreeing here again). sntp could depend on on the ntpdig package from #1003966, but it would probably need to carry a compatibility symlink Good point. ntpdate and ntp could be transitional packages on the ntpsec counterparts as well, but since ntpsec/ntpsec-ntpdate has Conflicts/Replaces on the src:ntp binary packages it needs coordination. For this reason building the transitional binaries from src:ntpsec would probably be easier. Sure. How do we feel about this process then: 1. I split out ntpdig, as suggested in #1003966. This is presumably ntpsec-ntpdig for consistency with the rest being ntpsec-*. Maybe upload this at this step, to start the NEW process. 2. I create transitional binary packages in src:ntpsec: ntp -> ntpsec ntp-doc -> ntpsec-doc ntpdate -> ntpsec-ntpdate sntp -> ntpsec-ntpdig with an sntp -> ntpdig symlink 3. Get a review from you (Bernhard) if you're willing? 4. Upload. 5. Then Bernhard requests ftpmasters remove src:ntp. Is that how that works? Can be done in any order: N. Mass bug filing on that list of packages, that they should use: Depends: systemd-timesyncd | time-daemon If we're going to promote chrony instead, then I think we need some more discussion and there would be more work, as it seems we should then replace systemd-timesyncd with chrony in default installs too. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: The future of src:ntp
[I'm the Debian ntpsec maintainer.] On 1/18/22 11:21 AM, Paride Legovini wrote: > I'd prefer making ntp a dummy package depending on ntpsec rather than > having src:ntpsec takeover bin:ntp. If I understand correctly, you're suggesting src:ntp builds bin:ntp that is a dummy package which depends on ntpsec? Another option would be to have src:ntpsec build the bin:ntp dummy package and remove src:ntp entirely. Either seems fine to me. I don't have a strong preference. I can implement whatever is necessary on the ntpsec side. And for either option, probably likewise ntp-doc -> ntpsec-doc, ntpdate -> ntpsec-ntpdate, and if I broke out ntpdig as suggested in bug #1003966, sntp -> ntpsec-ntpdig. There are some differences. For example, ntp stores its configuration file at /etc/ntp.conf while ntpsec uses /etc/ntpsec/ntp.conf. [1] But bin:ntpsec's postinst already handles that transition. On 1/18/22 5:03 PM, Paride Legovini wrote: > bin:ntp has always been a specific NTP implementation, I think > it's OK if it's replaced by an almost compatible fork, less OK if a > completely different implementation is brought in instead. I'm biased here, but I agree. I think it makes the most sense to transition existing ntp installs to ntpsec, not chrony, as ntpsec is a drop-in replacement with a shared code history. This is my position even if we think that chrony should be the default for new installs. On that topic, I think the current default of systemd-timesyncd is fine. [1] When I was first packaging ntpsec, I was going to have it share as many paths, service names, etc. with ntp (as upstream NTPsec does). But this lead to issues with certain tooling (e.g. around init scripts) and ultimately I decided it was better to use a different namespace. This does mean that Debian ntpsec is patched and diverges a bit from upstream NTPsec. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: merged-/usr transition: debconf or not?
On 11/17/21 8:18 PM, Zack Weinberg wrote:
However, I think it was the responsibility of the developers of usrmerge
to find out how bad that problem actually was, rather than dismissing it.
And, as it has proven to be a genuinely critical problem, it is also their
responsibility to fix it, per the 'no one can be forced to do anything' rule.
At least for this email, I'll stipulate to everything above.
Is this particularly hard to fix, though?
Can't we just do something like the following pseudo-code:
/* At dpkg start... */
usrmerged = FALSE;
if (the_flag_is_set) {
usrmerged = TRUE;
} elif (bin symlinked to /usr/bin) {
usrmerged = TRUE;
/* Update e.g. /bin/foo to /usr/bin/foo in the database. */
update_database();
set_the_flag();
}
/* As dpkg is deciding to write a file path into the database. */
/* e.g. the package is trying to install to /bin/foo, put
* /usr/bin/foo into the database. */
if (usrmerged) {
path = canonicalize(path);
}
(I've used /bin -> /usr/bin as an example, but the canonicalization must
deal with the other merged paths too.)
The second bit ensures that all new operations write canonicalized paths
(e.g. /usr/bin/foo) into the database regardless of whether the .deb
shipped with /bin/foo or /usr/bin/foo. This ensures the database stays
in sync with the filesystem moving forward.
The first bit performs a one-time canonicalization of paths in the
existing database. An on-disk flag ensures that this is run only once
(for performance reasons only, because it's already idempotent). This
corrects the existing database-filesystem mismatch.
The one-time canonicalization can be removed once non-usrmerged systems
are no longer supported. The second bit needs to live (probably a lot)
longer, until it's no longer reasonable to install a .deb containing
non-usrmerged paths (which might be old or from a third party).
Am I missing something here?
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Re: Crypto Libs: Linking to OpenSSL, GnuTLS, NSS, ..?
On 11/11/21 1:23 PM, Michael Biebl wrote: Nowadays I'm not so sure anymore, e.g. I'm even considering disabling GnuTLS support in librelp. Just wondering if anyone would object to such a change? I would not. I force OpenSSL anyway. That is at least in part so we can use tls.tlscfgcmd to set CipherString, Ciphersuites, and MinProtocol per $DAYJOB's general TLS policy. It may also be because of issues with GnuTLS, I can't remember (and my comments/config messages don't indicate that). -- Richard
Re: dash and hidden bashisms in configure scripts
On 11/10/21 12:50 PM, Andrej Shadura wrote: On Wed, 10 Nov 2021, at 19:18, Sam Hartman wrote: I understand that it's generally better to fix bashisms in configure scripts. Is it possible to force autoconf to prefer bash for a given configure script if it's difficult or undesirable to fix bashisms in a configure script? Yes, passing CONFIG_SHELL=/bin/bash to configure with do the thing. Can we just enable LINENO in dash then, let the other packages FTBFS, and people who care about the packages that FTBFS can either: A) Fix the bashisms, or B) Add CONFIG_SHELL=/bin/bash to their ./configure invocation. bash is currently Essential, so there's no need for a Build-Depends on bash for option B right now. A might be easy, and B is definitely trivial. It sounds like there are real benefits to enabling LINENO in dash. LINENO support is apparently required by POSIX, so this fixes dash in that regard (582952 comment #10) and for those packages using autoconf without bashisms, dash will speed them up (842242 comment #5). Bug #582952 (the first time LINENO was enabled in dash) was from 2010. I understand reverting the change to dash if it was near a release. But that's not the case right now and at this point, it's been ELEVEN YEARS. It's time to move forward. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Not running tests because tests miss source code is not useful
On 10/7/21 11:35 AM, Russ Allbery wrote: Richard Laager writes: I haven't looked into the specifics of this situation, but in general, tests should be run against the same versions of dependencies that the actual code will use, for what should be obvious reasons. If Debian has the dependencies with different API versions, then it's all the more important that the tests run against the Debian versions of the dependencies. I believe the dependencies in question are test dependencies. In other words, they're dependencies required to drive the test suite machinery, not dependencies of the code under test. Thanks for the clarification of the specifics! In that case, I personally don't see a big problem with them being vendored as opposed to using system copies. But AFAIK, they do still need to be DFSG-free to be in main if they are in the source tarball. And I personally would not consider minified JS (if that is indeed at issue here) to be "source code". -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Not running tests because tests miss source code is not useful
On 10/7/21 4:40 AM, Pirate Praveen wrote: What you are proposing would require the package maintainer to adapt these tests to versions available (many times with different API versions) in Debian and the easier choice is disabling tests. I haven't looked into the specifics of this situation, but in general, tests should be run against the same versions of dependencies that the actual code will use, for what should be obvious reasons. If Debian has the dependencies with different API versions, then it's all the more important that the tests run against the Debian versions of the dependencies. Running tests against vendored dependencies one isn't going to use at run-time is of limited usefulness. Presumably upstream is already running those tests against the vendored dependencies, so the odds of Debian finding breakage in the _source_ at packaging time is low. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#995189: RFH: isc-dhcp
On 9/28/21 11:49 AM, Vincent Bernat wrote: ❦ 28 September 2021 11:16 -05, Richard Laager: As to what should be the distro default, I'm not sure I am convinced either way, but to argue the other side... There is some value in using netplan by default. Some random thoughts: [...] OTOH, netplan is just an abstraction above existing systems Agreed. and does not allow proper reconfiguration. What do you mean? Make a change, reload your configuration, everything breaks. Are you saying "everything breaks" as in: A) the change is not applied (correctly) in the way that it would be if the system was rebooted, or B) the change is applied, but the human made a mistake in the config and the change breaks things, or C) B + the human gets cut off from e.g. SSH due to the error? I would say (generally) that A is a bug, B is inherent to any tooling applying a human's instructions, and C can be addressed by a rollback function. `netplan try` covers C (and thus also B). `netplan apply` (and thus `netplan try`) have a caveat that they don't remove virtual devices that are no longer described in the config. This feels like an example of A, though it's arguable how much it matters. ifupdown2 is smart and will converge to the new configuration. Network Manager can restart and minimize impact. AFAIK, systemd-networkd is as dumb as ifupdown and does not know how to converge. What does converge mean in this context? Is something needing to apply parts of the changes iteratively to arrive at the desired state? My point is that ifupdown2 was a possible successor to ifupdown but was never adopted because written in Python. As netplan is written in Python, ifupdown2 seems a far better replacement. Am I understanding correctly that ifupdown2 is an alternative to systemd-networkd and NetworkManager (as opposed to netplan, which is a layer on top of them)? Can you articulate why ifupdown2 is better than e.g. systemd-networkd + netplan? I'm not looking for an exhaustive comparison or anything, but just a brief statement or two if you're willing? I've never used it, and if it's better than systemd-networkd + netplan, I might consider switching. -- Richard
Re: Bug#995189: RFH: isc-dhcp
On 9/28/21 8:44 AM, Vincent Bernat wrote: ❦ 28 September 2021 01:29 -05, Richard Laager: As to what should be the distro default, I'm not sure I am convinced either way, but to argue the other side... There is some value in using netplan by default. Some random thoughts: [...] OTOH, netplan is just an abstraction above existing systems Agreed. and does not allow proper reconfiguration. What do you mean? -- Richard
Re: Bug#995189: RFH: isc-dhcp
On 9/27/21 9:15 PM, Marco d'Itri wrote: On Sep 28, Noah Meyerhans wrote: Should it be mentioned what the new recommended DHCP server for general use will be? ISC Kea? I haven't converted to it, but that's their replacement for dhcpd. I think that a good default would be systemd-networkd for servers and NetworkManager for systems with Wi-Fi or a GUI. That seems reasonable. I don't think we should install something like netplan by default. I agree: it only adds complexity. I personally use netplan everywhere. As to what should be the distro default, I'm not sure I am convinced either way, but to argue the other side... There is some value in using netplan by default. Some random thoughts: This default would match Ubuntu. (I value reducing that delta. Not everyone does, and that's fine.) netplan can configure both systemd-networkd and NetworkManager (though I've only used it with systemd-networkd). In my non-trivial configurations, the netplan YAML input is half as many lines as its networkd output. This is with the input including a bit of comments and the boilerplate, disabling dhcp, and using YAML's more verbose list syntax (separate lines vs one line). I don't see anything wrong with its output that I could simplify. Again, in this non-trivial configuration, I think it's more useful to have one netplan YAML file than 24 separate networkd files. This is especially true when I'm building this file from an Ansible template and most of it (by volume) is built by loops. In the trivial case, it's 19 lines of netplan (16 if you exclude the stock comment) vs 25 lines of systemd-networkd, both in single files. That's not a huge difference. -- Richard
Re: next steps after usrunmess
On 8/27/21 10:20 AM, Theodore Ts'o wrote: Does someone need to create patches to dpkg which attempt to teach it that /bin/foo and /usr/bin/foo are the same file, if there exists a symlink from /bin to usr/bin? Yes. I can't speak to the dpkg internals, but conceptually, this seems like the right thing to do. Even if we eliminated usrmerge entirely, I'm not sure what's harmful about dpkg canonicalizing filenames. In fact, it seems very much like the right thing to do. So unless the patch is very invasive, I don't see why one would object to this change on its own. And then with some kind of process, maybe with the blessing of the technical committee, upload it as an NMU over the objections of the dpkg developers if they continue to refuse to engage with solutions that proceed forward with /usr-unification? Yes. If the dpkg maintainer does not accept a reasonable patch, then this may need to be presented to the TC to overrule him, which requires a 3:1 TC majority. One might argue the existing TC decision implies this, but the least ambiguous procedural option would be to have the TC explicitly overrule the maintainer once a specific implementation is available. It is my view that the usrunmess utility also needs to be dropped before the bookworm release. That quite clearly follows from the existing TC decision, which is that only the merged-usr layout is supported, so I don't think that needs further TC action. However, I think removing that utility should wait until such time as we have the other issues reasonably resolved. Should a single DD have the power to overturn a techical committee because they are the maintainer of a highly important package? No. This is settled in the Debian constitution. If a DD wishes to override the TC, they need to propose a GR. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: What are desired semantics for /etc/shells?
On 6/14/21 7:39 AM, Helmut Grohne wrote: At this time, my personal preference would be turning /etc/shells into a symbolic link to an autogenerated file. Is there a harm in /etc/shells containing shells that are not installed on the system? If not, then we could ship a single /etc/shells in base-files and be done with it. The file would only need to change when a new shell is packaged for Debian, which is infrequent; such a change would be trivial to make. One downside would be that third-party repositories, e.g. for a new shell, could not add to /etc/shells, in a policy-compliant way. That said, Debian Policy is not binding on them anyway. If it _is_ harmful for /etc/shells to reference shells that do no exist, then maintaining the list automatically (by whatever mechanism, including the current approach but fixing the bugs) makes sense. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Epoch bump for kernelshark
On 5/23/21 8:34 AM, Sudip Mukherjee wrote: And, as a result, upstream kernelshark is now at v2.0 but the Debian packaged version is at v2.9.1 and I will need to add an epoch to the version to package it directly from its new upstream repo. Current version: 2.9.1-1 Proposed version: 1:2.0-1 How close is upstream to 3.0? If not close, are they willing to bump to 3.0 anyway to avoid this versioning issue? -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: DEP-14 update, second attempt
On 11/29/20 10:11 AM, Paride Legovini wrote: > I tried to do a synthesis of past August/September thread on the > finalization of DEP-14 [1], see: > > https://salsa.debian.org/dep-team/deps/-/merge_requests/1/diffs This all looks great to me! > I tried to stick to what I believe we had consensus on, however I think > that point (3) has a shortcoming: it allows / branches, > but doesn't cover cases where has no development _suite_. For > example it wouldn't allow the kali/kali-dev branch, as Kali doesn't have > suites (IIUC). This case could be covered by adding: > > However, when `` has no concept of suite for the > development release but has a fixed codename for it, the > use of the `/` scheme is accepted. Assuming the acceptance of the other text, I think the consensus is that kali/kali-dev is perfectly fine. I'm not sure if additional text is necessary to clarify this, especially since this isn't actually binding on Kali anyway. But at the same time, I have no objection to that additional text either. -- Richard signature.asc Description: OpenPGP digital signature
Re: Proposed changes to sbuild and debootstrap
On 11/29/20 1:33 PM, RhineDevil wrote: > A viable solution for achieving this may be using an optional -f/--flavour > parameter Is flavour intended to be something like Debian vs. Devuan vs. Ubuntu? If so, could you please use "vendor" instead, since that is the pre-existing term for that distinction in various places, including dpkg-vendor. -- Richard signature.asc Description: OpenPGP digital signature
Re: epoch bump for libtraceevent
On 10/13/20 11:40 AM, Sudip Mukherjee wrote: > libtracevent is currently being packaged from the linux kernel source > and as such it has the version of '5.8.14-1' same as the kernel. As > reported in #971976, the upstream libtraceevent now lives in its own > repo and has a version of '1.1.0' > So, I will need to add an epoch to the version to package it directly > from its upstream repo. Have you asked upstream if they would be willing to bump the version to 6.0 or something? -- Richard signature.asc Description: OpenPGP digital signature
Re: Allowed to build-depend a pkg in main on a pkg in non-free?
On 9/30/20 4:45 PM, Paul Wise wrote: > The > official buildds, for packages in main, seem to include contrib but > not non-free binary packages in the chroot's apt sources.list files. > Both contrib and non-free source packages are available in the chroots > apt sources.list files. This appears to be the same for all three of > main, contrib, non-free. I would expect that: 1. main builds include main repositories 2. contrib builds include main, contrib, & non-free repositories 3. non-free builds include main, contrib, & non-free repositories This would match the Policy allowed package dependencies. Including _more_ than this wouldn't break builds, but could allow non-Policy compliant dependencies to sneak in. For example, a package in main that Build-Depends on a package from contrib should FTBFS on the buildd, but would not. Including _less_ than this could break builds. For example, if I have a "free package in contrib that require[s]... non-free packages" (Policy 2.2.2) and the buildd doesn't include non-free, it will FTBFS when it should build. Am I missing something here? If I'm understanding everything correctly, this seems buggy. -- Richard signature.asc Description: OpenPGP digital signature
Re: How much data load is acceptable in debian/ dir and upstream (Was: edtsurf_0.2009-7_amd64.changes REJECTED)
On 9/14/20 2:04 PM, Andreas Tille wrote: > in the Debian Med team there are two GSoC students very busy to write > autopkgtests for (in the long run) all our packages (if possible). That is an excellent thing to do. > On Sun Sep 13 18:00:08 BST 2020, Thorsten Alteholz wrote:[3] >> please don't hide data under debian/*. > > Sorry, Thorsten but I think "hiding" is not the right term. FWIW, I agree that "hiding" seems wrong here. > We have no > other dir to add extra files than the debian/ dir. Assuming a "3.0 (quilt)" package, you have the option of adding another source tarball. [1] I'm not sure if that is better or worse here. It just moves data from one source tarball (the debian one) to another. But it is an _option_ at least. >> Don't forget to mention the copyright information. > > In principle yes, but these data are not copyrightable as far as I know. > Nilesh has mentioned the origin of data in debian/tests/README to > provide a reference. If you consider this information not sufficient > please let us know a better way. I would put the explanation in debian/copyright (instead of or in addition to any other location). If you're using machine-readable copyright, use "License: public-domain", and and note that 7.1.1 _requires_ an explanation of why it is public-domain, as public domain is commonly misunderstood. [2] [1] https://wiki.debian.org/Projects/DebSrc3.0#How_to_use_multiple_upstream_tarballs_in_3.0_.28quilt.29_format.3F [2] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name -- Richard signature.asc Description: OpenPGP digital signature
Re: [Pkg-javascript-devel] How to switch to DEP14 automatically for > 1000 existing repositories
On 9/11/20 11:26 AM, Xavier wrote: > $ salsa --group xx-team --all --no-fail rename_branch \ > --source-branch=upstream --dest-branch=master Should "upstream" be "upstream/latest"? As I understand it, "master" is correct if it is the upstream git "master", but "upstream/latest" is correct if it is the gbp upstream-branch representing imported upstream tarballs. -- Richard signature.asc Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 9/7/20 5:33 AM, Raphael Hertzog wrote:
> On Sat, 05 Sep 2020, Richard Laager wrote:
>> I do not see why we have to prohibit occasional uploads to experimental
>> from debian/unstable. If this is permitted, then that also avoids the
>> busywork of creating debian/experimental in that scenario.
>
> To me it feels awkward to allow this. You can't really get it both ways
> IMO. If you decide to use codename-based branches, then you should use
> debian/experimental for an experimental upload.
That view is: A > B.
FWIW, my justification for B > CD is:
Since the parallel branch scenario is already debian/unstable &
debian/experimental, then I'll take a small inconsistency for the
occasional upload to experimental to be able to use a strict subset of
those choices (debian/unstable) as the normal scenario, rather than a
whole new thing (debian/{master,latest}).
> The "clarity" of debian/unstable is limited to Debian developers, upstream
> developers might not know that unstable is the development branch. Random
> outsiders neither.
Whatever it is called, the main development branch will normally be the
HEAD, so an unqualified `git clone` will give that branch. (Exceptions
include when the repository is mixed upstream and packaging.) That
probably covers the upstreams and random outsiders.
> But what I meant is that "unstable" is only applicable to Debian and
> that derivatives have different models and that we should not impose
> too much to make sure we cater to the needs of derivatives too.
I think you were following, but to be clear, the proposal isn't
/unstable, it's /. So
debian/unstable, ubuntu/groovy (changes as time moves on),
kali/kali-dev, etc.
I do acknowledge that /latest is undoubtedly easier for the
tooling to implement, and that is a serious advantage of C.
> Without having read your precise diff, I would believe my personal view
> would be: C > D > B > A
That is what I expected your view to be. You might be A > B rather than
B > A, though, as discussed above.
Anyway, I think I'm into dead horse territory here. Unless someone else
speaks up, I assume the next step is for you to pick an option, which I
assume will be C (in principle; not necessarily my wording).
Thanks for taking the time to hear me out and thanks for DEP-14!
--
Richard
signature.asc
Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 8/31/20 8:53 AM, Raphael Hertzog wrote: > I already agreed that we can tweak the wording to document that it's I don't think the people on the list saw that message, as it had an attachment. It's below (unabridged). > OK to use debian/unstable as default branch even if you are not a > complex package that require multiple branches, provided that you will > not use debian/unstable when you decide to push something to > experimental. I do not see why we have to prohibit occasional uploads to experimental from debian/unstable. If this is permitted, then that also avoids the busywork of creating debian/experimental in that scenario. On 8/30/20 4:27 PM, Raphael Hertzog wrote: > Hello, > > On Sun, 30 Aug 2020, Richard Laager wrote: >> You could use debian/experimental all the time and then merge down to >> debian/unstable only when you're ready to upload and have chosen >> unstable. But I suspect your objection would be: that's unnecessary >> busywork. And I see that point. I would probably make the same >> objection, which means I think I agree with the debian/latest concept in >> your situation. > > You perfectly understood my reasoning. Thank you for making that effort. > >> I'm not sure if most package maintainers are doing this or not. I've >> always assumed that most people are targetting only unstable most of the >> time and that use of experimental is relatively rare. I could easily be >> wrong on that. > > I don't think that you are wrong. Most packages definitely only target > unstable and never use experimental. Then why give up the simplicity of only one choice and the clarity (and tooling advantages) of debian/unstable as the typical case, in favor of debian/latest? > But most packages also never need to maintain two development branches > in parallel. Only very big packages, linux or django for example, will > maintain different upstream versions in two parralel branches. > > Another thing that's quite certain is that you never know what the future > will bring you. And while you never had to use experimental, you might > have to at some point. > > In that sense, I find debian/latest more future-proof but I also > agree that for the few cases where we would have to use experimental, > it's not a big deal to have to create debian/experimental. > > Another thing to take into account is that DEP-14 has been drafted > as a vendor-neutral recommendation. I use it in the context of Kali > and there's no "unstable" release in Kali. We have "kali-dev". Ubuntu > only has codenames even for their development release. What's wrong with kali/kali-dev? I'd love to hear someone from Ubuntu weigh in on why ubuntu/latest would be better there. From my point of view (as someone who occasionally SRUs something in Ubuntu), having ubuntu/ is the right choice. When a new development release opens up, you would branch e.g. ubuntu/focal into ubuntu/groovy. Then ubuntu/focal continues to exist for SRUs (stable release updates). To me, my proposed branching model feels like it matches the Ubuntu development model 1:1. > Thus /latest is a better default for tools like git-buildpackage > and it makes sense for DEP-14 to endorse such a default branch as the > recommended name. > >> That is, I'm generally always targetting unstable and _not_ regularly >> using multiple releases, so the DEP-14 language "prohibits" me from >> using debian/unstable. This is what feels backwards to me. If I'm always >> targetting unstable, debian/latest (and previously debian/master) is >> less clear than debian/unstable. >> >> At a minimum, can we rework this in some way so the language does not >> require me to be regularly using multiple releases to use >> debian/unstable as a branch name? > > That seems entirely reasonable, yes. Can you try to make a proposal ? > > I attach the current markdown file with my not-yet pushed change that I > submitted for review here. > > Cheers, DEP-14 starts this section with a broad, "In general, packaging branches should be named according to the codename of the target distribution." On that, I think we all agree. Then it continues, "We differentiate however the case of development releases from other releases." Fundamentally, the scope of that exception is what we are discussing. Diffs available here (since this list refuses attachments and I can't figure out how to disable line wrapping in Thunderbird): https://paste.debian.net/1162793/ Proposal "A": My original position was that we limit that exception to using "unstable" and "experimental" instead of "sid" and what (I later learn
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 8/30/20 12:02 PM, Sean Whitton wrote: > Hello Raphael, > > On Fri, 28 Aug 2020, at 4:01 PM, Raphael Hertzog wrote: >> diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn >> index 0316fe1..beb96ea 100644 >> --- a/web/deps/dep14.mdwn >> +++ b/web/deps/dep14.mdwn >> +In the interest of homogeneity and of clarity, we recommend the use of >> +`debian/unstable` over `debian/sid` as it better conveys its special nature >> +as opposed to other branches named after codenames which are used for >> +stable releases. > > I think we should recommend debian/sid because for some years dgit has been > generating branches called dgit/sid. I think it would smooth the integration > between branches on salsa and branches on dgit.debian.org if both always used > codenames. Using debian/sid makes the branch name inconsistent with debian/changelog, which traditionally uses "unstable" not "sid". It also makes debian/experimental an outlier that cannot be made consistent (because there is no character code name for experimental AFAIK). -- Richard signature.asc Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
I think I now have a better handle on how/why I disagree with the DEP-14
recommendation language.
On 8/30/20 8:36 AM, Raphael Hertzog wrote:
> On Sat, 29 Aug 2020, Richard Laager wrote:
>> That said, I do understand we give a lot of deference to developers'
>> workflows. So I have no objection to DEP-14 supporting this workflow
>> with debian/latest. But I would like to see it (debian/latest)
>> recharacterized as the alternate approach rather than the recommended
>> method.
>
> Your approach is perfectly valid but I don't really believe that it should
> be the recommended approach. It doesn't seem to match the most common
> workflow.
>
> Most package maintainers are not actively working on two different
> development branches, instead the single development branch keeps moving
> between:
> - ready for unstable/upload to unstable
> - work in progress on a new upstream release
> - possible upload to experimental to gather feedback (buildd, users)
> - back to ready for upload to unstable
So you are regularly using multiple releases (unstable and experimental)
where the DEP-14 language allows you to use either debian/latest or
debian/{unstable,experimental}, but you feel debian/latest makes the
most sense most of the time in that scenario.
I think I see your point. You don't always know a priori when you are
going to want to upload to experimental. (Where you do know that, it's
because you expect the experimental piece to live in parallel for a
while and you'll use a temporary debian/experimental branch.) So you
have one debian/latest branch that can upload to unstable or
experimental as needed.
You could use debian/experimental all the time and then merge down to
debian/unstable only when you're ready to upload and have chosen
unstable. But I suspect your objection would be: that's unnecessary
busywork. And I see that point. I would probably make the same
objection, which means I think I agree with the debian/latest concept in
your situation.
I'm not sure if most package maintainers are doing this or not. I've
always assumed that most people are targetting only unstable most of the
time and that use of experimental is relatively rare. I could easily be
wrong on that. But that is definitely _my_ practice:
My package branch typically moves between:
- ready for unstable/upload to unstable
- work in progress on a new upstream release
- back to ready for upload to unstable
That is, I'm generally always targetting unstable and _not_ regularly
using multiple releases, so the DEP-14 language "prohibits" me from
using debian/unstable. This is what feels backwards to me. If I'm always
targetting unstable, debian/latest (and previously debian/master) is
less clear than debian/unstable.
At a minimum, can we rework this in some way so the language does not
require me to be regularly using multiple releases to use
debian/unstable as a branch name?
Preferably, can we change this to convey the following (probably using
better language):
1. If you (have one line of package development and) regularly
alternate between uploading to unstable and experimental, use
debian/latest.
2. If you normally only upload to unstable, use debian/unstable.
3. If you will have a separate line of package development for upload
to experimental, name that debian/experimental. If that is
long-lived, the other branch should be debian/unstable.
#1 covers your use case. #1 is listed first per your view that this is
the common case. #2 covers my use case. #3 allows either a #1 or #2
style to add debian/experimental temporarily, while recommending the
debian/{unstable,experimental} pair if the experimental branch is
long-lived (because it's confusing for debian/latest to not be the
latest version).
--
Richard
signature.asc
Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 8/29/20 5:16 PM, Simon McVittie wrote: > On Sat, 29 Aug 2020 at 15:07:07 -0500, Richard Laager wrote: >> However, this is still saying that one should prefer debian/latest over >> debian/unstable, and that debian/unstable is (sort of) only for use when >> you're also uploading to experimental. > > The way I think of it phrases this a bit differently: whether or not you > have a version targeting experimental right now, if you *were* uploading > to experimental, what would you do? I think that's a perfectly reasonable way to look at the issue. I don't think that's what the DEP-14 language says, though. > I think the workflow used in packaging dbus (with the newly proposed > naming: debian/unstable as default, and a debian/experimental branch > that runs ahead of it) is fine. This is good if you want to draw most > attention to the version in unstable, with experimental being for early > adopters and not recommended for general use. > > I think the workflow used in packaging gnome-shell (with the newly > proposed naming: debian/latest as default, and a debian/unstable branch > that lags behind it) is *also* fine. This is good if you want to draw > most attention to the version in experimental (when there is one). In both cases, I would have debian/unstable and debian/experimental branches. I would draw attention to the main line of development by making that as the default branch on the server: debian/unstable in the first case and debian/experimental in the second. That way, someone who doesn't know the package's branch style gets a hint on clone; someone who does already knows which branch they want and can pick it explicitly. Of course, the same server-side HEAD setting also works (and should be used) if debian/latest is in use. -- Richard signature.asc Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 8/29/20 5:19 PM, Russ Allbery wrote: > The problem in my case with not putting a branch name in Vcs-Git is that, > for packages for which I'm also upstream, the default branch in the > repository named in that header is the upstream development branch, which > contains no Debian packaging files and thus would be a very confusing > thing for debcheckout to clone. So I have to name *some* branch, which > right now is debian/master and would be debian/latest. If the packaging is on Debian Salsa (which I would recommend), then I'd set the default branch to the packaging branch. If upstream happens to live there too, then people can switch to that explicitly. Rationale: The packaging is the more relevant thing to Debian. While there are Debian native packages and some people are both upstream and packager, the common case is software packaged from another upstream. Then you don't need a branch name in debian/control. -- Richard signature.asc Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 8/29/20 3:33 PM, Russ Allbery wrote:
> I think the primary thing that bothers me about this workflow is that
> experimental becomes an ephemeral branch, which appears and disappears
> based on the vagaries of the release cycle.
To me, that feels like the branch is an accurate representation of
reality. The packages in experimental are ephemeral and appear and
disappear too, right?
> That said, one way in which this becomes concrete is the Vcs-Git control
> field. What do you put in the branch field for your experimental upload?
> Naming debian/experimental is clearly wrong; that branch is highly likely
> to not exist when someone later checks. Naming debian/unstable is also
> clearly wrong; the package is not based on that branch.
I wouldn't (and don't) put a branch name there. I don't think it serves
a practical purpose. If it does, I guess a corollary is that I/we should
be specifying debian/buster there for stable updates and likewise
debian/buster-backports for backports. Is that a thing people actually
do? I haven't been, but I can do so if that is a best practice.
I currently set the branch name in debian/gbp.conf because that actually
has a practical effect on the tools.
Putting the branch name in debian/gbp.conf leads to a small amount of
churn for things like stable updates and backports. I had forgotten
about the effects of that in your case. That does undercut my argument a
bit in the immediate term, as you'd have to change that when going
between experimental and unstable, which means they aren't just
fast-forward merges. But if we standardize on this naming convention as
I propose, then gbp could default to these branch names, which means we
wouldn't need to set branch names in debian/gbp.conf. That seems like
the best long-term outcome.
> It's valid to say that it's okay for me to feel odd and I can cope with
> feeling odd and follow the convention anyway.
To be honest, I lean towards that view. But you've been doing Debian
development more and/or longer than me (and more to the point here,
actually use experimental regularly), so I'm very hesitant to dismiss
your viewpoint. I could easily be missing something.
I would love to see other people weigh in on debian/latest vs
debian/unstable as the default. Assuming the silent majority is using
debian/{master,latest}, is that out of a considered preference over
debian/unstable or out of inertia / following other packages / following
DEP-14? In other words, how many people _care_ either way?
--
Richard
signature.asc
Description: OpenPGP digital signature
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On 8/28/20 6:01 PM, Raphael Hertzog wrote:
> following the recent discussions of June and of the last days, I'm
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed earlier. And
> it says that debian/unstable is preferred over debian/sid.
I think this is a change in the right direction.
However, this is still saying that one should prefer debian/latest over
debian/unstable, and that debian/unstable is (sort of) only for use when
you're also uploading to experimental.
I think this is backwards. I think the default should be
debian/unstable. If you want to use experimental, then also use a
debian/experimental branch.
The big advantage of this approach is that the branch names are always
consistent with changelog names. This works well when you need a
debian/buster for a stable update and/or a debian/buster-backports for a
backport. Aside from being helpful to humans, this consistency then
makes for a reasonable default in the tools (e.g. git-buildpackage). It
also extends perfectly to use with downstream distributions, with things
like ubuntu/bionic, ubuntu/focal, etc. FWIW, I have a package using all
of debian/{buster,buster-backports,unstable} and ubuntu/bionic right now
and it works great.
When I last brought this up [1], Russ Allbery said that debian/latest
was desirable (to him, at least) because, "My normal use of experimental
does not involve maintaining unstable and experimental branches
simultaneously. I essentially never do that; instead, I maintain one
development branch, which I upload to either experimental or to unstable
based on things like where we are in the release cycle or whether I need
to stage some change." [2]
I believe that "git branches are cheap", so I don't really see the
problem in switching back and forth between debian/unstable and
debian/experimental in that case. Given that he further said, "If I'm
uploading to experimental, I don't fix bugs in unstable until the
experimental release is ready for upload to unstable.", the merges would
be fast-forward merges anyway, so they wouldn't take any actual hand
merge work. Using separate branches would inherently allow for proper
handling of the "exception" he described of needing to upload a fix to
unstable while debian/latest is the upload to experimental.
That said, I do understand we give a lot of deference to developers'
workflows. So I have no objection to DEP-14 supporting this workflow
with debian/latest. But I would like to see it (debian/latest)
recharacterized as the alternate approach rather than the recommended
method.
Previously, my proposal would have required a fair amount of branch
renaming--from debian/master to debian/unstable. However, with the
change from debian/master to debian/latest, branch renaming would "have
to" occur anyway, so renaming debian/master to debian/unstable is no
more trouble.
[1] https://lists.debian.org/debian-devel/2019/11/msg00084.html
[2] https://lists.debian.org/debian-devel/2019/11/msg00085.html
--
Richard
signature.asc
Description: OpenPGP digital signature
Re: Pimp your shell - Debian developer tips?
Some notes from our defaults at $DAYJOB. I can't take credit for most of
this. These were ideas I've picked up from various people along the way.
# Prevent users from accidentally overwriting files with redirection.
set -o noclobber
Warning: While I'm the one that added it, sometimes I don't love
"noclobber".
# Fix some spelling errors in tab-completions
shopt -s cdspell
shopt -s dirspell
# Allow ** to recurse
shopt -s globstar 2> /dev/null
# Make globs case-insensitive
shopt -s nocaseglob
# Tell less to not ring the bell (Q) and pass through color escape
# sequences (R).
export LESS="QR"
# Save and show timestamps in the command history.
HISTTIMEFORMAT='%F %T '
We also colorize the hostname, which can act as a subtle hint as to
whether you are on the right system. (It's basically an subconscious
thing; it's not like we memorize which system is which color.) These
days, the per-host color is calculated with Jinja templating in Ansible.
The example below is the older code where bash calculates it. My email
client is going to word-wrap this, so you'll have to reverse that, but
it's straightforward.
# We use dircolors instead of tput to determine which types of terminals
# support colors. Otherwise, we can end up with an inconsistency
# between bash and ls, et al. For example: a vt100 on OpenIndiana.
if (LS_COLORS= ; eval $(dircolors 2> /dev/null) ; [ -n "$LS_COLORS" ])
then
# Colorize based on hostname: green, yellow, blue, magenta, or cyan.
ps_h='\[\e[1;'$((32 + $(hostname | cut -d. -f1 | cksum | cut -c1-3)
% 5))'m\]\h\[\e[0m\]'
if [ "$(id -u)" = "0" ]
then
# Make the username and # red when logged in as root.
PS1='${debian_chroot:+($debian_chroot)}\[\e[1;31m\]\u\[\e[0m\]@'$ps_h':\w\[\e[0;31m\]\$\[\e[0m\]
'
else
PS1='${debian_chroot:+($debian_chroot)}\u@'$ps_h':\w\$ '
fi
unset ps_h
if [ -r ~/.dircolors ]
then
eval "$(dircolors -b ~/.dircolors)"
else
eval "$(dircolors -b)"
fi
alias ls='ls --color=auto'
alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
It's not shown in the example above, but we also use white text on a red
background for the hostname if it ends in -new. This is our convention
when a new system is being setup: we set the hostname (in Ansible in our
case) for a system replacing a host named "name" to "name-new". This
prompt helps you keep track of whether you are on the current production
system or the -new system you are configuring. It is functionally
equalivalent to:
ps_h='\[\e[1;37m\]\[\e[1;41m\]\h\[\e[0m\]'
--
Richard
signature.asc
Description: OpenPGP digital signature
Re: +1 (no hidden directory, please) Re: [Summary]: RFC: Standardizing source package artifacts build paths
On 5/3/20 5:54 PM, Holger Levsen wrote: > On Sun, May 03, 2020 at 10:56:32PM +0200, Simon Richter wrote: >> Frankly, I don't see the point in hiding the directory. The only person >> who'd ever look into that directory would be someone inspecting what >> happened during a build process, and all that hiding directories >> achieves is adding more mental load to them where they have to remember >> to use ls -a, and type a dot before trying to tab-complete anything. >> >> Basically, it would just be annoying with no good reason. > > my thoughts exactly. Agreed. Nothing else in the debian directory is hidden. I think the burden should be on justifying why this should be the one hidden directory. -- Richard signature.asc Description: OpenPGP digital signature
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
On 3/30/20 2:34 PM, Sean Whitton wrote: > The text quoted from the -private IRC channel is a bit misleading. I > was the one who rejected the upload, and it was not actually because of > the QR codes, but for other reasons. I think it was pretty clear from the original email that there was another reason, not under debate, for why it was rejected. This thread was only to address the QR code question. -- Richard signature.asc Description: OpenPGP digital signature
Re: DFSG of disk image with contrib package
On 3/16/20 12:25 PM, Emmanuel Kasper wrote: > For extended functionality, I build some of the disk images with a > package from contrib, namely virtualbox-dkms Could you use KVM (and if necessary, libvirt) instead? -- Richard signature.asc Description: OpenPGP digital signature
Re: Best practices for Debian developers who are also upstreams?
On 2/8/20 7:57 PM, Simon Richter wrote: > In my experience, it was often a good idea to separate my upstream and > Debian hats. +1 My current situation is that I'm a Debian packager who has then over time become more involved in upstream and eventually ended up with a commit bit. On a different package, I'm in the process of taking over packaging for something where I am already an upstream developer (or perhaps should say "was", as I haven't been active upstream in some time, though that may change here). That sounds like it may be different than your situation, but I hope I can still offer some useful comments. > At the same time, Debian packages have a well-defined installation > procedure, so it is often possible to build a quick fix for a bug that > will give users a working package, but where the patch is not suitable > for upstream inclusion, like changing an init script or unit file. +1. In such a case, you can clean that up into a more general solution for upstream and later drop the Debian patch. I've had that exact thing happen. >> - have debian/ in upstream repository, and a CI that does the bulk of >> Debian QA on every upstream commit and immediately gives feedback to >> upstream devs that "break" something from Debian QA point of view I'm in the process of packaging something where upstream (which is not me) puts their debian directory (for CI purposes) as packaging/debian. That allows them to do real Debian packaging for CI, and update that as necessary, but keeps it out of the way of the real "debian" directory. You might consider that option. Upstream's CI presumably has to move/copy/link ./packaging/debian to ./debian before kicking off the Debian build, but that's just one extra step. >> - bonus: import upstream releases as git operations Do this either way! :) In the packages I maintain, my debian/README.source says: The `master` branch is upstream's `master` branch. ... The `upstream/latest` branch contains the unpacked contents of the orig tarball. It is branched off the `master` branch, so the delta from `master` (at the branch point) to `upstream/latest` contains generated files that exist in the tarball but not in the upstream repository. That said, I prefer to keep separate git checkouts for the package and upstream to avoid the potential for accidents like pushing upstream pull request branches to Debian Salsa or, far more likely, accidentally pushing the current master to Debian Salsa. > Maintaining debian/changelog inside a version control system is a bit of > a category error, because it is a form of version control system log, I'm a big fan of using git-buildpackage and `gbp dch`. My current workflow (somewhat "copied" from e.g. lintian) is that debian/changelog contains a stub like this until it is time to tag a Debian package release: ntpsec (1.1.8+dfsg1-4+git) UNRELEASED; urgency=medium * UNRELEASED -- Richard Laager Sat, 11 Jan 2020 22:49:28 -0600 Note that it is critical that the version in Salsa NOT be the same as the version in the archive if you are using Salsa CI to test changes. That's why the +git is added. If they are the same, when the CI code tries to install the package, you'll have problems because of the conflicting version numbers. -- Richard signature.asc Description: OpenPGP digital signature
Re: packages that are touching /srv?
On 2/6/20 9:41 AM, Daniel Baumann wrote:
> On 2/6/20 4:10 AM, Richard Laager wrote:
>> That's been my interpretation too. My expectation as a sysadmin is that
>> /srv is available for my _exclusive_ use.
>
> in the case of vsftp and tftpd-hpa, there's a debconf question asking
> the admin for the location of these directories, for which /srv/{t,}ftp
> are the default values.
>
> or in other words: I agree with you that /srv shall not to be touched
> without consent from the admin.
That's a very interesting point! I hadn't considered the difference
between a fixed default and a debconf default.
FWIW, at $DAYJOB, our stance is to accept all debconf defaults (e.g. use
"hit enter at every prompt" or use noninteractive mode) and then
configure after / on top of that (via debconf or not). So to me, in
practice, debconf defaulting to /srv/tftp is the same as not having a
debconf prompt and making it a fixed default. I understand that's not
the same in theory, where a reasonable argument can be made that the
admin accepting the debconf prompt is giving their permission.
In terms of these particular packages, I'm not using vsftp and I'm using
tftpd-hpa with its default of /srv/tftp. I don't have strong feeling
abouts debconf-default vs fixed-default, so I probably don't have much
to add further.
--
Richard
signature.asc
Description: OpenPGP digital signature
Re: packages that are touching /srv?
On 2/5/20 7:36 PM, Paul Wise wrote: > AFAICT from Debian's FHS > documentation, since /srv is laid out differently on different hosts > packages should not rely on a particular layout. My interpretation is > of this is that packages should never touch /srv unless directed to do > so by the sysadmin. That's been my interpretation too. My expectation as a sysadmin is that /srv is available for my _exclusive_ use. > FTP servers that default to using /srv/ftp to serve files. > TFTP servers that default to using /srv/tftp to serve files. > These also use those dirs as user home directories. I actually use both /srv/ftp and /srv/tftp, but I still don't think those are acceptable defaults. > I wonder if any of these should be changed? FWIW, I would say yes. -- Richard signature.asc Description: OpenPGP digital signature
Re: Salsa CI news
On 2/5/20 5:05 PM, Dmitry Smirnov wrote: > It should be on abuser Saying "abuser" is inflammatory, especially as no abuse has been proven. Please stop. > to explain that it was not possible to build a > service in a fully DFSG compliant manner Why is the current solution not DFSG compliant? > only from components provided by Debian. While I agree it would be better in Debian to use a Debian image instead of an Alpine one and to use Debian packages, that is separate from DFSG compliance and a much lower severity issue. -- Richard signature.asc Description: OpenPGP digital signature
Re: Adding security features (was: Kernel parameters protecting fifos and regular files)
[ Note: I have reordered the quoted text blocks. ] On 1/29/20 8:28 AM, Marvin Renich wrote: > On the other hand, I do agree with using unstable and testing to > determine the level of disruption, on the condition that there is a > _commitment_ to removing the feature before stable release if the > impact on usability is more than minor. +1 I don't think we're that far apart here. There are plenty of shades of grey in this, and what counts as "minimal", "medium", or "massive" is going to be at least somewhat subjective. > Even medium disruption is the > wrong balance for a general distribution's default. I'm willing to go a bit further than you, as I would take (again, my subjective) "medium" disruption for a real security win, generally speaking. > I would like to give big kudos to the AppArmor team for providing > Debian developers and users with an exemplary experience while adding > a security feature as a distribution default. +1 AppArmor had the potential to cause massive breakage, and has not, primarily due to it being opt-in. I think this has been a big success. I would characterize AppArmor as being on the low end of "medium" breakage. AppArmor is something that I need to care about on an on-going basis as a sysadmin. I need to be aware it exists, how its problems will manifest, how to debug it, and how to fix it. I can't completely ignore it, as it does break things from time to time. This is not to say it breaks things out-of-the-blue. It breaks things when I change configurations away from the default. That's totally fine. I figure it out and go add the appropriate bit to the local/tunable file. Something minimally disruptive would be something like Address Space Layout Randomization (ASLR). While that may have impacts on maintainers enabling/disabling compiler flags, it is not something I ever have to think about as a sysadmin. It is never the problem. I never need to do anything related to it (as a sysadmin). Something like SELinux in the RedHat world is probably still at least on the high end of "medium" these days and could probably be characterized as "massive breakage" in its early days. "Massive breakage" is the sort of thing where large numbers of experienced sysadmins respond with "just turn it off". With what I know about this particular change right now, my assumption is that it will cause little to no breakage. I would characterize the expected impact as "minor". Further, I expect that any breakage will be "one-time" breakage that can be addressed by application developers and/or package maintainers, and it will not cause on-going work for system administrators. > > Unless massive breakage is expected, the default should > > be the most secure option. > The above > statement implies that the default should be the maximum security that > does _not_ cause _maximum_ disruption. I'd say that "massive breakage" (breaking lots of things) is not the same as "maximal disruption" (the most disruption). Maximum disruption would be, for example, breaking things that were "fully correct" (not doing something "dodgy") before the change. This would be a "flag day" change. That level of disruption needs to be avoided if at all possible, and carefully managed if completely unavoidable and worth the pain. > Time and time again I see security expert "wannabes" pushing for the > most security possible. Even real experts sometimes lose sight of the > balance between usability and security. Unfortunately, there are a lot > more "wannabes" than real experts, and the "wannabes" are typically much > more vocal. While I understand your point, I think it would be better to focus on the arguments rather than the people making them. -- Richard signature.asc Description: OpenPGP digital signature
Re: Kernel parameters protecting fifos and regular files
On 1/28/20 9:23 PM, Craig Small wrote: > My personal preference is to lock them down by default, by setting both > to mode 2. FWIW: I agree. Unless massive breakage is expected, the default should be the most secure option. If you default to secure and that breaks something, people will be motivated to fix it (either the root issue or by changing the setting). If you default to compatible, very few people will find the option and tweak it, so most people will lose out on the security. If there is massive breakage, you can back it off, of course. -- Richard signature.asc Description: OpenPGP digital signature
Bug#949979: ITP: talkatu -- GTK+ widgets for instant messaging clients
Package: wnpp Severity: wishlist Owner: Richard Laager * Package name: talkatu Version : 0.1.0-dev Upstream Author : Gary Kramlich * URL : https://bitbucket.org/rw_grim/talkatu/ * License : GPL-2+ Programming Lang: C Description : GTK+ widgets for instant messaging clients Talkatu is a collection of Gtk+ widgets that are useful for chat applications. -- "It was started as a rewrite of the GtkIMHTML widget found in Pidgin, but quickly expanded to include most things related to conversation windows." This is the successor to Pidgin 2's GtkIMHTML widget and is a dependency of Pidgin 3. My intention is to package this for experimental only, until such time as it and Pidgin 3 have stable releases. Having this in experimental will make it easier for people to build Pidgin 3 and will ensure the packaging is ready when Pidgin 3 is. This package will be maintained on Debian Salsa at (not yet created): https://salsa.debian.org/debian/talkatu -- Richard
Bug#949977: ITP: libgnt -- GLib Ncurses Toolkit
Package: wnpp Severity: wishlist Owner: Richard Laager * Package name: libgnt Version : 2.14.0-devel Upstream Author : Pidgin Developers * URL : https://bitbucket.org/pidgin/libgnt/ * License : GPL-2+ Programming Lang: C Description : GLib Ncurses Toolkit GNT is an ncurses toolkit for creating text-mode graphical user interfaces in a fast and easy way. It is based on GLib and ncurses. It was born out of the console-based UI, Finch, for the libpurple project. -- This code is currently part of the Pidgin upstream tarball and thus the pidgin source package, but is being broken out upstream for the next release. Accordingly, I am breaking it out into a new package in Debian. I am working with Ari Pollak, the pidgin package maintainer. My intention is to prepare the package using a development snapshot so that everything is ready in advance for the 2.14.0 releases of libgnt and Pidgin. Given that this is already a stable library and going to be a dependency of the next minor release of Pidgin, I am leaning towards uploading to unstable rather than experimental, but I can be convinced otherwise. This package will be maintained on Debian Salsa at (not yet created): https://salsa.debian.org/debian/libgnt -- Richard
Bug#949978: ITP: gplugin -- GObject based plugin library
Package: wnpp Severity: wishlist Owner: Richard Laager * Package name: gplugin Version : 0.29.0 Upstream Author : Gary Kramlich * URL : https://bitbucket.org/rw_grim/gplugin/ * License : GPL-2+ Programming Lang: C Description : GObject based plugin library GPlugin is a GObject based library that implements a reusable plugin system which supports loading plugins in other languages via loaders. It relies heavily on GObjectIntrospection to expose its API to the other languages. -- This is a dependency of Pidgin 3. My intention is to package this for experimental only, until such time as it and Pidgin 3 have stable releases. Having this in experimental will make it easier for people to build Pidgin 3 and will ensure the packaging is ready when Pidgin 3 is. This package will be maintained on Debian Salsa at (not yet created): https://salsa.debian.org/debian/gplugin -- Richard
Re: https://tracker.debian.org/pkg/dballe
On 1/17/20 6:55 AM, Sam Hartman wrote: >> "Johannes" == Johannes Schauer writes: > > Johannes> or have a mechanism that allows maintainers to tell buildds > "please build this > Johannes> source package with build profiles X and Y enabled". That would > then build the > Johannes> binary packages necessary to do a full build in a second upload. > > That doesn't help. > > If I need version y+3 of rustcc to build y+5 of rustcc and only y is in > the archive, no build profile is going to help me. If I'm following correctly: The packager would use rustcc >= y+3 (in practice, likely rustcc y+5) to locally build rustcc y+5 and then do a binary upload. But if dak (or whatever, I'm not so familiar with the server side here) throws away the binary, then we're sunk. So there needs to be a way to note that the binary needs to be kept. Assuming I'm on the right track, here are a couple of questions: In such a case, would the source package have a Build-Depends of >= y+3? It seems like it would. Could that be the way to indicate a bootstrap upload? In other words, if the package has a Build-Depends on one of the binary packages it produces that is _not_ satisfied in the suite it's being uploaded to but is satisfied by this upload, then it's a bootstrap upload, and the binaries should be kept. This would avoiding adding a new field for this and would ensure the Build-Depends are set correctly in bootstrapping scenarios. Regardless of how the "keep the binaries" flag is implemented... should the uploaded binary be published, or should the package be rebuilt? I think I'd argue for the latter. The uploaded binary package should be installed on the buildd and then the package should be rebuilt from source, with _that_ result being put into the archive. This doesn't protect against the trojaned-compiler problem, but it does at least ensure that the package builds from source. -- Richard signature.asc Description: OpenPGP digital signature
Re: migration from cron.daily to systemd timers
On 1/8/20 1:02 PM, Michael Stone wrote: > As a third party with no particular ax to grind on this, I do wonder > what the advantage is to adding another mechanism for this particular > use case, given the need to somehow handle upgrades involving an > existing (presumably working?) solution. At my work, we recently converted all our cron jobs to system units (service and timer pairs). We see the following advantages: You can use systemd's dependencies. This allows you to do things like automatically stop a related scheduled task if its service is manually stopped (e.g. for maintenance). This can keep the scheduled task from interfering with your work (e.g. a watchdog script restarting the "dead" service) and/or throwing errors (because the service isn't running). In the latter case, that might mean that you avoid needing to suppress errors because of this normal occurrence, which means you aren't suppressing real errors. The service unit can be started manually. This makes it a lot easier to debug/develop with systemd than cron (where you have to manually change it to run at the next minute and wait). Obviously, you can still run the scripts directly, but sometimes the problem you're working on only manifests when it is run under cron/systemd (e.g. because of different environment variables being missing or different [1]). The timer units can be randomized over arbitrarily sized windows, customized per service. This avoids load peaks, e.g. at cron.daily time. Your scripts can write non-error debug/status information to stdout without it resulting in an email. This info shows up in the logs, which can be convenient. [4] Obviously, one can use logger(1) or syslog, depending on programming language, but for trivial in-house scripts, it's hard to beat the simplicity of just printing to stdout. Yesterday, we implemented a new script that uses a web API where you request an action and then poll until it completes. We wanted a timeout. With systemd, since the service is Type=oneshot, we can just set TimeoutStartSec= and we're done. This will kill the script if it hangs for any reason at any step. We obviously could have implemented a timeout in the script for that particular step, or in general, but this was simpler. For new/junior sysadmins, there is more overlap. Everything they learn about systemd services applies to both scheduled tasks and those that start at boot. That's not to say that cron is harder to learn, just that it's another thing. Recent versions of systemd have an analyze option to show you the next iteration(s) of a calendar specification. This makes it easy to verify that your calendar syntax is firing at the right times, and you haven't mixed up hours/minutes/seconds, etc. It will also show you the normalized form (which we prefer to use to avoid confusing humans). Some examples from my history: systemd-analyze calendar --iterations=5 'Mon..Fri 01:50' systemd-analyze calendar --iterations=5 '*:0/5' systemd-analyze calendar --iterations=5 '*:27,57' We do lose the automatic cron emails, which some would see as a downside, though there are ways to get them on a service-by-service basis. [2] [3] In our particular case, anything that is _expected_ to send an email was already doing so manually (i.e. calling mail(1)) for other integration reasons. In our particular case, though, using systemd units was preferable from an alerting perspective, as we already have an Icinga check that runs `systemctl list-units --failed` and alerts if any service (scheduled or daemon style) has failed for any reason. The systemd units are "fluffier" (more lines and more characters of overhead) than crontabs, but that's not a true increase in complexity. All told, with this change, it feels like things are a bit simpler and easier to work on while achieving a bit better results. It's a modest "quality of life" improvement. This is _not_ my blog, but I read it regularly and comment periodically: [1] https://utcc.utoronto.ca/~cks/space/blog/linux/SortCronLocaleDanger [2] https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdTimersAndErrors [3] https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdTimersMailNotes This one quotes my comment on article [2]: [4] https://utcc.utoronto.ca/~cks/space/blog/sysadmin/NotificationsVersusLogs -- Richard signature.asc Description: OpenPGP digital signature
Re: migration from cron.daily to systemd timers
On 1/8/20 4:25 PM, Josh Triplett wrote: > (I would suggest doing the same for the cron job, for new installations: > put the script itself in /usr/lib/spamassassin or similar, and document > that people can enable it by either enabling the systemd timer, linking > the script from cron.daily, or copying the script to cron.daily if they > really want to modify it.) It seems like this would work well. That's better than my previous proposal and the current commit, as it doesn't result in a cron.daily script starting just to exit. It looks like the existing commit uses /usr/sbin/spamassassin-maint, so I'll use that instead for the example. I personally wouldn't put this script in the PATH, but that's a separate issue. The migration would then look something like this: [ -e /etc/default/spamassassin ] && . /etc/default/spamassassin if ! [ -L /etc/cron.daily/spamassassin ] && ! TODO_check_for_local_changes ; then if [ "$CRON" = "1" ] ; then if [ -d /run/systemd/system ]; then systemctl enable spamassassin-daily-maintenance.timer rm -f /etc/cron.daily/spamassassin else ln -sf /usr/sbin/spamassassin-maint \ /etc/cron.daily/spamassassin fi else rm -f /etc/cron.daily/spamassassin fi fi So, if the user changed it, just leave everything alone. If they didn't change it and aren't using it, remove it. If they didn't change it but are using it, replace it with a symlink or a systemd unit, depending on whether systemd is in use. This covers everything except the case of: they're using it, but did not modify it, and are using systemd, but don't want systemd timers. In that case, the user would have to disable the systemd timer and add the symlink. I'd mention this in the NEWS. With this proposeal, the maintenance script should also stop checking CRON= (or for the systemd timer), and CRON= should be removed from /etc/default/spamassassin (though that needs to be done AFTER the check above fires). -- Richard signature.asc Description: OpenPGP digital signature
Re: migration from cron.daily to systemd timers
On 1/7/20 3:18 PM, Noah Meyerhans wrote: > Current the cron.daily script is a no-op by default, and functionality > is enabled by setting CRON=1 in /etc/default/spamassassin. For users > running systemd, I'd expect to ship a timer unit that is disabled by > default, and have them enable it with: > > $ systemctl enable spamassassin-daily-maintenance.timer This seems correct. It is the systemd native way to do it. > For upgrades from versions that did not include the timer, should I > enable the systemd timer if the user has set CRON=1? Or should I leave > the timer disabled and preserve the original behavior via cron.daily? > Since the cron script is a conffile, and may have local modifications, I > think it should be left in place, but would take confirmation. It'd be > possible to perform the migration while still preserving local > modifications, e.g. by having the shipped cron script enable the unit > file, but IMO that would be gross. Could you check for local modifications and only enable the timer if there were NOT local modifications? [ -e /etc/default/spamassassin ] && . /etc/default/spamassassin if [ -d /run/systemd/system ] && [ "$CRON" = "1" ] && ! some_check_for_local_modifications then systemctl enable spamassassin-daily-maintenance.timer fi > If the timer and the cron activity are both enabled, the cron script > will be a no-op. This is accomplished with the following in the cron > script: > > if command -v systemctl > /dev/null 2>&1 && >systemctl is-enabled spamassassin-daily-maintenance.timer; then > exit 0 > fi > > Would you do this a different way? If it was me, I'd just check for whether systemd is running (e.g. [ -d /run/systemd/system ]), not whether the timer unit is enabled. That way, at least moving forward, you're only supporting two scenarios (systemd uses the units, non-systemd uses cron) rather than three (those two plus the option of systemd systems still using cron). If you were doing this new, I would suggest that you use cron.d instead of cron.daily. Then check for systemd by prefixing your command with: [ -d /run/systemd/system ] || ... This way, if the user installs systemd-cron (which replaces crond and generates systemd service & timer units from cron files), it will not generate units for the cron job. See: https://github.com/systemd-cron/systemd-cron/blob/master/src/bin/systemd-crontab-generator.py#L335 Unfortunately, there is currently no equivalent for /etc/cron.daily, as systemd-cron just runs run-parts. It does not convert each cron.daily script into a separate service. I filed a feature request for that back in 2016, and it's gotten another look recently. I may have some time to work on it again this year and propose a patch if nobody beats me to it: https://github.com/systemd-cron/systemd-cron/issues/47 If you wanted, you could migrate from /etc/cron.daily to /etc/cron.d and then apply this approach, but you'd still have the "local modifications" problem. If you are willing to drop support for direct local modifications, then you could use cron.d and disable the script in cron.daily. This would give you the simplest solution moving forward, but would require explicit action from anyone who had customized the cron.daily script. -- Richard signature.asc Description: OpenPGP digital signature
Re: watch files and .gitattributes export-ignore
On 12/12/19 2:48 AM, Jean-Michel Vourgère wrote: > Upstream of phppgadmin has nice unit tests in its github.com repository, but > they use a .gitattributes file [1] to strip these tests files from the > distributed tar files: All the unit tests are missing from the orig.tar. Have you asked upstream to ship the tests in the tarball? -- Richard signature.asc Description: OpenPGP digital signature
Re: Namespaces for Lintian Tags
On 11/20/19 3:01 PM, Sean Whitton wrote: > For example, I would request obsolete-national-encoding@debian/copyright > rather than national-encoding@debian/copyright. Or perhaps obsolete-encoding@? -- Richard signature.asc Description: OpenPGP digital signature
Re: Usage of DEP5
On 11/7/19 7:40 AM, Thorsten Glaser wrote: > I also often deal in software which > has more… flexibility than the DEP 5 format allows, or where it is > plain simpler. Would you be willing to share an example, at a minimum just the name of the package? -- Richard
Git Branch Names / DEP-14 (Was: Re: Summary: Git Packaging Round 2 [comments by 11/05/2019])
On 11/5/19 9:51 PM, Nicholas D Steeves wrote: > Richard Laager writes: >> I'd love to see more information about a recommended branch >> structure. FWIW, I've been using branches named for each release >> (e.g. "sid" is the default, but I also have "buster" for a (proposed) >> stable update, will likely soon have "buster-backports"). This works >> really well, and also scales to also having branches for Ubuntu >> (e.g. I have "bionic" and "cosmic" too due to some SRUs). It also >> keeps "master" available for the upstream master branch. This seems so >> obvious and wonderful to me, but I'm not sure how popular it is. As I moved my first package to Salsa and was rethinking everything, I switched from "sid" to "unstable", for reasons that will come up below. > https://dep-team.pages.debian.net/deps/dep14 > > It sounds like you're already using something similar :-) I had forgotten about DEP-14 until it was mentioned earlier today by Feri . I'll likely rename my branches again to add the debian/ prefix, to be in compliance with DEP-14. DEP-14 specifies three options for development releases: debian/master (the recommended default) debian/sid debian/unstable Having three names increases inconsistency between packages, which seems to me contrary to the goal of DEP-14. If someone is working with both unstable and experimental, then they must use two branches to differentiate them. DEP-14 says to do so with debian/experimental for experimental. So far, so good. For unstable, DEP-14 says to use debian/sid or debian/unstable. Why not A) pick *one* of those, and B) always use it, never using debian/master? As for _which_ one (debian/sid or debian/unstable)... The DEP-14 recommended branch names for stable release are debian/CODENAME. The recommended branch name for experimental is debian/experimental. These, plus debian/unstable, but not debian/master or debian/sid, are consistent with distribution names from debian/changelog and the .changes file. [0] Therefore, it seems like one should use debian/unstable. [0] https://www.debian.org/doc/debian-policy/ch-controlfields.html#id25 -- Richard signature.asc Description: OpenPGP digital signature
Re: Summary: Git Packaging Round 2 [comments by 11/05/2019]
This all looks very good. Presumably the repository / Salsa project name should match the source package name? If so, that might be good to note, at least as the default. I'd love to see more information about a recommended branch structure. FWIW, I've been using branches named for each release (e.g. "sid" is the default, but I also have "buster" for a (proposed) stable update, will likely soon have "buster-backports"). This works really well, and also scales to also having branches for Ubuntu (e.g. I have "bionic" and "cosmic" too due to some SRUs). It also keeps "master" available for the upstream master branch. This seems so obvious and wonderful to me, but I'm not sure how popular it is. I'm currently maintaining my packages on GitHub, but I'm going to move them to Salsa shortly to follow the consensus recommendation. I'm not a DD (and not a DM either, though I'm finally getting around to applying). Unfortunately, this means I have the, IMHO obnoxious, -guest suffix on my Salsa account. I certainly don't want to create things under that namespace, and it's doubly painful because if I ever become a DD, my username would change. So I'm asking my sponsor to create projects in the debian namespace. Of course, that's the recommendation anyway, so the -guest might be an inadvertent feature because it's encouraging me to use the debian team. :) I understand that DMs are quite literally second-class citizens (and non-DM package maintainers are third-class), but I really wish that things like Salsa usernames didn't call that out. If this message is threaded wrong, my apologies. While I am now, I was not subscribed to debian-devel at the time. I have tried to set In-Reply-To directly, but this is my first attempt at doing so. In these situations, I would normally download the mbox archive, import it, and reply to the message that way, but mbox archives are seemingly unavailable (at least to non-DDs?) for Debian lists. -- Richard signature.asc Description: OpenPGP digital signature
