de. We have benefitted repeatedly from his careful
analysis.
--
Sean Whitton
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
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
nt
for these sorts of choices.
--
Sean Whitton
le importing into salsa as you also
suggest.
--
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
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
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
-dpm, though it is a bit
fiddly to dig it out.
--
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
(by the way, after reading the package description, I lowered the
priority of isc-dhcp-common too)
--
Sean Whitton
signature.asc
Description: PGP signature
ar if you want to provide long-term support
> for your project. Talk to the LTS team in case you need help. Nobody is
> forced to do anything.
This is a good idea, but ISTM the assumption should be that the
subproject does not participate unless it explicitly says that it does.
--
Sean Whitton
signature.asc
Description: PGP signature
x27;may' (see Policy 1.1). I assume you mean the RFC2119 meaning of
'shall', which is equivalent to 'must'?
--
Sean Whitton
signature.asc
Description: PGP signature
t;
> So, as mentioned on:
>
> https://reproducible-builds.org/blog/posts/185/
>
> … Simon McVittie has actually patched our testing framework to vary
> this and this is now live.
>
> https://bugs.debian.org/901473#33
>
> (There is some further discussion on this bug.)
Nice. Props to you all.
--
Sean Whitton
or it.
What harm are the packages doing sitting in unstable? Distributing them
does not have much point, but neither does removing them.
If someone does want to come along and fix the package, having it pass
through NEW again is not a good use of ftpteam time.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Thu 22 Nov 2018 at 11:20AM GMT, Holger Levsen wrote:
> On Wed, Nov 21, 2018 at 08:37:28PM -0700, Sean Whitton wrote:
>> What harm are the packages doing sitting in unstable? Distributing them
>> does not have much point, but neither does removing them.
>
>
version) if the maintainer doesn't want to fix the reject
> right away.
Cool idea!
--
Sean Whitton
signature.asc
Description: PGP signature
saying that we should minimise the number
of times packages go through new as having ftpteam members check every
file in the package more than once is not a good use of their time --
however many members of that team there may be.
--
Sean Whitton
sed-updates repository
- Additional work for the release team as the testing-proposed-updates
mechanism is more work to approve changes, AIUI.
--
Sean Whitton
signature.asc
Description: PGP signature
t, and in this case
> it leads to the same conclusion.
Indeed, although it should be noted that Policy does require -devel
consultation even for a bump (as IOhannes is clearly aware).
--
Sean Whitton
signature.asc
Description: PGP signature
-8, flang-42
>
> field or so?
>
> As another example Python has `Python-Version: 3.6, 3.7` (for packages
> where this matters; don't ask me about details, I don't know much).
Indeed. Now that Built-Using has been tightened, this is how this sort
of thing should be handled.
--
Sean Whitton
signature.asc
Description: PGP signature
n use an alternative
> implementation.
>
> Adam/other elogind maintainers, please clarify/improve wording if this was
> somehow inaccurate.
There seems to be a consensus (and this is not really controversial), to
please file a bug against Policy with a patch to the virtual package
list
would just depend on it and the generated jquery/
> directory be replaced with a symlink to the known place?
Forgive my ignorance of the specifics of this package, but why can't you
add symlinks to the files shipped by libjs-jquery? That is the standard
solution.
--
Sean Whitton
signature.asc
Description: PGP signature
y to refer only to new packages with system users.
Ideally the adduser change would happen before we wrote this down in
Policy, but since the adduser behaviour is easy to workaround (IIRC), it
would not be required for it to happen first.
--
Sean Whitton
signature.asc
Description: PGP signature
For the purposes of this e-mail, let's assume that we have a good grasp
on what a "reasonable standard development workstation install" means.
Thanks.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Fri 15 Feb 2019 at 08:59PM -0700, Sean Whitton wrote:
> Use of the Build-Conflicts field is currently mostly optional, but Ian
> Jackson and I have been working on text for Debian Policy that would
> require its use in certain cases. See #824495 for the discussion.
>
>
you at least share a copy in this thread,
please, Guillem?
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Sat 16 Mar 2019 at 07:07PM +0100, Mattia Rizzolo wrote:
> On Sat, Mar 16, 2019 at 05:00:30PM +, Adam D. Barratt wrote:
>> On Sat, 2019-03-16 at 08:16 -0700, Sean Whitton wrote:
>> > Hello,
>> >
>> > On Sat 16 Mar 2019 at 10:17AM +08, Paul Wi
remain available as the git remote tracking
branches for your upstream remote, e.g. remotes/upstream/master.
The reason for not *additionally* maintaining upstream branches is
simply that then you don't have to keep track of whether they are
up-to-date.
--
Sean Whitton
signature.asc
Description: PGP signature
dgit-maint-gbp and either -merge or -debrebase is
tricky because you are going from patches-unapplied to patches-applied.
What I think you would want to do is use convert-from-gbp, and then if
you wanted -merge, just don't invoke `git debrebase` anymore. But I am
not sure.
Do you thin
to be turned
into a .deb once you've fixed your problem. You want the history of the
whole thing. Thus, a git history that contains both the upstream git
history and the Debian maintainer's changes to the packaging scripts is
going to be very useful. A git history of only the Debian p
Package: dgit
Version: 8.4
Severity: wishlist
X-debbugs-cc: Ian Jackson ,
debian-devel@lists.debian.org, Ian Campbell
There should be a manpage on converting between workflows.
On Mon 29 Apr 2019 at 01:50PM -07, Sean Whitton wrote:
> dgit-maint-merge -> dgit-maint-debrebase would ind
rred form for modification.
Perhaps I'm missing something, but zigo said he was pushing upstream's
tags to his repo. Doesn't that cover this?
--
Sean Whitton
signature.asc
Description: PGP signature
or this case.
If there is, it would be a bug in one of the workflow manpages.
You would pick your preferred dgit-maint-*(7) workflow and follow it.
--
Sean Whitton
signature.asc
Description: PGP signature
s, one can avoid some of the problems by pushing a non-fast-forward,
> non-interchange branch. But that differs from the regular workflow
> and, again, requires more advanced Git knowledge.
This, and other things in your mail to which I'm replying, are
legitimate criticisms of git-debrebase, but not of dgit.
--
Sean Whitton
signature.asc
Description: PGP signature
their uploads. If getting all DDs typing `dgit
push-source` to upload is going to be how we make source packages
obsolete, that's significant.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello all,
In a recent thread there were several requests for a dgit FAQ.
This now exists: https://wiki.debian.org/DgitFAQ
--
Sean Whitton
signature.asc
Description: PGP signature
ity-support (>= 2019.04.25)" to base-files in buster.
I didn't think we supported upgrades from anything but the latest point
release of the previous stable release?
My belief is based on the release notes saying that you should upgrade
to the latest point relesae first.
--
Sean Whitton
signature.asc
Description: PGP signature
ase notes saying that you should upgrade
to the latest point relesae first.
--
Sean Whitton
signature.asc
Description: PGP signature
e new dh_haskell would need a lot of testing etc.
So Haskell libraries and apps would probably have to be one of the
exceptions.
--
Sean Whitton
signature.asc
Description: PGP signature
l, if a policy requirement or convention should apply to new
packages, then it should apply to existing packages, too. But
specifically where applying the requirement to an existing package is
hugely more work than applying it to a new package, perhaps the
requirement ought to be limited to n
supported by
> Git-BuildPackage) is currently not supported by DGit.
>
> Is the DGit FAQ wrong on that point?
Thanks, fixed.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Tue 14 May 2019 at 12:30PM +01, Ian Jackson wrote:
> Sean Whitton writes ("Re: Do we want to Require or Recommend DH"):
>> I agree with Scott's emphasis on the distinction between new and
>> existing packages. Perhaps application of the distinction could
about it anyway. So this post is less about pointing in a
specific direction as giving a different angle to think about
things.
http://joeyh.name/blog/entry/80_percent/
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Wed 22 May 2019 at 04:57PM +02, Marc Haber wrote:
> On Mon, 13 May 2019 18:35:02 -0700, Sean Whitton
> wrote:
>>Hello all,
>>
>>In a recent thread there were several requests for a dgit FAQ.
>>
>>This now exists: https://wiki.debian.org/DgitFAQ
>
tries hard to
Note that nothing in dev-ref is binding on developers, so I think it's a
bit misleading to use the term 'policy'. All of dev-ref is guidelines.
Otherwise, I think your summary of what dev-ref says about NMUs is
correct.
--
Sean Whitton
signature.asc
Description: PGP signature
interchange format: the source packages that actually get uploaded. Or,
in other words, we want merge requests against the dgit view of
packages. Presumably package maintainers to massage such a thing into a
merge request against the maintainer view ... ?
--
Sean Whitton
signature.asc
Description: PGP signature
thing.
The commercial SSL thing is indeed a problem (#790093).
For the history thing, after you `dgit clone`, `git fetch vcs-git` will
get you the maintainer's history for browsing. That's about as easy as
debcheckout.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Wed 19 Jun 2019 at 11:51pm +0200, Wouter Verhelst wrote:
> On Mon, Jun 17, 2019 at 11:47:38AM +0100, Sean Whitton wrote:
>> We could try to write a tool which tries to guess and convert (e.g.) the
>> dgit view with your changes into a maintainer workflow, but the
[adding some lists to the CC; please CC me on replies]
On Tue 25 Jun 2019 at 03:54pm +0100, Sean Whitton wrote:
> This is to announce that Ian Jackson and I are planning a sprint on git
> for Debian packaging, dgit and related topics. We'll have planning
> discussions about what
t wanted to note this in case you
hadn't come across it)
--
Sean Whitton
signature.asc
Description: PGP signature
've just been lucky in not having to use quilt, or similar, yet.
"Never having a Debian delta" would seem to be a property of packages,
not workflows.
--
Sean Whitton
signature.asc
Description: PGP signature
n regardless of whether or not they are in a position to
push the patch upstream. And they'll have to use quilt to do that.
--
Sean Whitton
signature.asc
Description: PGP signature
writeable
by all DDs on salsa, so we wouldn't be giving up too much by moving off
the wiki.
Then we'd use GitLab pages or similar to publish it.
On Sun 30 Jun 2019 at 10:44PM +02, Enrico Zini wrote:
> I'd say that seeding the wiki with pages for each branch formats coul
ails!
(Filling out these pages can be done independently of trying to decouple
the taxonomy work from the design work, also indentified by Enrico.)
[1] https://wiki.debian.org/GitPackagingSurvey
--
Sean Whitton
signature.asc
Description: PGP signature
a second pair of eyes look at your SONAME bump etc.
[1] https://ftp-master.debian.org/REJECT-FAQ.html right at the top
--
Sean Whitton
signature.asc
Description: PGP signature
heduling binNMUs
that costly (in terms of buildd and human time) mistakes would be
likely.
Unless the interface only let you do very simple binNMU requests of
single packages, in which case it might not be worth implementing.
--
Sean Whitton
signature.asc
Description: PGP signature
ory.
Okay, thanks for this, I think I understand better now.
Do you expect some other Debian contributor doing an NMU to clone a copy
of upstream's repo and follow a similar workflow, if they want to change
the upstream source? Or what?
--
Sean Whitton
signature.asc
Description: PGP signature
t;adds a
> new binary package to the archive" in order to be effective.
The FTP team can't check every single upload, so I guess that at some
point someone decided that checking every binary-NEW upload was a
sensible compromise.
More sophisticated filtering on what gets checked would probab
people who
live at Ian Jackson's place (including Ian) for hosting.
[1] https://manpages.debian.org/git-debpush
[2] https://wiki.debian.org/GitPackagingSurvey
[3]
https://debconf19.debconf.org/talks/68-one-git-to-package-them-all-and-on-the-salsa-find-them/
--
Sean Whitton
signat
input is the git tags before their signature has been
verified against the Debian keyring. Maybe we could isolate fetching
and checking those tags from the part of the service which fetches the
whole git tree to produce a source package.
--
Sean Whitton
signature.asc
Description: PGP signature
on this. While things may
well change in the future (either the project's opinion on init or the
way Policy works), Policy is not the way to do this for the time being.
--
Sean Whitton
signature.asc
Description: PGP signature
ful to us is for it to be just a little
bit more pushy than Policy, as indeed it is.
--
Sean Whitton
signature.asc
Description: PGP signature
n early stage. From my perspective, the hardest problem to solve was
conversion of git trees to uploads, on the server side, in a way that is
user friendly. We take ourselves to have solved that problem, which to
my mind renders this project beyond the early stages of development.
--
Sean Whitton
si
t able to make a judgement about what would
be useful, however.
--
Sean Whitton
signature.asc
Description: PGP signature
ocally, by the uploader.
Just like how they would PGP-sign, locally, the .dsc and .changes.
--
Sean Whitton
signature.asc
Description: PGP signature
tpmaster would normally do.
Right. dgit-infrastructure already has code to do that. We just
haven't hooked it up yet.
--
Sean Whitton
signature.asc
Description: PGP signature
t I
wanted to mention this point about obsoleting source packages for the
benefit of others in the thread.
We can expect git to move off SHA-1 eventually, and it is not at all
clear the threat from preimage attacks is sufficient for it to be wise
for us to hold ourselves back here.
--
Sean Whitton
signature.asc
Description: PGP signature
think it is. (That said, designing
> the system for hash agility if possible is certainly recommended.)
Thanks for this.
tag2upload is equally as hash-agile as git.
--
Sean Whitton
signature.asc
Description: PGP signature
s
maintaining those packages could be made easier by implementing
something like your proposal.
In the meantime, let's deploy the tag2upload service, which has already
been coded up, and enable git pushes to upload for the vast majority of
packages.
--
Sean Whitton
signature.asc
Description: PGP signature
d nothing else.
If I'm doing a source-only upload then binaries are not relevant, so
there's no need to involve a tool as complex as sbuild.
Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or
(easier) `dgit push-source`.
--
Sean Whitton
ssible, generating both binary and
> source .changes. Both in a clean chroot. Then I can try out my .debs
> and on success just sign and dput. Works fine for me with pbuilder.
ICBW but I am pretty sure that sbuild builds the source package
*outside* of the clean chroot.
--
Sean Whitton
signature.asc
Description: PGP signature
t this point would be that sbuild is
not intended to be a replacement for all of dpkg-buildpackage.
--
Sean Whitton
signature.asc
Description: PGP signature
Package: wnpp
Severity: wishlist
Owner: Sean Whitton
* Package name: cutest
Version : 1.5
Upstream Author : Asim Jalis
* URL : http://cutest.sourceforce.net/
* License : zlib-like
Programming Lang: C
Description : C unit testing framework
Let'
less).
I think Russ' point is that this regression is a reasonable one, given
the benefits against which it is to be traded off.
--
Sean Whitton
signature.asc
Description: PGP signature
s the same package/version as
> expected.
Thanks for this.
--
Sean Whitton
signature.asc
Description: PGP signature
switches away from SHA-1, which perhaps it is reasonable to expect
eventually.
It would be good to hear responses to Rebecca's suggestion from those
who disagree that it is okay to rely on SHA-1 in the particular way that
git-debpush/tag2upload does.
--
Sean Whitton
Hello,
On Sun 28 Jul 2019 at 09:55PM +01, Rebecca N. Palmer wrote:
> On 28/07/2019 20:01, Sean Whitton wrote:
>> When I read your first e-mail what I thought you had in mind was just
>> this -- having git-debpush compute a stronger hash of the tree object
>> and add tha
there are errors, it is quite a bit harder to understand what's going on
than it is with git-debpush/tag2upload, basically because there are
.dscs involved.
(I don't think we'd want to make git-debpush a wrapper for that because
it is not a pure git command, so shouldn't be in t
ds will
achieve that.
> On 31/07/2019 20:21, Sean Whitton wrote:
>
>> Just fyi, it is indeed as simple as [dgit push-source && git push --all
>> --follow-tags]. However, when
>> there are errors, it is quite a bit harder to understand what's going on
>>
r ftp-master or dgit-repos.
Also, it should be noted that the tag cannot be deleted from dgit-repos
(except by a service administrator). So we don't have to rely on salsa
either.
Given the above, I believe your requirement is satisfied by tag2upload,
with only the addition of the new Git-Tag-Info field. Perhaps you could
confirm my reasoning here.
--
Sean Whitton
; other reasons that seem obvious enough not to require enumeration.
Hmm, okay. I think of dgit-repos as external to ftp-master only by
accident -- it's more like ftp-master than it is like salsa. But
there's no doubting that dgit-repos is not ftp-master at the present
time.
--
Sean
Hello,
On Thu 01 Aug 2019 at 02:35PM +02, Guillem Jover wrote:
> On Thu, 2019-08-01 at 04:37:41 -0700, Sean Whitton wrote:
>> On Wed 31 Jul 2019 at 10:53PM +01, Rebecca N. Palmer wrote:
>> > Do "complicated and inconvenient" mean "harder to remember than 'g
ect in the least; just wondering about the value.)
--
Sean Whitton
signature.asc
Description: PGP signature
ranch prefixed with 'wip' might be rebased
myself, but others might be surprised.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Sat 14 Sep 2019 at 01:07PM +02, Marc Haber wrote:
> On Fri, 13 Sep 2019 13:05:20 -0700, Sean Whitton
> wrote:
>>On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote:
>>> How about documenting that branches prefixed with "wip" can be force
>>>
ut real stable
releases, however good your workflows are, packaging GitLab and
administering GitLab installations demands more of people's time than it
would if there were real stable releases.
Real stable releases are freedom-enhancing when they free up people's
time to work on other
e code. Indeed, Emacs exports all these as CHANGELOG files in
its release tarballs.
--
Sean Whitton
s and
our users. And it's within one of the areas of Debian that we're most
proud of -- completely smooth upgrades between stable releases.
So, I think we should assume the people who are more worried are right,
for the time being. We lose little in doing so.
--
Sean Whitton
signature.asc
Description: PGP signature
at's the reason the RT advice was
> worded as it was.
It's designed to stop as-yet-unknown problems happening, too.
--
Sean Whitton
signature.asc
Description: PGP signature
licy documents and best practices contain various provisions with
user's own packages in mind.
--
Sean Whitton
signature.asc
Description: PGP signature
to achieve something more general than that, however.
It is completely reasonable, as you wrote in another message, to want
this transition to be held to the same standards as others.
--
Sean Whitton
signature.asc
Description: PGP signature
would require a new, maintainer-overruling vote.
Our existing decisions do not apply, so far as I can tell.
I have written a separate message to the bug and to debian-dpkg with a
proposal to avoid having to have such a vote.
--
Sean Whitton
signature.asc
Description: PGP signature
ut people are not doing that on Debian lists, so
the quoted text from your message seems entirely off-topic.
--
Sean Whitton
signature.asc
Description: PGP signature
author's names for rhetorical effect, or asking rhetorical questions,
and it would keep the temperature of the discussion lower.
--
Sean Whitton
signature.asc
Description: PGP signature
arcasm is constructive in this sort of contentious
discussion.
--
Sean Whitton
signature.asc
Description: PGP signature
copyright.
I would be in favour of the 25 lines criterion. The main problem with
manipulating d/copyright is only the really long licenses, IME.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello Kunal,
Thank you for your message.
Unfortunately, only existing DDs can nominate themselves for this.
--
Sean Whitton
signature.asc
Description: PGP signature
p the two separate.
Not everyone agrees with this. I think that same repo, non-native
versioning is often what's best for a package.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Fri 29 Mar 2024 at 01:44am GMT, Colin Watson wrote:
> On Fri, Mar 29, 2024 at 09:28:44AM +0800, Sean Whitton wrote:
>> On Thu 14 Mar 2024 at 01:29pm GMT, Jonathan Dowland wrote:
>> > I took a peek, out of curiosity. I was surprised not to find a
>> > orig.ta
1 - 100 of 665 matches
Mail list logo
