here any code changes under consideration in response to this work?
--
Sean Whitton
signature.asc
Description: PGP signature
#737634 be reconsidered.
>
> No reply by the dpkg maintainer showed up. Do we need to revisit that?
Quick ping on the TC decision in #1007717: do you have any response to
the TC's advice? Thanks.
--
Sean Whitton
signature.asc
Description: PGP signature
n for the Debian archive is also implemented for dpkg
upstream. And it might be that the dpkg developers would be against the
TC override solely or mostly because of this fact. So possibly changing
that would resolve things peacefully.
I don't see how this conflates things, but would be grat
eality, that we can celebrate, that dpkg has an upstream
existence independent of Debian.
--
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
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
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
3, 4c and 5
Option X -- issue only items 1, 2, 3 and 5
Option N -- none of the above.
END BALLOT
--
Sean Whitton
signature.asc
Description: PGP signature
mirrors.
I don't understand -- why would it be irrelevant?
--
Sean Whitton
indeed their git repos on salsa. Not all of
them, but very many.
--
Sean Whitton
signature.asc
Description: PGP signature
ntion to extend the ballot as sent by Sean on
> June 7th.
>
> Thanks for bearing with me and bringing those arguments forward.
Cool, thanks for reviewing and confirming that.
--
Sean Whitton
igrating the remaining packages when there's no reason to stay with
> 1.0, using the NMU procedure if needed.
I agree that this would be a good outcome, as expressed by your option 4c.
--
Sean Whitton
signature.asc
Description: PGP signature
diff uploads?
My own appraisal of the situation is that we do not know enough yet to
be thinking about cutting back on features and workflows. But I
certainly agree that it would be better to have a better solution, like
Ian's sketch.
I think Ian has already suggested adding text to our resolution
recommending the development of such a source format. To be honest I
don't think it's really necessary as everyone agrees it would be better
to have it, but if you think it should be said explicitly then let's do
that.
--
Sean Whitton
s not inherent to all of the workflows we are discussing here,
just one of them. Indeed, this is one of the primary motivations for
one of the others.
--
Sean Whitton
Hello,
On Tue 10 May 2022 at 05:29pm -07, Sean Whitton wrote:
> At today's ctte meeting we considered whether we can start a vote on
> this, but two committee members were missing, and someone else at the
> meeting reported that they hadn't yet been able to spend enough time
current resolution text for a bug that's probably
been open too long already.
--
Sean Whitton
ould be a good ballot option to include, thank you.
--
Sean Whitton
a particular packaging team
> (with unified processes), onboarding people into Debian takes very long
> compared to other projects.
Right, hence why we want 'dgit clone' to be as useful as possible.
--
Sean Whitton
7;d say that as uniformity is not
good in itself, it would be good to have more concrete reasons for
wanting uniformity in this case documented in this bug (not necessarily
in the resolution text) before we add it to the ballot.
--
Sean Whitton
t choice for a particular source package,
including, but not limited to, git-first packaging workflows.
5. We decline to comment on the recent source package format MBF.
Option A -- issue items 1--5
Option B -- issue items 1, 2, 3 and 5, but not 4
Option N -- none of the above.
END
this doesn't help address the issue of new
contributors struggling to find .build when trying to figure out where
their build artifacts have gone -- it's not going to be any easier for
them to find the --builddirectory option.
As has been said, a non-hidden 'build' is easier
(non-dotdirs) being a symlink to
the latter (.build)?
--
Sean Whitton
signature.asc
Description: PGP signature
hidden directory is to reduce clutter and stomping over any
>
> Love the hidden directory.
Fair enough, but what do you think about the counterarguments that have
been raised? What's good about having it hidden?
Thanks.
--
Sean Whitton
signature.asc
Description: PGP signature
Hello,
On Tue 23 Jul 2019 at 10:14PM +01, Ian Jackson wrote:
> Sean Whitton writes ("Bug#932753: tag2upload should record git tag signer
> info in .dsc [and 1 more messages]"):
>> AIUI a fingerprint fails to uniquely identify a PGP key unless you also
>> include the
keysize ought to be included
alongside the fingerprint, if the above is right.
--
Sean Whitton
signature.asc
Description: PGP signature
ot;the default in our package build
toolchain" as I didn't really mean to distinguish between dpkg and
debhelper in making my point.
Thank you for pointing out the error.
--
Sean Whitton
signature.asc
Description: PGP signature
; mandatory,
> is it dpkg-dev and policy issue?
Requiring maintainers to put `Rules-Requires-Root: no` in every single
d/control file would be a debian-policy bug, yes.
Changing debhelper's default, if that remainder overrideable by the
maintainer, would not be.
(surely we are a very long way from r-r-r: no for every package?)
--
Sean Whitton
signature.asc
Description: PGP signature
is going to be different for each proposed
new field.
It's probably fine for discussions to start here and then we can
reassign the bugs when we figure out who the consumers are.
--
Sean Whitton
signature.asc
Description: PGP signature
recisely where I expect to be using `dgit build-source`
myself (though it wasn't me who came up with the feature).
`dgit sbuild`, test the binaries, `dch -r`, `dgit push-source` -- no
need to do a binary build to test the `dch -r`.
--
Sean Whitton
signature.asc
Description: PGP signature
Dear Guillem,
On Thu, May 25, 2017 at 03:03:51AM +0200, Guillem Jover wrote:
> [ Just a very quick reply, will go over the other mails during the week. ]
Have you had more time to think about this one? I'd like to make
progress on my patch series to dgit, if possible. Thanks.
--
Sean
are some comments regarding 100%
reproducible builds of source packages in #756978.
--
Sean Whitton
signature.asc
Description: PGP signature
er a .changes is source-only.
Alternatively we could have dgit not accept -C with push-source. This
would be to think of push-source as a command to /do/ a source-only
upload, rather than a variant on `dgit push` that /ensures/ a
source-only upload. This is probably fine.
--
Sean Whitton
signature.asc
Description: PGP signature
g. In any case the
> other day I just added a FAQ entry, given that this seems a recurring
> question. :)
>
>
> <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_are_.buildinfo_files_always_generated_with_dpkg-buildpackage.3F>
Thank you for confirming this, and for the FAQ link.
--
Sean Whitton
signature.asc
Description: PGP signature
!
(please keep me CCed; I am not subscribed to this list)
--
Sean Whitton
signature.asc
Description: PGP signature
s, or
> with single-debian-patch (where I think the patch is autoregenerated
> as needed); or if the build is being done by a non-maintainer user
> from the dgit history view; or the maintainer is willing to invoke
> dgit to obtain the dgit history view and build from that.
Quick note t
en dh-make-elpa, and it
didn't occur me to look for the functionality in libdpkg-perl.
dh-elpa uses libdebian-source-perl only to see whether the Build-Depends
field contains a certain binary package.
HTH!
--
Sean Whitton
36 matches
Mail list logo
