Hi,
the thread about naming (source) packages reminded me of an other thing:
Debian's bug tracking system currently (mostly) tracks bugs against
binary packages and (less often) against source packages.
It gets confused if a source & binary package with the same name, but
otherwise unrelated exis
Russell Stuart writes:
> On Tue, 2019-10-22 at 20:21 -0700, Russ Allbery wrote:
>> This history has at least one commit per upload, although ideally has
>> the package maintainer's full revision history and upstream's full
>> revision history.
> I understand you like the history. A lot of peopl
On Tue, 2019-10-22 at 20:21 -0700, Russ Allbery wrote:
> This history has at least one commit per upload, although ideally
> has the package maintainer's full revision history and upstream's
> full revision history.
I understand you like the history. A lot of people do. But not
everyone values
Hello,
On Tue 22 Oct 2019 at 10:54PM +00, Holger Levsen wrote:
> On Tue, Oct 22, 2019 at 08:05:28PM +0200, Jonas Smedegaard wrote:
>> Let us please all name new source package same as main binary package
>> (not same as upstream project).
> [...]
>> Therefore: Can we please use domain-specific na
Hello,
On Tue 22 Oct 2019 at 08:21PM -07, Russ Allbery wrote:
> In looking this over, none of this precludes the source format 4.0 that
> Bastian proposed, provided that there was some way to export that source
> format easily and simply from point 4. Maybe it doesn't matter what's
> published i
Hi!
On Tue, 2019-10-22 at 20:05:28 +0200, Jonas Smedegaard wrote:
> Let us please all name new source package same as main binary package
> (not same as upstream project).
I'm not sure, as is, this is a good general rule. I'd reword as, we
should always namespace source packages appropriately, r
Russell Stuart writes:
> Has it been done? Given this point has been raised several times before
> if it hasn't been done by now I think it's reasonable to assume it's
> difficult, and thinking that it's so is not excessively pessimistic.
Oh, it's news to me that anyone has raised this before.
I think we have about two weeks left in the review period.
Just as a reminder we do need comments.
Even if people generally agree, we do need at least a few comments to
that effect.
On Tue, 2019-10-22 at 16:52 -0700, Russ Allbery wrote:
> That seems excessively pessimistic. What about Git makes you think
> it's impossible to create a reproducible source package?
Has it been done? Given this point has been raised several times
before if it hasn't been done by now I think it'
Bastian Blank writes:
> On Mon, Oct 21, 2019 at 09:29:05PM -0700, Russ Allbery wrote:
>> If we're going to go to the trouble of defining a new source format,
>> I'd prefer we embrace a VCS-based one rather than once again rolling
>> our own idiosyncratic representation of a tree of files
> I'm n
On Tue, Oct 22, 2019 at 08:05:28PM +0200, Jonas Smedegaard wrote:
> Let us please all name new source package same as main binary package
> (not same as upstream project).
[...]
> Therefore: Can we please use domain-specific names for source packages,
> to leave names available in generic namespa
Hi Jan, Hi Andreas,
> both contains the same file, namely
> /usr/lib/lazarus/2.0.2/components/IdeInspector/ideinspector.lpk
> and removing it from one of them would fix the issue.
That is not a bug, but rather a feature that is solving previous bugs [1] and
[2]
The issue is that I copied some co
Hi Bastian,
thanks for this proposal,
On 10/22/19 5:22 AM, Bastian Blank wrote:
> During the tag2upload discussion, I think it got clear that it does not
> fit anywhere. And my standing is, that we can't implement such a
> service properly without some core changes to how our sources look like.
On Mon, Oct 21, 2019 at 11:06 PM Bastian Blank wrote:
> There is "gbp dch", which ignores merge commits (so no really good for
> merge requests), but I don't consider it to have enough control over the
> content of the changelog.
Just set your merge settings per project to fast-forward.
Thanks,
Hi all,
Let us please all name new source package same as main binary package
(not same as upstream project).
I am concerned about the practice of naming source packages after
upstream projects, seemingly common at least for Python packages.
Problem is needlessly leads to unintuitive package n
Hi Russ
On Mon, Oct 21, 2019 at 09:29:05PM -0700, Russ Allbery wrote:
> If we're going to go to the trouble of defining a new source format, I'd
> prefer we embrace a VCS-based one rather than once again rolling our own
> idiosyncratic representation of a tree of files
I'm not completely sure wha
On Tue, 22 Oct 2019 at 05:22:57 +0200, Bastian Blank wrote:
> - Files need to be compressed and are recorded as such, which is a hard
> problem and give rise to tools like pristine-tar and such.
My understanding is that this is deliberate: it means the only layer
with the hard requirement to be
On Tue, 22 Oct 2019 07:35:55 -0400, Sam Hartman wrote:
> Or some code that knows how to merge changelogs
dpkg-mergechangelogs(1) is a nice helper for some of the merge
situations.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP
I agree that better handling of things like debian/changelog is
something we should focus effort on.
I think we can either do something gbp dch like, possibly allowing
commits to annotate whether and to what extent they should be included
in changelog.
Or some code that knows how to merge chang
Hi.
My initial reaction is that this is additional complexity in a direction
that we don't need.
Like Russ, I generally assume that VCS-like things are the future.
I understand there is complexity there.
But I don't understand why this proposed format would be a step forward
in a world where we
Package: wnpp
Severity: wishlist
Owner: Alexandre Marie
* Package name: jupyter-sphinx
Version : 0.2.1
Upstream Author : Jupyter Development Team
* URL : https://github.com/jupyter/jupyter-sphinx
* License : BSD 3-Clause "New" or "Revised" License
Programmin
Package: wnpp
Severity: wishlist
Owner: Alexandre Marie
* Package name: wurlitzer
Version : 1.0.3
Upstream Author : Min RK
* URL : https://github.com/minrk/wurlitzer
* License : Expat
Programming Lang: Python
Description : Capture C-level output in con
On 10/22/19 6:29 AM, Russ Allbery wrote:
> Bastian Blank writes:
>
>> I would like to have some comments on a large revision on the source
>> format. It also needs modifications to dak to handle some parts of it.
>
>> - Source format version would be "4.0".
>> - Each source includes an arbit
23 matches
Mail list logo
