Hello,
On Thu 29 May 2025 at 11:31am +02, Marc Haber wrote:
> On Thu, May 29, 2025 at 10:27:09AM +0100, Sean Whitton wrote:
>>On Wed 28 May 2025 at 10:04pm +02, Marc Haber wrote:
>>> My personal pet peeve is the difference between the source package and the
>>> packag
bably want to use git-debrebase or git-dpm or
single-debian-patch in addition to dgit.
--
Sean Whitton
signature.asc
Description: PGP signature
files are committed to git) in use in the
archive by high profile packages. For example, Emacs.
--
Sean Whitton
signature.asc
Description: PGP signature
dying anyway, it doesn't play well
> with systemd, and it doesn't play at all with systemd units that use
> security.
It's very useful to a workstation user and that is unlikely to change.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Mon 26 May 2025 at 01:13pm +02, Julien Plissonneau Duquène wrote:
> Hi,
>
> Le 2025-05-21 14:45, Sean Whitton a écrit :
>> It's meant to be kept up-to-date. If it's a dead link, it should be
>> deleted.
>
> The way it is currently specified in thi
that are relevant for evaluating current licensing compliance.
It's meant to be kept up-to-date. If it's a dead link, it should be deleted.
--
Sean Whitton
signature.asc
Description: PGP signature
x27;t count d/control Vcs-* though?)
>
> Has there been any work towards a single-file declarative file syntax to
> generate all the debian/ files?
>
> Except for debian/patches/ and debian/tests/ I think this could work.
> Compare rpm's *.spec or Homebrew files.
Woul
t; debian package, It is not viable.
There is the Source field in d/copyright where you can put a git remote
URL. Maybe that usage should go into DEP-14 ?
--
Sean Whitton
signature.asc
Description: PGP signature
it
> gives more power to optimize stuff).
>
> Maybe DEP-14 should focus on being the debhelper of git-based packaging,
DEP-14 and gbp are not the same, though. There's no need to conflate
them. I think Holger's point is that he wants to adopt all or most of
DEP-14, but not gbp.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Mon 12 May 2025 at 01:27pm +02, Bálint Réczey wrote:
> Hi,
>
> Sean Whitton ezt írta (időpont: 2025. máj.
> 12., H, 13:11):
>>
>> Hello,
>>
>> On Mon 12 May 2025 at 10:37am +02, PICCA Frederic-Emmanuel wrote:
>>
>> >> debian/
gt; Do we have a tool around DEP-14, which allows this ?
Well, git-debrebase does, and is as compliant with DEP-14 as you'd like
it to be.
--
Sean Whitton
signature.asc
Description: PGP signature
ure
they're portable yet.
Also, I have to admit, I found it a lot of fun trying to figure out how
to make these programd performant enough with only POSIX facilities.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Sat 19 Apr 2025 at 09:40am -04, Michael Stone wrote:
> On Sat, Apr 19, 2025 at 08:05:54PM +0800, Sean Whitton wrote:
>>I have interpreted scripts that I want to run on any FreeBSD and Debian
>>machine, because they are part of my OS bootstrapping. What else is
>&g
Hello,
On Fri 18 Apr 2025 at 08:18am -04, Michael Stone wrote:
> On Fri, Apr 18, 2025 at 02:52:17PM +0800, Sean Whitton wrote:
>>On Thu 17 Apr 2025 at 08:02pm -05, Richard Laager wrote:
>>> So, personally, I think getting mktemp(1) added to POSIX would be
>>> better
I think the implementation of this does not need to be "Essential: yes",
btw. Making it possible to be even smaller is fine too. I'm talking
about defaults -- and I think that includes default/official container
images.
--
Sean Whitton
signature.asc
Description: PGP signature
27;t follow POSIX strictly, unfortunately.
See these workarounds for both the potential lack of m4 and the lack of
GNU m4 behaving POSIXly:
https://sources.debian.org/src/consfigurator/1.2.3-1/src/connection.lisp/#L305
--
Sean Whitton
signature.asc
Description: PGP signature
we can tweak
them to exclude duplicates etc.. It can be done collaboratively so
that people's efforts can be pooled.
All in all, a great start to this effort.
--
Sean Whitton
signature.asc
Description: PGP signature
ble view? I might be able to provide some
feedback.
Thanks!
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Wed 19 Mar 2025 at 12:58am +01, Simon Josefsson wrote:
> Sean Whitton writes:
>
>>> Packages (for example): libntlm, cppi, git2cl, guile-fibers
>>
>> That should be enough! If you were able to do at least one upload using
>> 'dgit push-source&#
Hello,
On Wed 19 Mar 2025 at 12:25am +01, Simon Josefsson wrote:
> Sean Whitton writes:
>
>> That should be enough! If you were able to do at least one upload using
>> 'dgit push-source' for each package to confirm everything is okay, that
>> would be grea
sit in BD-Uninstallable status until the whole batch has
> been processed, with no real harm done?
Yes, I think that is fine.
--
Sean Whitton
sufficient to count me as a dgit user.
>
> Packages (for example): libntlm, cppi, git2cl, guile-fibers
That should be enough! If you were able to do at least one upload using
'dgit push-source' for each package to confirm everything is okay, that
would be great.
--
Sean Whitton
Hello,
On Sat 15 Mar 2025 at 01:03pm +01, Johannes Schauer Marin Rodrigues wrote:
> Hi Sean,
>
> Quoting Sean Whitton (2025-03-15 02:49:58)
>> - (At least some of) the packages are uploaded relatively often.
>
> with the upcoming freeze, I do not expect too many uploads to
commendation, and hereby appoint Paul as member of
> the Technical Committee, effective immediately. Simon McVittie's term
> ended at the end of 2024, thanks to Simon for his work on the Debian
> Technical Committee.
It was my term that ended, Simon's finished a while back.
-
Hello,
On Sun 09 Mar 2025 at 12:17pm +01, Simon Josefsson wrote:
> Sean Whitton writes:
>
>> The docs are public: https://salsa.debian.org/ftp-team/manpages
>
> Those are helpful even for me as uploading packages to NEW! I wish I
> had read them before.
Mmm. They sat pr
uestion
correctly.
So, a more general answer: we mostly care about individual packages and
rely on maintainers and britney to care about how they interact.
But if we see something which seems obviously like introducing breakage
we'll probably ask you about it, and if you tell us it's fine,
heir problems if any, then come
> back".
The docs are public: https://salsa.debian.org/ftp-team/manpages
> Finally, a question -- as you don't seem to document the issues you have with
> long term packages in their ITP bug, where *do* you document them?
There is a notes system i
d the ftp team.
I updated this section to try to capture what I learned.
- Policy 12.5 -- covers some of the othe REJECTs
- the REJECT-FAQ.
--
Sean Whitton
signature.asc
Description: PGP signature
#x27;s OK
> because..."), rather than somewhere to put a change history of previous
> negative feedback being addressed. The ftp team don't need to know about
> the existence of previous, wrong packages, they are only approving or
> rejecting the hopefully-correct final package that
Hello,
Thank you, Timo, for all the info. I think you're quite right about the
psychological impacts and the comparison with the level crossing is apt.
--
Sean Whitton
signature.asc
Description: PGP signature
full copyright
and license review even if it's just a SONAME bump. I do not think we
should be doing this, but it's the team policy.
[1] https://salsa.debian.org/ftp-team/manpages
--
Sean Whitton
signature.asc
Description: PGP signature
arify policy on this aspect.
I read it that way too.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Thu 27 Feb 2025 at 06:11pm +09, Charles Plessy wrote:
> Le Thu, Feb 27, 2025 at 03:02:08PM +0800, Sean Whitton a écrit :
>>
>> Packages that already install programs to /usr/games, where another
>> package installs a program of the same with different func
;t just throw people at a team of volunteers who are busy doing
other things and say "train them". Nobody wins, there, and the
candidates won't come back at a time when those volunteers *do* have the
time to do the training.
--
Sean Whitton
signature.asc
Description: PGP signature
evisit the idea along these lines:
If someone wants to set this up in a way that doesn't increase ftp team
workload but means packages have to be reject'd less often -- by all
means.
--
Sean Whitton
signature.asc
Description: PGP signature
he same name under "/usr". ... The
base-files package is an exception, for it installs aliasing
symbolic links from "/bin" to "/usr/bin", "/lib" to "/usr/lib", et
cetera.
--
Sean Whitton
signature.asc
Description: PGP signature
very clear to Andreas.
--
Sean Whitton
signature.asc
Description: PGP signature
o being
usable in as many situations as possible; they are not fundamentally
broken; they are not setting up some sort of parallel git ecosystem.
Not at all.
[1] https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/409
--
Sean Whitton
signature.asc
Description: PGP signature
do as they like with their code.
Yes, just as we may :)
--
Sean Whitton
signature.asc
Description: PGP signature
ly disagrees with you.
The preferred form for modification, which is what NEW cares about, is
determined by upstream's actual practices, not by their fiat.
We frequently reject packages from NEW because we have minified files;
we add the source to debian/missing-sources/.
--
Sean Whitton
upstream Git then users can clone source
packages from salsa (or, better, 'dgit clone' if the maintainer has used
'dgit push-source') and can use powerful tools like 'git blame' and 'git
bisect' to understand their bug.
With tarballs the granularity of these tools is so much less.
--
Sean Whitton
signature.asc
Description: PGP signature
beta testers
soon. Thanks to the formorer for the listmasters, Andreas our DPL, and
special thanks to Philipp Kern of DSA for figuring out the hosting with
us.
--
Sean Whitton
signature.asc
Description: PGP signature
f the DEP and mark the rest of it as ACCEPTED. I don't think
any other parts have disagreement.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
All delegates have to co-ordinate with each other. There’s no special need for
this delegation to make reference to others, as josch says.
--
Sean Whitton
Please excuse top-posting and brevity. I am writing to you from a mobile phone.
> On 15 Jan 2025, at 07:47, Andreas Tille wr
e, the whole Debian project
> should be held responsible. Either it gets fixed by someone or it gets RM'd by
> someone."
Hmm, what you describe seems more like an orphaned package.
--
Sean Whitton
signature.asc
Description: PGP signature
iners can touch. This stance helps nobody.
> ITS solely for QA work is in the same boat of wrong. Just NMU.
Yes, quite. Integers are cheap, and these are not uploads directly to
stable. We can always just upload again.
--
Sean Whitton
signature.asc
Description: PGP signature
mined by
looking at the git history, it would be appropriate to write to the
people in Uploaders and ask how they'd like it to be handled.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
Another thought I had was just to use the packages.d.o address.
E.g.
Maintainer: Debian developers
It would be invalid to use this in maintainers without any human
uploaders. Only q...@packages.debian.org is valid without human
uploaders.
--
Sean Whitton
Hello,
On Sat 21 Dec 2024 at 08:09am +01, Gioele Barabucci wrote:
> On 21/12/24 03:11, Sean Whitton wrote:
>>> an alternative that I was thinking of, is making this "everybody is onboard"
>>> policy more explicit by having a special email to use for the Ma
t; keeping things running has taken precedence.]
Wow! Thanks for working on this!
--
Sean Whitton
signature.asc
Description: PGP signature
e next step: agree on a "standard" Debian workflow and allow (encourage?)
> people to convert existing packages to it (assuming that the don't touch tag
> file is absent) ?
Let's discuss just one of these two highly controversial changes at
once.
--
Sean Whitton
signature.asc
Description: PGP signature
ercase 'd' deliberate)
We could replace the LowNMU wiki list with this, right now.
It's the same as "Debian QA team" but it signals active maintainance by
at least one of the named uploaders.
We could do this independently of any other ideas about
dont_touch_my_package.
>True, but people taking this stance do not stay in competition.
Really? It's already this bad, in some places?
You work in academia right? Maybe it's less bad in software shops.
--
Sean Whitton
signature.asc
Description: PGP signature
on. For Perl, given their strict
stance to backwards compatibility, we can just keep it.
--
Sean Whitton
signature.asc
Description: PGP signature
a structures are far more *discoverable*
> than Perl, which translates to much easier bug fixing. The same thing applies
> to typing. Did you try to statically-type-check a Perl program lately?
Yes, type checking is one advantage of Python over Perl.
--
Sean Whitton
signature.asc
Description: PGP signature
ore difficult to use them for.
The deeper philosophical differences aren't too relevant to maintaining
Debian stuff.
Even if people tend to have a strong preference for one over the other,
they can develop curiosity for learning a bit more about the other in
order to fix something
(happened to me recently in the direction Perl->Python).
--
Sean Whitton
cant work out what is being acknowledged
(gmail's threading support is famously simplistic)
--
Sean Whitton
signature.asc
Description: PGP signature
ost of those were requested >1 year ago.
They are usually still valid. I have one from last year and I would
still like help.
--
Sean Whitton
signature.asc
Description: PGP signature
that C library you might be able
to help upload, I meant that it would be on a continuing basis.
It doesn't seem good for Debian, or the sponsee, for the DD to sponsor
it through NEW and then leave the sponsee in limbo.
--
Sean Whitton
"needs at least 10 minutes to process a request". It seems to be a problem
> specific to the BTS.
The GNU instance of debbugs, which I interact with regularly, is like
lightning compared to ours, and it does help.
--
Sean Whitton
agree with the first sentence but I think the 2nd sentence is too much
> drama.
>
> Those many workflows exists for reasons, some good, some not so good.
Right. And there are many package-specific needs.
--
Sean Whitton
ls. Let us get the first version deployed first :)
--
Sean Whitton
Hello,
On Tue 03 Dec 2024 at 11:12am +01, Simon Josefsson wrote:
> Sean Whitton writes:
>
>> Hello,
>>
>> On Mon 02 Dec 2024 at 10:07pm -08, Otto Kekäläinen wrote:
>>
>>> As you know I have been testing dgit and reviewing tag2upload, and to
>>&g
would ask you not to do that.
In general: I am not willing to spend time retreading the grounds of the
disagreement now. I want to work on the programming work to enable this
new feature, instead. Please see the debian-vote archives at the time,
if you really want to know.
--
Sean Whitton
signature.asc
Description: PGP signature
he purpose of
feeding sbuild.
So, teams and individual maintainers that switch over to tag2upload
will be able to forget about a lot of this stuff.
--
Sean Whitton
;m not the only one.
Even for traditionally maintained software like Emacs, Rob and I push
upstream-signed git tags to dgit.debian.org instead, and use 'git
archive' to generate a tarball to satisfy dak.
--
Sean Whitton
signature.asc
Description: PGP signature
'git deborig'.
I appreciate not everyone is happy with this, but it solves the problem.
--
Sean Whitton
buttal. Maybe gbp should just refuse to generate a
> random tarball from a commit-ish and let^Wrequire people to provide one or
> provide a way to generate one in a correct way.
'origtargz' from devscripts usually does the right thing.
--
Sean Whitton
d, and
> those requirements and benefits still stand.
The very name of the tool is intended as an encouragement for us to move
away from tarballs. It's making fun of Debian's attachment to upstream
tarballs.
--
Sean Whitton
Hello,
On Sun 24 Nov 2024 at 07:53am +01, Johannes Schauer Marin Rodrigues wrote:
> Hi,
>
> Quoting Sean Whitton (2024-11-24 01:23:24)
>> This is interesting. One concern I have is speed -- isn't it always slower
>> to have to unpack a tarball before the build instea
tal and any
> feedback is very much appreciated.
>
> -- Johannes Schauer Marin Rodrigues
This is interesting. One concern I have is speed -- isn't it always
slower to have to unpack a tarball before the build instead of having a
chroot under /srv/chroot that's always unpacked?
Thanks.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello Kari,
Have you seen:
https://wiki.debian.org/GitPackagingSurvey
You may find something suitable for what you want there.
--
Sean Whitton
consistently spell it with a dash going forward. Anyone seconds?
I always thought it was with a hyphen, indeed.
--
Sean Whitton
e of our conduct documents even has this as one of its points: that we
should continually bear in mind the many demands on everyone's time.
--
Sean Whitton
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.
--
Sean Whitton
signature.asc
Description: PGP signature
ut from
> getting NMUdiffs via the BTS, because it's good to have one workflow which
> works for *all* packages.
I think so to.
--
Sean Whitton
signature.asc
Description: PGP signature
ould be added that would have been helpful to you, a patch would be
very welcome.
--
Sean Whitton
signature.asc
Description: PGP signature
uploads are still needed for passages in NEW (in that case: it's to
> target experimental for the first upload of the pair).
Also non-free packages that aren't marked as autobuildable.
--
Sean Whitton
sn'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.
--
Sean Whitton
plied 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
oad 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?
--
Sean Whitton
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.
--
Sean Whitton
d to automatically import all uploads back into dgit-repos.
So we will have a gitified source of truth, which is a step forward.
--
Sean Whitton
onflicts when upstream modifies
> the removed files. Is there a smart way to handle this?
There are some notes on a few ways to do this in dgit-maint-merge(7) and
dgit-maint-debrebase(7).
--
Sean Whitton
Hello,
I hadn't heard of these architecture-is-64-bit and not-supported-on
metapackages(?). Would someone who knows how they are meant to work
consider submitting a patch for Policy? Thanks.
--
Sean Whitton
signature.asc
Description: PGP signature
(by the way, after reading the package description, I lowered the
priority of isc-dhcp-common too)
--
Sean Whitton
signature.asc
Description: PGP signature
Hello Santiago,
What are your current intentions in this area? Do you want to make the
change for trixie? If not, I'd like to close the override change bug
for now. Thanks.
--
Sean Whitton
-dpm, though it is a bit
fiddly to dig it out.
--
Sean Whitton
signature.asc
Description: PGP signature
it could be a metadata field.
Just to note that once people are using tag2upload, this information
will start being recorded on salsa, as a side-effect. I've filed
#1078016 about exposing this information in a machine-readable way.
--
Sean Whitton
to note that once people are using tag2upload, this information
will start being recorded on salsa, as a side-effect. I've filed
#1078016 about exposing this information in a machine-readable way.
--
Sean Whitton
signature.asc
Description: PGP signature
include some explanations as to what sort of packages are
best suited to each of them.
--
Sean Whitton
signature.asc
Description: PGP signature
le importing into salsa as you also
suggest.
--
Sean Whitton
signature.asc
Description: PGP signature
nt
for these sorts of choices.
--
Sean Whitton
Yes, tag2upload. It’s almost ready :)
Please wait a little longer.
--
Sean Whitton
Please excuse top-posting and brevity. I am writing to you from a mobile phone.
> On 1 Aug 2024, at 20:43, Charles Plessy wrote:
>
> Le Thu, Aug 01, 2024 at 12:23:43PM +0100, Luca Boccass
yet I may have a stab at it.
>
> If anyone has any spare cycles I'd also like us think about how a
> full-blown git-filter-branch/-repo invocation would fit into the picture so
> perhaps the interface could handle those in the future.
I do a manual 'git rm', commit, an
de. We have benefitted repeatedly from his careful
analysis.
--
Sean Whitton
it yet.
Well, 'dgit clone' adds a vcs-git remote pointing at the maintainer's
history. So it sort of does this. We could make it do more.
--
Sean Whitton
signature.asc
Description: PGP signature
hen I am
> more willing to accept your stanze.
I have tried it out, and am happy for those maintainers that like it to
use it, but I do not want to maintain most of my packages that way.
I want people to send me patches to the BTS / project ML.
--
Sean Whitton
signature.asc
Description: PGP signature
aintain git-annex and git-repair outside of the monorepo.
--
Sean Whitton
signature.asc
Description: PGP signature
ire a new field.
That seems worth writing down.
Thank you Maytham for your work so far.
--
Sean Whitton
signature.asc
Description: PGP signature
1 - 100 of 665 matches
Mail list logo
