Re: Editor extensions to help editing debian/* files?
> I looked into better tooling/editor support in general for Debian > languages in general. I think the industry answer is that "someone" > ought to build a "language (LSP) server" for the Debian languages, which > would enable editors with LSP support[1] to get the same basic features. True - LSPs is the common API into linters (and more) nowadays, but I was ready to settle with something simpler, as building a LSP for Debian I imagine is a lot of work.. .. > I might have a stab at writing a prototype for a LSP for Debian formats. ..however, if you start doing a minimal prototype it would be a great! Who knows if the LSP some day in the future would forward snippets to a Debian-specific LLM that would give hints on what needs to be changed to conform to the Debian policy :)
Re: Editor extensions to help editing debian/* files?
Otto Kekäläinen:
Hi!
Thanks for the tip, Niels!
It would be cool if dh_assistant had some kind of generic command like
"dh_assistant validate" which would attempt to introspect all
information silently and emit output only if it fails to parse
something.
That might be an option. The question is what more would you expect here
that is actually feasible to implement. :)
Feel free to propose concrete ideas and I will have a look at them.
Sadly, debhelper was never designed to be introspect-able, but depending
on the ask it might be doable or doable with some limitations.
Additionally it could emit a non-zero exit code on errors.
I tested your latest command and it works as you expected, though it
does not use exit code.
> # dh_assistant detect-unknown-hook-targets
The hook target override_dh_car_configure in debian/rules does not
seem to match any known commands.
# echo $?
0
Adding an exit 2 as a "linter" exit code in the next version with a
"--no-linter-exit-code" (open for better names) to have it always return
0 (which I suspect will be easier for some users).
Also if the JSON included the filename and line number of the finding
it would be handy:
{
"unknown-hook-targets": [
{
"candidates": [],
"filename": "debian/rules",
"target-name": "override_dh_car_configure"
}
]
}
I would be happy to include that. Unfortunately, I only have the
information available from:
LC_ALL=C make -Rrnpsf debian/rules debhelper-fail-me 2>/dev/null
Which seems to have the following limitations:
* filename/line is *not* included for "empty" targets
* When a line number is present, it is for the first line of the recipe
and not the target definition itself. One might be tempted to do
(lineno - 1) but it is not accurate[0].
I am open to suggestions for this that does not involve parsing the
makefile itself. I will leave ad-hoc parsing of Turing complete
languages to other programs.
I don't know how much ambition you have for expanding the scope of
dh_assistant.
The dh_assistant tool is growing organically based on requests, or
things I need, or when I notice people needing to introspect something
and I can easily provide it via dh_assistant. :)
I did not aim for it to be a full-fledged linter, though I do not mind
adding debhelper related linting where possible.
We already have Lintian which has a massive amount of
checks, including ones related to debian/rules. It is just a pity
Lintian does not support checking a single file or the debian/
directory contents without building the package.. [1]
[1] https://bugs.debian.org/262783
The infrastructure and design choices of lintian is working against
lintian here. I doubt #262783 will ever be solved as there is a major
difference between a 'clean assembled packages' and the '"mess" you call
a git checkout".
Even if we get #262783, a lot of lintian checks are written to check
.deb packages because that is the final result and you avoid a lot of
"what if d/rules decided to do X - what if it does *not* do X"
ambiguity. Which the person who does #262783 would probably also spend a
lot of effort porting binary checks in to the ("dirty") source context
where you have less context.
I looked into better tooling/editor support in general for Debian
languages in general. I think the industry answer is that "someone"
ought to build a "language (LSP) server" for the Debian languages, which
would enable editors with LSP support[1] to get the same basic features.
Among features that LSP servers can provide are:
* Configurable on save actions (such as wrap-and-sort)
* Format file on user request (wrap-and-sort, again)
* Diagnostics (linting)
* Text highlighting / inline documentation / inlay hints
* Auto-completion
The first half is basically what you are looking for and the latter half
is what I have been focusing on in my plugin, so it does seem to cover
our interests.
I might have a stab at writing a prototype for a LSP for Debian formats.
But it will not be in `dh_assistant`.
Best regards,
Niels
--
[0]: Sample makefile
"""
my-target:
# Some makefile level comment (not indented)
first line of the target definition
"""
Here the line number reported by make would be 3, but the target
definition is actually line 1 (so doing a -1 would be "off by one per
line of comment")
[1]: Which allegedly includes:
* emacs via eglot (?), which comes built-in these days
* neovim
* atom/pulsar via plugin (?)
* IDEA via open source plugin or builtin via their paid subscription
Re: Policy: versioning between releases
Hi, On 1/21/24 21:35, Matthias Urlichs wrote: Now … does that apply to crossing release boundaries? Specifically, if foo/testing requires bar >=1.1 to work but just states "Depends: bar >=1", and bar/stable is 1.0.42 … is that a bug? If so which severity? I'd say yes, with normal severity. There is no guarantee that releases will be upgraded atomically. Depending on the package in question, a too-loose dependency might even break release upgrades, and this information is also important for backports. There is also no good reason not to update the package in testing/unstable. Simon
Re: X-Windows on PPC in Debian SID
> "Stan" == Stan Johnson writes: Stan> sysvinit-core. But if wdm really does require systemd now, Stan> that might explain this issue, with other X packages being Stan> dependent on either wdm or systemd. As I recall, wdm is the It does not look like wdm requires systemd. I set up a podman container, installed sysvinit-core (*), and then installed wdm. I did not end up with systemd. This is amd64, not powerpc though. (*) I ran into trouble with sysvinit-core crashing my container on first install. Bug filed.
Re: Editor extensions to help editing debian/* files?
Hi!
Thanks for the tip, Niels!
It would be cool if dh_assistant had some kind of generic command like
"dh_assistant validate" which would attempt to introspect all
information silently and emit output only if it fails to parse
something. Additionally it could emit a non-zero exit code on errors.
I tested your latest command and it works as you expected, though it
does not use exit code.
# dh_assistant detect-unknown-hook-targets
The hook target override_dh_car_configure in debian/rules does not
seem to match any known commands.
# echo $?
0
Also if the JSON included the filename and line number of the finding
it would be handy:
{
"unknown-hook-targets": [
{
"candidates": [],
"filename": "debian/rules",
"target-name": "override_dh_car_configure"
}
]
}
I don't know how much ambition you have for expanding the scope of
dh_assistant. We already have Lintian which has a massive amount of
checks, including ones related to debian/rules. It is just a pity
Lintian does not support checking a single file or the debian/
directory contents without building the package.. [1]
[1] https://bugs.debian.org/262783
Re: X-Windows on PPC in Debian SID
Hi Colin, On 1/21/24 3:22 PM, Stan Johnson wrote: > ... > > I'll also try installing systemd first (and let sysvinit-core be > uninstalled), then I'll run "apt-get dist-upgrade", then re-install > sysvinit-core and see if that disables systemd and lets the X packages > remain. I've noticed before that some packages claim to be dependent on > systemd, but they'll continue to work if systemd is installed and then > replaced by sysvinit-core. But if wdm really does require systemd now, > that might explain this issue, with other X packages being dependent on > either wdm or systemd. As I recall, wdm is the last X login manager that > didn't require systemd (I think xdm and lightdm both require systemd, at > least as compiled in Debian). Please see attached (my comments are preceded by "***"). The bottom line is that there appears to be a dependency issue in Debian SID at the moment that makes wdm (and other X-Windows packages such as the Xorg server) dependent on systemd, even if systemd is already installed, regardless of whether systemd is being used as the init (that may not be quite correct, but it appears that way from the attached file). Removing sysvinit-core manually (after the "apt-get upgrade" step) results in systemd being used as the init. But even then, "apt-get dist-upgrade" deletes the X-Windows packages. For now, I'll restore my rootfs to just after my last "apt-get upgrade". thanks -Stan ppc-g4_01202024.txt.xz Description: Binary data
Re: build profile proposal: nogir (second try)
Hi Simon,
On Sun, Jan 21, 2024 at 03:24:25PM +, Simon McVittie wrote:
> > How annoying would it actually be to split this to a
> > different source package?
>
> Really quite annoying. [...]
You gave more than sufficient reason. I won't argue.
> If porters are interested in making bootstrap automatic despite cycles
> like this one, I think a better route would be to be able to have
> a list of suggested bootstrap steps and build-order considerations,
> either centralized in some sort of cross infrastructure or distributed
> among packages. I'd be fine with adding something like this to glib2.0,
> for example, if it helped:
>
> Bootstrap-Before: dbus, gobject-introspection
> Bootstrap-Build-Profiles: nogir, nocheck, noinsttest
We effectively tried the approach of encoding bootstrap-info into
individual packages with stage profiles and that was a bad idea. What
stages are needed can (and does) change. For instance, we no longer need
glibc's stage1 profile and go to stage2 directly. Hence, we try to more
and more use profiles that change a particular aspect of a package in an
obvious and isolated way and externally maintain how these are to be
combined into a successful bootstrap.
> Or, if we separated the nogir build profile that I'm proposing here into
> two, something like this:
>
> nogir-changing-content
> can change content: Y ("unreproducible"/"unsafe" profile)
> can change package set: Y
> nogir
> can change content: N ("reproducible"/"safe" profile)
> can change package set: Y
>
> would that allow automatic bootstrapping infrastructure to figure out
> that it was both safe and desirable to build glib2.0 with nogir?
I've considered this option for other profiles already and did not find
it appealing. Often times, you are interested in enabling the profile
without caring about whether it changes package contents, but such a
split would require you to figure out which of the profiles you need (or
simply both?).
More and more I think that merely documenting which instances of these
profiles are reproducible would be a better approach. I've had this
float as a vague idea since a while:
XS-Reproducible-Profiles: nogir
It's a promise that a source package can issue about a subset of the
profiles it supports. It bears some similarity to "Multi-Arch: foreign"
in the sense that both are promises on how the interface behaves. In
particular, such a declaration would be machine-checkable. We could
simply run an autobuilder that verifies whether such declarations are
practically correct (on amd64).
Bootstrappers do not really need that separation into two different
profile names that you propose. Having the information of which profiles
are reproducible in which source packages (and which packages get
disabled when enabling the profile), is what is needed.
So this is what I prefer, but it still comes at a cost. We're up for
changing lots of packages to declare these headers. And we're up for
setting QA to verify these. I fear I cannot provide the capacity to do
all of this and hence I have not pushed this forward.
Manually ordering glib2.0 in the bootstrap tooling may be annoying, but
that's about it. It still is way less work than any of the alternatives.
> (I infer that there must be some sort of infrastructure that knows that
> it's safe to build packages with "nocheck,noinsttest", otherwise glib2.0
> and dbus are already in a cyclic dependency for their test suites.)
Not really. nocheck and noinsttest are issued by default and simply
assumed to do the right thing in all cases.
> [...] I'm sorry if that's
> causing extra work for your use-case.
Yes, that's causing extra work on my side, but that extra work is really
low compared to the extra work on your side for the alternative. That
makes the choice rather obvious to me. Also having this advance warning
further lowers the cost on my side. You answered my question in way more
detail than expected. Thank you.
Helmut
Re: X-Windows on PPC in Debian SID
Hi Colin, Thanks for your reply. On 1/21/24 12:35 PM, Colin Watson wrote: > On Sun, Jan 21, 2024 at 10:41:05AM -0700, Stan Johnson wrote: >> I have a PowerMac G4 MDD (two 1.25 GHz CPUs, 2 GiB memory) that has been >> running Debian SID for years. It was last updated on 15 Oct 2023, with >> no problems. Yesterday, the update failed. Specifically, "apt-get >> update" worked, "apt-get upgrade" worked, and "apt-get dist-upgrade" >> worked but deleted ~500 MB of X Windows packages, including Xorg, wdm, >> etc. So the system currently is text-only in Debian SID. > > This sort of thing sometimes happens in unstable due to various > dependency issues that are typically filtered out of testing; you're > expected to keep a reasonably close eye on what upgrades are going to do > and say no if the result is unsuitable. Yes, I usually ignore the list knowing that I can go to a previous backup made just after "apt-get upgrade", which is the same as saying no at "apt-get dist-upgrade". So I can restore that backup, then run "apt-get dist-upgrade" and capture the output. > > The proximate cause may or may not be sysvinit/systemd. The best thing > would be if you still have a record of the terminal log, but it's > possible you don't. > >> This system is using sysvinit instead of systemd, and perhaps that's the >> problem? I noticed when I tried to reinstall wdm, apt wanted to remove >> sysvinit and presumably use systemd as the init program. > > What happens if you try "apt install wdm sysvinit" to nudge it into not > doing that? > I'll try that. I expect it will complain that wdm and sysvinit are incompatible. The "apt-get dist-upgrade" didn't actually delete sysvinit, but it appears to have deleted packages that require systemd to be the init program, and any packages that depend on those packages. I'll also try installing systemd first (and let sysvinit-core be uninstalled), then I'll run "apt-get dist-upgrade", then re-install sysvinit-core and see if that disables systemd and lets the X packages remain. I've noticed before that some packages claim to be dependent on systemd, but they'll continue to work if systemd is installed and then replaced by sysvinit-core. But if wdm really does require systemd now, that might explain this issue, with other X packages being dependent on either wdm or systemd. As I recall, wdm is the last X login manager that didn't require systemd (I think xdm and lightdm both require systemd, at least as compiled in Debian). -Stan
Re: X-Windows on PPC in Debian SID
On Sun, Jan 21, 2024 at 10:41:05AM -0700, Stan Johnson wrote: > I have a PowerMac G4 MDD (two 1.25 GHz CPUs, 2 GiB memory) that has been > running Debian SID for years. It was last updated on 15 Oct 2023, with > no problems. Yesterday, the update failed. Specifically, "apt-get > update" worked, "apt-get upgrade" worked, and "apt-get dist-upgrade" > worked but deleted ~500 MB of X Windows packages, including Xorg, wdm, > etc. So the system currently is text-only in Debian SID. This sort of thing sometimes happens in unstable due to various dependency issues that are typically filtered out of testing; you're expected to keep a reasonably close eye on what upgrades are going to do and say no if the result is unsuitable. The proximate cause may or may not be sysvinit/systemd. The best thing would be if you still have a record of the terminal log, but it's possible you don't. > This system is using sysvinit instead of systemd, and perhaps that's the > problem? I noticed when I tried to reinstall wdm, apt wanted to remove > sysvinit and presumably use systemd as the init program. What happens if you try "apt install wdm sysvinit" to nudge it into not doing that? -- Colin Watson (he/him) [cjwat...@debian.org]
X-Windows on PPC in Debian SID
Hello, I have a PowerMac G4 MDD (two 1.25 GHz CPUs, 2 GiB memory) that has been running Debian SID for years. It was last updated on 15 Oct 2023, with no problems. Yesterday, the update failed. Specifically, "apt-get update" worked, "apt-get upgrade" worked, and "apt-get dist-upgrade" worked but deleted ~500 MB of X Windows packages, including Xorg, wdm, etc. So the system currently is text-only in Debian SID. This system is using sysvinit instead of systemd, and perhaps that's the problem? I noticed when I tried to reinstall wdm, apt wanted to remove sysvinit and presumably use systemd as the init program. I realize that systemd is Debian's default init system, and perhaps X-Windows was always destined to eventually require systemd in Debian. If that's what has happened, please let me know. thanks for any information -Stan Johnson
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
Hi, Helmut. I'm very sorry for responding to an 8-months old letter, but I think my message is important. Helmut Grohne: > * mmdebstrap operates in two phases. It first unpacks and configures a > rather minimal set of packages and then proceeds to adding packages > passed to --include in a second phase once essential is fully > configured while debootstrap immediately unpacks everything. > > I think the debootstrap approach is slightly worse here, because it > means that preinst scripts of non-essential packages cannot rely on > essential packages having been configured. This is not true. Here is output of debootstrap: https://paste.debian.net/1304816/ . We created current sid from sid. As you can see, mc unpacked in very last stage. The same can be seen in debootstrap.log: https://paste.debian.net/1304817/ Moreover, I did another experiment: I did run debootstrap and aborted it immediately after output "Unpacking the base system..." The resulting system did not contain "mc" binary at all! (This is answer to https://lists.debian.org/debian-dpkg/2023/05/msg00080.html ) -- Askar Safin
Re: Policy: versioning between releases
Hi, On 21-01-2024 16:08, Matthias Urlichs wrote: However according to our release notes we only support upgrading from release x to x+1, skipping releases is not allowed. I'm not talking about skipping releases but about partial upgrades. Thus … > foo/testing requires bar >=1.1 to work but just states "Depends: bar >=1", and bar/stable is 1.0.42 assume that Stable has bar/stable==1.0.42 and foo/stable==2.1, while Testing has foo/stable==2.2. $USER adds Testing (or possibly stable/backports) to their apt.sources, updates foo, observes breakage, and now needs to dig through dependencies to figure out what went wrong. Because of the way we do QA on unstable to testing migration, we are in practice finding more and more of these cases. Which also means that we're supporting partial upgrades better over time. With my Release Team member hat on, I think we find these versioned relations increasingly more important to properly document, albeit not (yet?) at RC level. If I were to judge the severity, I think missing a *versioned* relation is typically severity important if with the older version (in testing or stable) a binary package (from unstable or testing) hardly works. Quite a lot of autopkgtest failures that I reported over the years fall in this category and I have not seen push back for adding the versioned relation in case of breakage of the binary's functionality. (Solving test breakage in case of version skew with versioned relations has seen push back occasionally, but that's not what we're discussing here (and I agree that regularly that's overkill)). So when I, as a maintainer, notice a problem along these lines, do I file a bug? Yes please. The solution is simple (in most cases, except for key packages and loops) while the maintenance price isn't that high (e.g. the janitor even helps to get rid of an obsolete versioned relation). Conversely, when I get this sort of bug report for one of my packages, is it OK to reply "that's not supported, go away"? I claim that nowadays we (as a project) don't expect our maintainers to reply like that. Yes, as far as I know partial upgrades are still not officially supposed to always work, but I think in practice it works quite well, so I think we support it as far as "it works most of the time reasonably well in reasonable configurations". Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Policy: versioning between releases
On 2024-01-21 Matthias Urlichs wrote: > On 21.01.24 15:34, Andreas Metzler wrote: > > However according to our release notes we only support upgrading from > > release x to x+1, skipping releases is not allowed. > I'm not talking about skipping releases but about partial upgrades. eah, but it still answers your question. ... > Thus … > > foo/testing requires bar >=1.1 to work but just states "Depends: bar >=1", > and bar/stable is 1.0.42 > assume that Stable has bar/stable==1.0.42 and foo/stable==2.1, while Testing > has foo/stable==2.2. $USER adds Testing (or possibly stable/backports) to > their apt.sources, updates foo, observes breakage, and now needs to dig > through dependencies to figure out what went wrong. ... If testing's foo 2.2 required bar >> 1.0.42 it would need to have a respective *versioned* dependency. > Yes I know that this cannot happen when people simply dist-upgrade, [...] I strongly disagree. A dist-upgrade is not atomic. foo and bar will/can be upgraded at separated dpkg runs by apt. If the dependencies are not strong enough we would see breakage. cu Andreas
Bug#1040971: ITP: hyprland -- dynamic tiling Wayland compositor based on wlroots
Package: wnpp Followup-For: Bug #1040971 Owner: Alan M Varghese X-Debbugs-Cc: debian-devel@lists.debian.org, a...@digistorm.in * Package name: hyprland Version : 0.34.0 Upstream Contact: vaxerski * URL : https://github.com/hyprwm/Hyprland * License : BSD-3-Clause Programming Lang: C++ Description : dynamic tiling Wayland compositor based on wlroots - From the readme: " Hyprland is a dynamic tiling Wayland compositor based on wlroots that doesn't sacrifice on its looks. It supports multiple layouts, fancy effects, has a very flexible IPC model allowing for a lot of customization, a powerful plugin system and more. " Upstream for Hyprland provides a source tarball with all its submodules packaged together. I intend to package them as-is and not separate out wlroots (don't know if that would even be possible; a custom wlroots binary is built and linked against during the build process).
Bug#1061255: ITP: custodian -- flexible just-in-time job management framework in Python
Package: wnpp Severity: wishlist Owner: Drew Parsons X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org, debian-scie...@lists.debian.org, debichem-de...@lists.alioth.debian.org * Package name: custodian Version : 2024.1.9 Upstream Contact: Shyue Ping Ong * URL : https://github.com/materialsproject/custodian * License : MIT/X Programming Lang: Python Description : flexible just-in-time job management framework in Python Custodian is a simple, robust and flexible just-in-time (JIT) job management framework written in Python. Using custodian, you can create wrappers that perform error checking, job management and error recovery. It has a simple plugin framework that allows you to develop specific job management workflows for different applications. Error recovery is an important aspect of many high-throughput projects that generate data on a large scale. When you are running on the order of hundreds of thousands of jobs, even an error-rate of 1% would mean thousands of errored jobs that would be impossible to deal with on a case-by-case basis. The specific use case for custodian is for long running jobs, with potentially random errors. For example, there may be a script that takes several days to run on a server, with a 1% chance of some IO error causing the job to fail. Using custodian, one can develop a mechanism to gracefully recover from the error, and restart the job with modified parameters if necessary. The current version of Custodian also comes with several sub-packages for error handling for Vienna Ab Initio Simulation Package (VASP), NwChem, QChem, FEFF, Lobster and CP2K calculations. Custodian has been developed by the Materials Project team responsible for pymatgen, and is used to manage tests for emmet-core etc. It is a general python package, but designed for computational chemistry. It could arguably be managed by the Debian Python Team, but probably best to keep it alongside pymatgen managed by the Debichem team.
Re: Editor extensions to help editing debian/* files?
Niels Thykier: [...] Btw, `debhelper` has a `dh_assistant` command that can do some very basic analysis as well. Not sure any of it is useful for editor integration (especially because some of the features requires that it receives the same arguments as `dh` or/and `dh_auto_configure`). Personally, I have used `dh_assistant detect-hook-targets` to detect which overrides that `dh` would pick up (relies heavily on "Build-Depends: dh-sequence-foo" style add ons though). Admittedly, not in an editor context but if you can combine it with something that reads known make file targets, you could get a "override_typo looks like an override target but `dh` does not recognize it"-style warning out of it. Maybe I should just add that feature directly to `dh_assistant`. Then you can have one more command for your checklist! :D Best regards, Niels Ok, added this to debhelper/13.11.10: $ apt satisfy 'debhelper (>= 13.11.10), libtext-levenshtein-perl' $ dh_assistant detect-unknown-hook-targets [--output-format=json] The code can have false positives - especially if you use `dh ... --with ...`. In that case, you have to pass the same `--with ...` to `dh_assistant` to avoid the false positive. All the more reason to use declarative `Build-Depends: dh-sequence-foo`. For machine output use the JSON format (lintian/lintian-brush, etc.). The text output is subject to change. MRs for improvements welcome at https://salsa.debian.org/debian/debhelper/ End sidebar/thread hijack. Best regards, Niels
Re: build profile proposal: nogir (second try)
On Thu, 18 Jan 2024 at 11:08:30 +0100, Helmut Grohne wrote:
> On Wed, Jan 17, 2024 at 11:38:09PM +, Simon McVittie wrote:
> > The only package where I'm sure that I intend to separate out the GIR
> > XML in the short term is src:glib2.0
>
> How annoying would it actually be to split this to a
> different source package?
Really quite annoying. The reason I'm integrating the GIR build into
the glib2.0 source package now is that upstream have done the same,
which allows the different parts to become increasingly tightly-coupled
in future (and I don't think upstream would be putting in this work if
they didn't intend to make use of that ability).
A snapshot of glib2.0 that takes over the GIR build is waiting in NEW
for ftp team approval:
https://ftp-master.debian.org/new/glib2.0_2.79.0+git20240119~62ee8bf6-1.html
https://salsa.debian.org/gnome-team/glib/-/tree/debian/2.79.0+git20240119_62ee8bf6-1?ref_type=tags
It's an upstream git snapshot rather than a formal prerelease, because
quite a lot is still changing in this area, and packaging a snapshot
seemed more applicable to future versions than backporting selected fixes
into the 2.79.0 prerelease; but this is going to be stable API/ABI in
GLib 2.80, due for release in March.
To make GLib properly robust I think we will want the ability to use
lockstep version dependencies here, but uploading two source packages
(with identical source code and different packaging) every time there
is a glib2.0 bug fix, and breaking the release team's ability to binNMU
them independently, seems like a high price to pay for making bootstrap
a little more automatic.
If porters are interested in making bootstrap automatic despite cycles
like this one, I think a better route would be to be able to have
a list of suggested bootstrap steps and build-order considerations,
either centralized in some sort of cross infrastructure or distributed
among packages. I'd be fine with adding something like this to glib2.0,
for example, if it helped:
Bootstrap-Before: dbus, gobject-introspection
Bootstrap-Build-Profiles: nogir, nocheck, noinsttest
Or, if we separated the nogir build profile that I'm proposing here into
two, something like this:
nogir-changing-content
can change content: Y ("unreproducible"/"unsafe" profile)
can change package set: Y
nogir
can change content: N ("reproducible"/"safe" profile)
can change package set: Y
would that allow automatic bootstrapping infrastructure to figure out
that it was both safe and desirable to build glib2.0 with nogir?
(I infer that there must be some sort of infrastructure that knows that
it's safe to build packages with "nocheck,noinsttest", otherwise glib2.0
and dbus are already in a cyclic dependency for their test suites.)
> given that it
> formerly was part of src:gobject-introspection, it cannot be unworkable
The fact that this worked in gobject-introspection was a big exception
to more usual practices, and it worked by copy/pasting and committing
all the doc-comments from glib2.0 into a large "source" file in
gobject-introspection. I don't think anyone really wanted this, but it
was considered a necessary evil to break cyclic dependencies.
As a result of that workaround, project members with a particularly
uncompromising definition of preferred forms for modification have
already required us to duplicate the rest of the src:glib2.0 source into
src:gobject-introspection (implemented as a secondary orig.tar.xz), and
then duplicate all of its copyright information in gobject-introspection's
d/copyright, which was rather unwieldy to say the least.
I personally think a compilation of doc-comments in editable text
form is an entirely valid form of source from which Debian users can
exercise all of their Free Software rights, but it seemed that there
was no consensus on this. Doing a bunch of tedious administrative work
and increasing the size of the gobject-introspection source package by
500% seemed more likely to succeed than getting into a fight about the
semantics of the DFSG with preferred-form-for-modification maximalists,
so I did what I had to do.
I do have limited patience for doing extra volunteer work that I think
is neither fun nor constructive, though, so I would prefer to remove the
situation that made this necessary by making use of the tools that we
have (including build profiles and cross-compiling). I'm sorry if that's
causing extra work for your use-case.
smcv
Re: Policy: versioning between releases
On 21.01.24 15:34, Andreas Metzler wrote: However according to our release notes we only support upgrading from release x to x+1, skipping releases is not allowed. I'm not talking about skipping releases but about partial upgrades. Thus … > foo/testing requires bar >=1.1 to work but just states "Depends: bar >=1", and bar/stable is 1.0.42 assume that Stable has bar/stable==1.0.42 and foo/stable==2.1, while Testing has foo/stable==2.2. $USER adds Testing (or possibly stable/backports) to their apt.sources, updates foo, observes breakage, and now needs to dig through dependencies to figure out what went wrong. Yes I know that this cannot happen when people simply dist-upgrade, but IMHO the world isn't always that simple. So when I, as a maintainer, notice a problem along these lines, do I file a bug? Conversely, when I get this sort of bug report for one of my packages, is it OK to reply "that's not supported, go away"? -- -- mit freundlichen Grüßen -- -- Matthias Urlichs OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Policy: versioning between releases
Quoting Matthias Urlichs (2024-01-21 13:35:05) > question: policy 3.5 states, rather unequivocally, > > Every package must specify the dependency information about other > packages that are required for the first to work correctly. > > Now … does that apply to crossing release boundaries? Specifically, if > foo/testing requires bar >=1.1 to work but just states "Depends: bar > >=1", and bar/stable is 1.0.42 … is that a bug? If so which severity? > > If not, shouldn't that be mentioned somewhere in Policy? Offhand I > didn't find anything that even mentions Debian suites / releases, but > admittedly I only skimmed the table of content and didn't re-read the > whole thing. It is not a bug to fail at predicting *future* breakage, which - if I understand you correctly - is what you are describing above. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Policy: versioning between releases
On 2024-01-21 Matthias Urlichs wrote: > question: policy 3.5 states, rather unequivocally, >Every package must specify the dependency information about other >packages that are required for the first to work correctly. > Now … does that apply to crossing release boundaries? Specifically, if > foo/testing requires bar >=1.1 to work but just states "Depends: bar >=1", > and bar/stable is 1.0.42 … is that a bug? If so which severity? > If not, shouldn't that be mentioned somewhere in Policy? Offhand I didn't > find anything that even mentions Debian suites / releases, but admittedly I > only skimmed the table of content and didn't re-read the whole thing. Hello, I also do not think policy has anything to say about our release system. However according to our release notes we only support upgrading from release x to x+1, skipping releases is not allowed. This implies that one may/should change "Depends: bar (>= 1.12)" to "Depends: bar" (in an upload to sid) once we have made a stable release that includes at least bar 1.12. IIRC https://janitor.debian.net/scrub-obsolete/ implements this algoritm. cu Andreas
Re: build profile proposal: nogir (second try)
On Wed, Jan 17, 2024 at 11:38:09PM +, Simon McVittie wrote:
> On Wed, 17 Jan 2024 at 23:15:03 +0100, Matthias Geiger wrote:
> > Does this mean we should should split out the .gir XML files from existing
> > source packages into a separate gir1.2-foo-dev (in the long run) ?
>
> That's a good question, and I don't have an easy answer for it. The
> tradeoff is:
>
> - having the GIR XML in libfoo-dev means fewer binary packages and
> therefore smaller Packages metadata;
>
> - having a separate (non-virtual) gir1.2-foo-1-dev means we can "cleanly"
> turn off GIR/typelibs in cases when they're not needed, and means
> libfoo-dev is a bit smaller and with fewer dependencies
Really, I think the main advantage of splitting them out into real
packages is the additional QA that we get. With the Provides-mechanism,
consumers will often miss the additional gir1.2-*-dev build dependency
that is required and adding those back will be a permanent duty of cross
build porters.
> It's analogous to the choice between one big -dev package (libcairo2-dev,
> libwayland-dev) or multiple smaller -dev packages (libportal*-dev) for a
> source package with more than one shared library.
The QA aspect is different there.
> The larger, more widely-used and lower-level the library is, the more I
> would be inclined to opt for the approach with extra binary packages
> - for example splitting out gir1.2-gtk-4.0-dev from libgtk-4-dev
> seems more desirable than splitting out gir1.2-shumate-1.0-dev from
> libshumate-dev. Separating out the GIR XML is more interesting for
> packages that are involved in bootstrapping, or for packages that someone
> will frequently want to cross-compile, particularly the ones you'll want
> to cross-compile early in the development of a new port when tools like
> qemu-user might not be able to target it.
In essence, you are arguing for deciding on a case-by-case way and I
concur with that. The provides mechanism seems easier for maintainers
and so I'd recommend doing that, then changing to the split mechanism
where we deem it useful.
> In the case where the GIR XML is in libfoo-dev, asking for it to have
> Provides: gir1.2-foo-1-dev means that dependent packages can depend on the
> systematic gir1.2-foo-1-dev name, and then will work correctly either way.
The real question becomes how we can continuously ensure that packages
correctly depend on these virtual facilities. I fear the simplest way is
actually splitting the binary packages. Does anyone have a better idea?
> The only package where I'm sure that I intend to separate out the GIR
> XML in the short term is src:glib2.0, where for historical reasons
> gir1.2-glib-2.0 has been built by src:gobject-introspection until
> now. I'm most of the way through preparing a version of glib2.0
> 2.79.x for experimental that takes over gir1.2-glib-2.0{,-dev}
> from src:gobject-introspection, and I definitely don't want to fold
> gir1.2-glib-2.0-dev into libglib2.0-dev, because GLib's position at the
> bottom of the GNOME stack makes it particularly important that we can
> still bootstrap and cross-compile it.
Thank you. How annoying would it actually be to split this to a
different source package? glib2.0 is involved with bootstrap at this
time and that works fully automatically *because* it is not involved
with gir. When you add gir, builders have to add the nogir profile (and
thus manually order glib2.0). If you were to split this into two
distinct source packages, you'd remove the need for applying a build
profile and thus automatic bootstrapping continues to work. Of course, I
cannot tell how that impacts the implementation, but given that it
formerly was part of src:gobject-introspection, it cannot be unworkable.
Quite definitely, such a split is not a requirement though.
Helmut
Policy: versioning between releases
Hi, question: policy 3.5 states, rather unequivocally, Every package must specify the dependency information about other packages that are required for the first to work correctly. Now … does that apply to crossing release boundaries? Specifically, if foo/testing requires bar >=1.1 to work but just states "Depends: bar >=1", and bar/stable is 1.0.42 … is that a bug? If so which severity? If not, shouldn't that be mentioned somewhere in Policy? Offhand I didn't find anything that even mentions Debian suites / releases, but admittedly I only skimmed the table of content and didn't re-read the whole thing. -- -- regards -- -- Matthias Urlichs OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Maintainers needed for debtags.debian.org
Hi Enrico (cc d-devel list), Quoting Enrico Zini (2022-10-19 15:20:43) > I would like to let go of the responsibility of maintaining > debtags.debian.org. > > Over the years I did my best to simplify the whole system, so picking up > maintenance shouldn't be too hard, if there is interest. > > I'm going to keep the service in life support until bookworm releases, > and if no other DD has picked up its maintenance by then, I'm going to > announce a plan for taking it offline. > > debtags.debian.org is a Django site. Its code is at > https://salsa.debian.org/debtags-team/debtagsd I can offer to maintain hosting and packaging of debtags code projects. Would that be helpful, or are/were you looking for new code maintainer? Sorry for not chiming in way way earlier. When you posted the above, I silently assumed that you were in need of a code maintainer, for which I consider myself a lousy fit. Only recently in another thread here on d-devel, Paul Wise made me realize that you might have interest in skills that I do feel confident in offering. I have also reached out to others who might potentially have interest and skills needed - again inspired by input from Paul Wise. If this action is too late and/or too little, then I understand, and apologize. Thanks for all your work on debtags over the years! Btw, is another communication channel perhaps more suitable than this? https://wiki.debian.org/Teams/DebTags lists a mailinglist, but that one doesn't exist, and indeed seems discontinued according to https://wiki.debian.org/Debtags Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Editor extensions to help editing debian/* files?
Otto Kekäläinen: Hi! What editors and extensions are you using to augment your productivity and minimize mistakes when editing debian/* files? I am aware of dpkg-dev-el for Emacs mentioned in the DD reference[1]. I am a big fan of Pulsar[2] and recently found a 'language-debian' plugin for Pulsar[3], but didn't get it to emit any errors/messages. I would be interested to learn what editors and integrations others use specifically for debian/* files. I've witnessed several old DDs stop their Debian work, and many aspiring ones give up on becoming a DD, because the Debian packaging work is so laboursome. One small thing that could ease the burden could be better editor integrations that help people write and maintain the debian/* files with less effort. - Otto [...] Hi Otto Personally, I use PyCharm/IDEA with the IDEA-debpkg plugin (the latter I wrote because there was no existing plugin) or emacs with dpkg-dev-el depending on the context. I think my use of PyCharm/IDEA started for similar reasons that you are praising Pulsar - if I need to work on another file, it would have an integration for that (like the preview pane with markdown, support for shellcheck, etc.). In most cases, PyCharm (and I presume Pulsar as well) has basic support out of the box or can hint you to a plugin based on the filename (extension based) - I do not have to hunt it down. Sadly, except for my own Debian plugin because d/control and d/changelog does not have extensions... oh well. Thanks for the command list. I have added a few of them to my todo list for my plugin. Like `wrap-and-sort` is due now that it supports comments and has better defaults out of the box. Btw, `debhelper` has a `dh_assistant` command that can do some very basic analysis as well. Not sure any of it is useful for editor integration (especially because some of the features requires that it receives the same arguments as `dh` or/and `dh_auto_configure`). Personally, I have used `dh_assistant detect-hook-targets` to detect which overrides that `dh` would pick up (relies heavily on "Build-Depends: dh-sequence-foo" style add ons though). Admittedly, not in an editor context but if you can combine it with something that reads known make file targets, you could get a "override_typo looks like an override target but `dh` does not recognize it"-style warning out of it. Maybe I should just add that feature directly to `dh_assistant`. Then you can have one more command for your checklist! :D Best regards, Niels
Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Sebastian, On Tue, Jan 09, 2024 at 10:49:23AM +0100, Sebastian Ramacher wrote: > > > > > > 22 libobs-dev > > > > > That's a change to the plugin ABI only. > > > > Can you explain how you've reached that conclusion? This is a package > > > > that failed to be analyzed in the latest run; an earlier run against > > > > Ubuntu lunar showed no change in ABI at all. > > > libobs-dev and the shared library are an oddity of obs-studio. There > > > only purpose is to build plugins. > > Ok, but it appears there are a large number of reverse-dependencies on > > libobs0 from other source packages, and there is no OTHER encoding of > > information about plugin ABI aside from this (no Provides: field on > > obs-studio). So what do you suggest here with respect to ABI skew between > > obs-studio and its plugins on armhf? > I need some more time to check the current situation. Have you had enough time to check this out? Are we ok to proceed with handling libobs0 along with the other libraries, which would address the ABI skew despite it technically not being libobs0 whose ABI is changing? > > > > > > 9 libopenmpt-dev > > > > > > > Seems to be a false positive. > > > > > > > > > > > > Your responses here are to the contents of the `sorted-revdep-count` > > > > list. > > > > This is the list of header packages that *we were unable to analyze with > > > > abi-compliance-checker*, and so in the interest of avoiding ABI > > > > mismatches > > > > and broken systems for users when upgrading on 32-bit archs, would get a > > > > package rename to be safe. > > > > This is the plan I had outlined at: > > > > https://lists.debian.org/debian-devel/2023/07/msg00232.html > > > > I am happy for any help in the form of patches to > > > > https://salsa.debian.org/adrien-n/armhf-time_t that fix the failures of > > > > these header packages to be analyzed, or explanations for how a given > > > > header > > > > package's API changes cannot affect the ABI of the runtime libraries > > > > from > > > > the source package so that we can manually exclude those libraries from > > > > the > > > > transition. I am not sure I would *recommend* that maintainers spend a > > > > lot > > > > of time on proving one or another individual library does not have an > > > > ABI > > > > breakage, especially in the long tail of libraries with few > > > > reverse-dependencies whose involvement in the transition is unlikely to > > > > substantially slow down Debian development. > I was looking at the repo but it is unclear to me how packages that can > be skipped are handled there. What would a PR look like to exclude > specific packages? The skip handling is in the block starting at https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/check-armhf-time_t?ref_type=heads#L852 Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
