Most optimal way to import NMU into existing git-builpackage repository?

[Otto Kekäläinen]

Hi,

I occasionally run into the situation that a package has been NMU'd or
otherwise updated directly into the Debian repositories,
bypassing/ignoring that a packaging git repository existed. I was
wondering what techniques other DDs use to
1) detect that the git packaging repository was bypassed/diverged?
2) bring the git repository back in sync with minimal effort?

So far, I have settled on having the deb-src for Debian sid configured
on my laptop (even though it is not running sid) and then inside the
git packaging checkout directory run for example:

gbp import-dsc --verbose --pristine-tar apt:j4-dmenu-desktop/sid

This will both check if there are any newer uploads than what git
knows about, and if needed, also download, apply and commit the
uploads using the uploader as the git author. The result of this
particular example is visible in
https://salsa.debian.org/otto/j4-dmenu-desktop/-/commit/62ea4cd6df973138e3a452b09250510da5279db4

I wanted to check if anyone knows any better techniques or mechanisms
than trying to remember to run this command manually before working on
a package?

- Otto

[Andreas Henriksson]

Hello Otto,

My way of working is very manual and possibly too labour intensive...

Post by Otto Kekäläinen
Hi,
I occasionally run into the situation that a package has been NMU'd or
otherwise updated directly into the Debian repositories,
bypassing/ignoring that a packaging git repository existed. I was
wondering what techniques other DDs use to
1) detect that the git packaging repository was bypassed/diverged?

apt-cache policy $pkgname (probably better to do rmadison or something
if you don't have all repos in your sources.list) and compare to head
debian/changelog of the source I'm about to modify.

Post by Otto Kekäläinen
2) bring the git repository back in sync with minimal effort?

1/ Look if there are any open merge requests on the salsa repo.
2/ Look at the close bug reports in the NMU and see if split up
patch series has been posted there.
3/ import the NMU as a single commit.

(Ofcourse for both 1 & 2 it's also needed to verify the diff actually
matches what was uploaded, which happens more often then you would think
is not the case.)

Post by Otto Kekäläinen
So far, I have settled on having the deb-src for Debian sid configured
on my laptop (even though it is not running sid) and then inside the
gbp import-dsc --verbose --pristine-tar apt:j4-dmenu-desktop/sid
This will both check if there are any newer uploads than what git
knows about, and if needed, also download, apply and commit the
uploads using the uploader as the git author. The result of this
particular example is visible in
https://salsa.debian.org/otto/j4-dmenu-desktop/-/commit/62ea4cd6df973138e3a452b09250510da5279db4
I wanted to check if anyone knows any better techniques or mechanisms
than trying to remember to run this command manually before working on
a package?

I would very much prefer if it was possible in Debian to not allow
the archive to get out of sync with packaging git repo (for example
when it lives under salsa.debian.org/debian which uploaders should have
access to already).
That would probably also require some "tag to upload" solution to be
implemented first I presume.

Post by Otto Kekäläinen
- Otto

Regards,
Andreas Henriksson

[Andrey Rakhmatullin]

Post by Andreas Henriksson
I would very much prefer if it was possible in Debian to not allow
the archive to get out of sync with packaging git repo (for example
when it lives under salsa.debian.org/debian which uploaders should have
access to already).

This requires making it easy for NMUers to commit changes to any such
repo, which requires standardization, which won't happen.

Besides, I'm not sure what would I do with a repo with unreleased changes
that I don't want to include in the NMU, so that part of the workflow
needs to be discussed and standardized too.

Post by Andreas Henriksson
That would probably also require some "tag to upload" solution to be
implemented first I presume.

Not sure what's the logic here, but I feel like what you thought about may
require some "tag to upload" solution not to be just implemented but also
mandated, which won't happen.

[Sean Whitton]

Hello,

Post by Andrey Rakhmatullin
Not sure what's the logic here, but I feel like what you thought about may
require some "tag to upload" solution not to be just implemented but also
mandated, which won't happen.

We do intend to automatically import all uploads back into dgit-repos.
So we will have a gitified source of truth, which is a step forward.

[Chris Hofstaedtler]

Post by Andreas Henriksson

Post by Otto Kekäläinen
I wanted to check if anyone knows any better techniques or mechanisms
than trying to remember to run this command manually before working on
a package?

I would very much prefer if it was possible in Debian to not allow
the archive to get out of sync with packaging git repo (for example
when it lives under salsa.debian.org/debian which uploaders should have
access to already).

While I understand the sentiment, ...

Post by Andreas Henriksson
That would probably also require some "tag to upload" solution to be
implemented first I presume.

..., I don't think this would be necessary in the first place, and
also there are a number of practical problems, plus the
policy/mandate problem mentioned by Andrey.

I'm just not seeing the duality of "the archive is the truth"
("preferred form of modication" or whatever people want to call it)
and "git is the truth" can really be made work.

It can work within limited workflows, where maintainers / maintainer
teams agree to mostly follow one or the other, and try to keep the
other side in sync, but it will never be a 100% thing.

If we want the 100% solution, IMO we cannot continue with the
duality. I guess someone who knows more about distributed systems
theory probably could explain on theoretical grounds why it can't
work (or why I'm wrong).

Best,
Chris

[Charles Plessy]

Post by Chris Hofstaedtler
"the archive is the truth"
"git is the truth"

Maybe you can rephrase it to "the archive is the present and git is the
future". For instance if a NMU is obsoleted by a new upstream release,
you can ignore the NMU and continue from your latest upload.

Have a nice day,

Charles

[Noah Meyerhans]

Post by Andreas Henriksson
I would very much prefer if it was possible in Debian to not allow
the archive to get out of sync with packaging git repo (for example
when it lives under salsa.debian.org/debian which uploaders should have
access to already).
That would probably also require some "tag to upload" solution to be
implemented first I presume.

Honestly I'd be happy if we could just establish some expectation that
the NMUer open a merge request for their changes. It can be merged
later without losing anything or requiring additional work. Enforcement
of this expectation would be even better, of course.

noah

[Andrey Rakhmatullin]

Post by Noah Meyerhans

Post by Andreas Henriksson
I would very much prefer if it was possible in Debian to not allow
the archive to get out of sync with packaging git repo (for example
when it lives under salsa.debian.org/debian which uploaders should have
access to already).
That would probably also require some "tag to upload" solution to be
implemented first I presume.

Honestly I'd be happy if we could just establish some expectation that
the NMUer open a merge request for their changes.

I write this too often in the recent months (maybe because I did much
fewer NMUs before 2024 than I did in 2024 for t64 and so I didn't care
before), but: if a NMUer wants to modify a random repo, they need to:

1. Identify if the repo is uptodate.
2. Identify which workflow is used in the repo, and whether that workflow
is some typical one or some random undocumented one.
3. Study the workflow used, to know how to rebuild the package, and
ideally at this step rebuild the package without modifications to make
sure it works.
4. Study the workflow used some more, to know how to add modifications to
the package, add them, rebuild the package once again, make sure the
built package is correct.

This is literally impossible unless the workflow is typical and you
guessed it correctly, and is too much additional work even when it's
possible.

[Holger Levsen]

Post by Noah Meyerhans
Honestly I'd be happy if we could just establish some expectation that
the NMUer open a merge request for their changes. It can be merged
later without losing anything or requiring additional work. Enforcement
of this expectation would be even better, of course.

the current expectation is that an NMU bug is opened, which contains
the debdiff.

https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#when-and-how-to-do-an-nmu

"... Then, you must send a patch with the differences between the current
package and your proposed NMU to the BTS. The nmudiff script in the
devscripts package might be helpful...."
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

"Der Tod der menschlichen Empathie ist eines der frÃŒhesten und deutlichsten
Zeichen dafÌr, dass eine Kultur gerade in Barbarei verfÀllt." Hannah Arendt

[Noah Meyerhans]

Post by Holger Levsen

Post by Noah Meyerhans
Honestly I'd be happy if we could just establish some expectation that
the NMUer open a merge request for their changes. It can be merged
later without losing anything or requiring additional work. Enforcement
of this expectation would be even better, of course.

the current expectation is that an NMU bug is opened, which contains
the debdiff.
https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#when-and-how-to-do-an-nmu
"... Then, you must send a patch with the differences between the current
package and your proposed NMU to the BTS. The nmudiff script in the
devscripts package might be helpful...."

Right, and that's not a whole lot more helpful than requiring me to
download the sourcepackage and generate the debdiff myself. Sure all
the content is there, but it's still a tedious amount of work that's
easily forgotten. Further, it loses a little bit of metadata, in that
the git commit now comes from me, rather than the person doing the
actual NMU.

Yes, I know this is trivial, and yes I know I can fix it with more work;
I don't want NMUs to make more work for me. It makes me not like NMUs.

noah

[Andrey Rakhmatullin]

Post by Noah Meyerhans

Post by Holger Levsen

Post by Noah Meyerhans
Honestly I'd be happy if we could just establish some expectation that
the NMUer open a merge request for their changes. It can be merged
later without losing anything or requiring additional work. Enforcement
of this expectation would be even better, of course.

the current expectation is that an NMU bug is opened, which contains
the debdiff.
https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#when-and-how-to-do-an-nmu
"... Then, you must send a patch with the differences between the current
package and your proposed NMU to the BTS. The nmudiff script in the
devscripts package might be helpful...."

Right, and that's not a whole lot more helpful than requiring me to
download the sourcepackage and generate the debdiff myself. Sure all
the content is there, but it's still a tedious amount of work that's
easily forgotten. Further, it loses a little bit of metadata, in that
the git commit now comes from me, rather than the person doing the
actual NMU.
Yes, I know this is trivial, and yes I know I can fix it with more work;
I don't want NMUs to make more work for me. It makes me not like NMUs.

Sure.
We have two options here: make the project do fewer NMUs by doing more
maintainer uploads, or standardize and mandate a git workflow or two.
We don't like *doing* NMUs either.

[Otto Kekäläinen]

Thanks for all the comments!

Trying to summarize and expand on the points raised:

Seems this is still the most optimal way to ensure git is correct:

gbp import-dsc --verbose --pristine-tar apt:j4-dmenu-desktop/sid

Also, dgit pull can be used to get the latest source automatically, but
unfortunately those git commits are made as a custom "Debian as a git repo"
representation, and is not compatible with using CI testing and code review
before upload in the way many of us are doing on Salsa currently.

Seems also others are occasionally annoyed by NMUs. Ideally mass change
drivers would do mass bug filings and let maintainers upload instead of
resorting immediately to NMUs.

The post-upload NMU bug report and diff will help ensure the fact that a
NMU happened is discovered by maintainer, but reconciling packaging git
contents to 100% match what was uploaded is still best to be done with
command above.

Packages that are actively maintained should in general never need a NMU.
If packages are abandoned they should move to salsa.debian.org/debian
namespace, as it would solve the access permissions and allow for some
changes to be pushed to git.

The Debian Janitor could perhaps be used both to sync NMUs back to git
repos, and as a replacement for NMUs in some cases. Any repo that has Salsa
CI passing and/or a gbp.conf is pretty easy to do a MR on, but doing
mass-MRs is a complex topic that deserves a documentation of its own.

Also, wider standardization in packaging workflows, and use of
machine-readable gbp.conf and such is needed to make it easier to work via
git. However there is, and will likely be, an inherent long-term conflict
in the duality that uploads can happen irrespective of version control in
git and use Debian repositories themselves for version control.

Anyway, a mass-MR filing does not result automatically in an upload
happening for every package, so some NMUs are likely to occur. Thus,
knowing the easiest one-liner to reconcile git packaging repo is still the
most important thing for DDs.

[Sean Whitton]

Hello,

Post by Otto Kekäläinen
Thanks for all the comments!
gbp import-dsc --verbose --pristine-tar apt:j4-dmenu-desktop/sid
Also, dgit pull can be used to get the latest source automatically, but unfortunately those
git commits are made as a custom "Debian as a git repo" representation, and is not
compatible with using CI testing and code review before upload in the way many of us
are doing on Salsa currently.

'dgit pull' integrates the NMU automatically, when it can. It doesn't
just fetch the source. I don't follow how it's different from 'gbp
import-dsc'. Could you say more?

[Otto Kekäläinen]

Hi!

Post by Sean Whitton

Post by Otto Kekäläinen
gbp import-dsc --verbose --pristine-tar apt:j4-dmenu-desktop/sid
Also, dgit pull can be used to get the latest source automatically, but unfortunately those
git commits are made as a custom "Debian as a git repo" representation, and is not
compatible with using CI testing and code review before upload in the way many of us
are doing on Salsa currently.

'dgit pull' integrates the NMU automatically, when it can. It doesn't
just fetch the source. I don't follow how it's different from 'gbp
import-dsc'. Could you say more?

In a gbp checkout of ***@salsa.debian.org:debian/j4-dmenu-desktop.git,
how would you invoke 'dgit pull sid' to import the NMU?

Without any parameters, it will create branch 'dgit/sid' which has
unrelated history and patches are applied and nothing can be merged or
cherry-picked to the git-buildpackage master branch. Perhaps I am just
missing something on how this should work, or perhaps
https://manpages.debian.org/unstable/dgit/dgit-maint-gbp.7.en.html#INCORPORATING_NMUS
implies the functionality isn't yet there?

[Sean Whitton]

Hello,

Post by Otto Kekäläinen
Hi!

Post by Sean Whitton

Post by Otto Kekäläinen
gbp import-dsc --verbose --pristine-tar apt:j4-dmenu-desktop/sid
Also, dgit pull can be used to get the latest source automatically, but unfortunately those
git commits are made as a custom "Debian as a git repo" representation, and is not
compatible with using CI testing and code review before upload in the way many of us
are doing on Salsa currently.

'dgit pull' integrates the NMU automatically, when it can. It doesn't
just fetch the source. I don't follow how it's different from 'gbp
import-dsc'. Could you say more?

how would you invoke 'dgit pull sid' to import the NMU?
Without any parameters, it will create branch 'dgit/sid' which has
unrelated history and patches are applied and nothing can be merged or
cherry-picked to the git-buildpackage master branch. Perhaps I am just
missing something on how this should work, or perhaps
https://manpages.debian.org/unstable/dgit/dgit-maint-gbp.7.en.html#INCORPORATING_NMUS
implies the functionality isn't yet there?

This is one of the cases where it can't do it completely automatically,
but a manual merge may be possible.

[Sean Whitton]

Hello,

Post by Otto Kekäläinen
Hi!

Post by Sean Whitton

Post by Otto Kekäläinen
gbp import-dsc --verbose --pristine-tar apt:j4-dmenu-desktop/sid
Also, dgit pull can be used to get the latest source automatically, but unfortunately those
git commits are made as a custom "Debian as a git repo" representation, and is not
compatible with using CI testing and code review before upload in the way many of us
are doing on Salsa currently.

'dgit pull' integrates the NMU automatically, when it can. It doesn't
just fetch the source. I don't follow how it's different from 'gbp
import-dsc'. Could you say more?

how would you invoke 'dgit pull sid' to import the NMU?
Without any parameters, it will create branch 'dgit/sid' which has
unrelated history and patches are applied and nothing can be merged or
cherry-picked to the git-buildpackage master branch. Perhaps I am just
missing something on how this should work, or perhaps
https://manpages.debian.org/unstable/dgit/dgit-maint-gbp.7.en.html#INCORPORATING_NMUS
implies the functionality isn't yet there?

Ah, I was thinking that you had already been using 'dgit --gbp push' to
upload the package. In that case the histories would be related, just
with some additional commits on top, and a manual merge would be
possible.

[Otto Kekäläinen]

Hi,

Post by Sean Whitton
Hello,

Post by Otto Kekäläinen
Hi!

Post by Sean Whitton

Post by Otto Kekäläinen
gbp import-dsc --verbose --pristine-tar apt:j4-dmenu-desktop/sid
Also, dgit pull can be used to get the latest source automatically, but unfortunately those
git commits are made as a custom "Debian as a git repo" representation, and is not
compatible with using CI testing and code review before upload in the way many of us
are doing on Salsa currently.

'dgit pull' integrates the NMU automatically, when it can. It doesn't
just fetch the source. I don't follow how it's different from 'gbp
import-dsc'. Could you say more?

how would you invoke 'dgit pull sid' to import the NMU?
Without any parameters, it will create branch 'dgit/sid' which has
unrelated history and patches are applied and nothing can be merged or
cherry-picked to the git-buildpackage master branch. Perhaps I am just
missing something on how this should work, or perhaps
https://manpages.debian.org/unstable/dgit/dgit-maint-gbp.7.en.html#INCORPORATING_NMUS
implies the functionality isn't yet there?

Ah, I was thinking that you had already been using 'dgit --gbp push' to
upload the package. In that case the histories would be related, just
with some additional commits on top, and a manual merge would be
possible.

I can (and I did test already) do a merge with --allow-unrelated
histories, but dgit history always has patches applied as separate
commits that get rebased and thus there is no quilt/gbp pq -compatible
git history to merge from. If I later do a 'dgit --gbp push' to
upload, how do I push a development version to Salsa for review and CI
testing?

Based on docs and your previous replies it isn't possible, thus `gbp
import-dsc --verbose --pristine-tar apt:j4-dmenu-desktop/sid` still
seems to stand as the optimal way to import NMUs onto a Debian
packaging git repo?

The man pages of dgit are extensive and explains well how to interact
with the Debian repository as if it was a git repository, but I am
unable to find descriptions of how to use dgit in team maintained
packages with testing and reviews prior to uploads.

[Sean Whitton]

Hello,

Post by Otto Kekäläinen
I can (and I did test already) do a merge with --allow-unrelated
histories, but dgit history always has patches applied as separate
commits that get rebased and thus there is no quilt/gbp pq -compatible
git history to merge from. If I later do a 'dgit --gbp push' to
upload, how do I push a development version to Salsa for review and CI
testing?

If the NMU was done with dgit, then dgit only appends commits to apply
the patches. Thus if you look a few commits back in history, you'll
find something you can merge.

Post by Otto Kekäläinen
Based on docs and your previous replies it isn't possible, thus `gbp
import-dsc --verbose --pristine-tar apt:j4-dmenu-desktop/sid` still
seems to stand as the optimal way to import NMUs onto a Debian
packaging git repo?

If the upload was not done with dgit, then probably, yes.

Post by Otto Kekäläinen
The man pages of dgit are extensive and explains well how to interact
with the Debian repository as if it was a git repository, but I am
unable to find descriptions of how to use dgit in team maintained
packages with testing and reviews prior to uploads.

The idea is that dgit is only needed when dealing with source packages.
When collaborating with team members prior to upload, you don't really
need any source packages -- you just build straight out of git.

If you can identify a place in the docs where some reference to this
could be added that would have been helpful to you, a patch would be
very welcome.

[Holger Levsen]

Post by Holger Levsen
the current expectation is that an NMU bug is opened, which contains
the debdiff.
https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#when-and-how-to-do-an-nmu
"... Then, you must send a patch with the differences between the current
package and your proposed NMU to the BTS. The nmudiff script in the
devscripts package might be helpful...."

FWIW, I think this should stay the default when doing NMUs but I also think
it should be (spelled out that it's) equally fine to open a MR on salsa
*if* the specific package somehow specifies this is ok.

I also think that currently no package should be able to opt-out from
getting NMUdiffs via the BTS, because it's good to have one workflow which
works for *all* packages.
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

There is no such thing as trans rights or gay rights or lesbian rights. There
are human rights of people who are gay, human rights of people who are lesbian,
and human rights of people who are trans. (@victor_madrigal)

[Sean Whitton]

Hello,

Post by Holger Levsen

Post by Holger Levsen
the current expectation is that an NMU bug is opened, which contains
the debdiff.
https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html#when-and-how-to-do-an-nmu
"... Then, you must send a patch with the differences between the current
package and your proposed NMU to the BTS. The nmudiff script in the
devscripts package might be helpful...."

FWIW, I think this should stay the default when doing NMUs but I also think
it should be (spelled out that it's) equally fine to open a MR on salsa
*if* the specific package somehow specifies this is ok.
I also think that currently no package should be able to opt-out from
getting NMUdiffs via the BTS, because it's good to have one workflow which
works for *all* packages.

I think so to.

[Helmut Grohne]

Andrey has already said much of what I could add to the thread, but I
think I can slightly clarify the needs of NMUers.

Post by Andreas Henriksson
I would very much prefer if it was possible in Debian to not allow
the archive to get out of sync with packaging git repo (for example
when it lives under salsa.debian.org/debian which uploaders should have
access to already).

There are three quite fundamental pieces missing to achieve this.

There needs to be simple way to turn a git commit into a source package.
If the source of truth ever is to become git, the .dsc becomes an export
format and then this becomes a hard requirement. We can turn git commits
into source packages. The problem is that there is not one way to do
this, but about a hundred and you need to know which package uses which.
That does not scale.

There needs to be a simple way to figure out the commit that corresponds
to an upload. This problem has been approached in two ways. For one
thing, there is DEP14 recommending a particular tag layout, but I think
this is backwards. It assumes that the git repository is trusted, but in
reality git repositories allow for much wider access than Debian
uploads. What we really needs is a source package to know the commit id
it was generated from.

These operations need to round-trip. If you take a source package,
identify the git commit and export it to .dsc, it must be functionality
equivalent to what you started with. Timestamps may differ, but file
content or contained files very much not.

To me, these are hard requirements for using maintainer git
repositories for performing NMUs.

Now the dgit users among us will be grinning already as what I have
written here, very much reads like a specification of (parts of) dgit.
Once again, I question whether salsa as we use it now is the solution or
the problem. I note that it is practically possible to push your dgit
history to salsa and then NMUers can easily do meaningful MRs for their
uploads even when your maintainer git has changes that have not yet been
uploaded.

Helmut

[Sean Whitton]

Hello,

Post by Helmut Grohne
Andrey has already said much of what I could add to the thread, but I
think I can slightly clarify the needs of NMUers.

Post by Andreas Henriksson
I would very much prefer if it was possible in Debian to not allow
the archive to get out of sync with packaging git repo (for example
when it lives under salsa.debian.org/debian which uploaders should have
access to already).

There are three quite fundamental pieces missing to achieve this.
There needs to be simple way to turn a git commit into a source package.
If the source of truth ever is to become git, the .dsc becomes an export
format and then this becomes a hard requirement. We can turn git commits
into source packages. The problem is that there is not one way to do
this, but about a hundred and you need to know which package uses which.
That does not scale.
There needs to be a simple way to figure out the commit that corresponds
to an upload. This problem has been approached in two ways. For one
thing, there is DEP14 recommending a particular tag layout, but I think
this is backwards. It assumes that the git repository is trusted, but in
reality git repositories allow for much wider access than Debian
uploads. What we really needs is a source package to know the commit id
it was generated from.
These operations need to round-trip. If you take a source package,
identify the git commit and export it to .dsc, it must be functionality
equivalent to what you started with. Timestamps may differ, but file
content or contained files very much not.
To me, these are hard requirements for using maintainer git
repositories for performing NMUs.
Now the dgit users among us will be grinning already as what I have
written here, very much reads like a specification of (parts of) dgit.
Once again, I question whether salsa as we use it now is the solution or
the problem. I note that it is practically possible to push your dgit
history to salsa and then NMUers can easily do meaningful MRs for their
uploads even when your maintainer git has changes that have not yet been
uploaded.

Well, quite, this is dgit indeed.

[Andrey Rakhmatullin]

Post by Otto Kekäläinen
Hi,
I occasionally run into the situation that a package has been NMU'd or
otherwise updated directly into the Debian repositories,
bypassing/ignoring that a packaging git repository existed. I was
wondering what techniques other DDs use to
1) detect that the git packaging repository was bypassed/diverged?

What's the problem here? You can simply assume that a NMU wasn't committed
but if you really need to check you can look at the tags and/or
debian/changelog?

Post by Otto Kekäläinen
2) bring the git repository back in sync with minimal effort?
So far, I have settled on having the deb-src for Debian sid configured
on my laptop (even though it is not running sid) and then inside the
gbp import-dsc --verbose --pristine-tar apt:j4-dmenu-desktop/sid

If gbp import-dsc works then I don't think there is a better way.
I thought you are asking about repos that have changes committed into them
since the previous maintainer upload, but I don't think there is an
automated way to update those.

[Peter B]

Post by Otto Kekäläinen
Hi,
I occasionally run into the situation that a package has been NMU'd or
otherwise updated directly into the Debian repositories,
bypassing/ignoring that a packaging git repository existed. <snip>

Hi Otto,

Are any of these packages team maintained?
I understand there is an issue whereby although uploading DDs
have unrestricted access to the archive,
they cannot update Salsa team repos if they are not a team member.
Maybe this ought to be fixed?
I can understand restricting access for DMs, but does it make sense for DDs?


Regards,
Peter

[Jonas Smedegaard]

Quoting Peter B (2024-10-25 12:22:25)

Post by Peter B

Post by Otto Kekäläinen
Hi,
I occasionally run into the situation that a package has been NMU'd or
otherwise updated directly into the Debian repositories,
bypassing/ignoring that a packaging git repository existed. <snip>

Hi Otto,
Are any of these packages team maintained?
I understand there is an issue whereby although uploading DDs
have unrestricted access to the archive,
they cannot update Salsa team repos if they are not a team member.
Maybe this ought to be fixed?
I can understand restricting access for DMs, but does it make sense for DDs?

As I understand it, Salsa is not solely used for Debian development --
i.e. I seem to recall Salsa maintainers explicitly ecouraging the use
of Salsa also for personal/upstream use.

If my understanding is correct, then it sounds wrong for DDs to be
granted access to all Salsa projects.

- Jonas

[Peter B]

Post by Jonas Smedegaard
If my understanding is correct, then it sounds wrong for DDs to be
granted access to all Salsa projects.

Hi Jonas,

I was not thinking of all Salsa projects,
but those that represent official packages.

Cheers,
Peter

[weepingclown]

Hi,

Each team has their own policy in place. Some teams just want you to request access if you want to work on a team package (eg: go team), but for some teams the membership is granted only after confirming they've read and accepted the team policy (eg: python team), regardless of whether they are a DD or not. Of course, for DDs it is mostly just a formality compared to new people who are typically granted access after seeing some debian contribution record. But regardless, it wouldn't be great to bypass the team policies, IMHO.

Best,
Ananthu

Post by Peter B
I understand there is an issue whereby although uploading DDs
have unrestricted access to the archive,
they cannot update Salsa team repos if they are not a team member.
Maybe this ought to be fixed?
I can understand restricting access for DMs, but does it make sense for DDs?

[Andrey Rakhmatullin]

Post by Peter B

Post by Otto Kekäläinen
I occasionally run into the situation that a package has been NMU'd or
otherwise updated directly into the Debian repositories,
bypassing/ignoring that a packaging git repository existed. <snip>

Hi Otto,
Are any of these packages team maintained?
I understand there is an issue whereby although uploading DDs
have unrestricted access to the archive,
they cannot update Salsa team repos if they are not a team member.

NMUers don't update package repos because it's too much effort, not
(just) because of permissions.

[Sean Whitton]

Hello,

Post by Otto Kekäläinen
Hi,
I occasionally run into the situation that a package has been NMU'd or
otherwise updated directly into the Debian repositories,
bypassing/ignoring that a packaging git repository existed. I was
wondering what techniques other DDs use to
1) detect that the git packaging repository was bypassed/diverged?

If you do all your uploads using 'dgit push', it will always detect this.

Post by Otto Kekäläinen
2) bring the git repository back in sync with minimal effort?

If you are using a patches-applied workflow or you have no patches,
'dgit pull' will do this.

If you are using patches-unapplied, you might be able to 'dgit fetch'
and then manually merge.