Re: should all bug reports be filed against /source/ packages?

[Sune Vuorela]

On 2019-10-23, Ansgar  wrote:
> So I'm wondering if we should start just filing all bug reports against
> source packages?  Reportbug could probably be easily changed to use
> `Source: ...` instead of `Package: ...`; more places could follow later.

Have you ever maintained source packages where a source produced many
different binaries?

I'm not sure the libreoffice maintainer, nor bug reporters, would
appreciate this.

Back when all the kdepim packages (mail, nntp, rss, calendar, contacts,
...) were one source, I'm sure dealing with them would have been a
nightmare.

/Sune

rocm-team: in support of AMD's free CUDA counterpart and end NVIDIA monopoly

[Mo Zhou]

Hi fellow developers,

As mentioned in a couple of previous mails, e.g.
"... tensorflow ...", and "... anaconda ...".
The license of software stack on nvidia's hardware
accelerator is always a problem. In the past, I helped
Debian's nvidia-team update the nvidia-cuda-toolkit
several times, and packaged some software around it,
even if their proprietary licenses looked disgusting.

AMD finally started to do somthing to attempt ending
nvidia's CUDA monopoly, and created ROCm, a free
(freesoftware licensed) counterpart to CUDA.
  https://rocm.github.io/index.html
Nowadays ROCm has gained support from some major
applications such as tensorflow and pytorch, etc.

And they also created a portability layer so that
existing CUDA code can be compiled to use AMD GPUs:
https://github.com/ROCm-Developer-Tools/HIP

That means AMD is trying to end nvidia's proprietary
CUDA monopoly. As a free distribution developer I
personally and spiritually support AMD's effort on
this direction.

I created a Salsa team, which could be used to hold
the ROCm software stack packaging:
  https://salsa.debian.org/rocm-team
However I personally don't have any AMD hardware,
so currently I'm still quite conservative in actual
packaging work.

Welcome to join the Salsa ROCm team, in (spiritual)
support of AMD's free software effort.

Bug#943552: ITP: tracecompass -- trace viewer and analyzer

[Sudip Mukherjee]

Package: wnpp
Severity: wishlist
Owner: Sudip Mukherjee 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: tracecompass
  Version : 5.1.0
* URL : https://www.eclipse.org/tracecompass/
* License : Eclipse Public License
  Programming Lang: Java
  Description : trace viewer and analyzer

Eclipse Trace Compass is an open source application to solve performance
and reliability issues by reading and analyzing traces and logs of a
system. Its goal is to provide views, graphs, metrics, and more to help
extract useful information from traces, in a way that is more
user-friendly and informative than huge text dumps.

- tracecompass supports multiple trace formats including lttng and ftrace.
- I need to use it frequently for my dayjob.
- I will need a sponsor.

Bug#943556: ITP: roc-roct-thunk-interface -- Radeon Open Compute Thunk Interface

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: roc-roct-thunk-interface
  Version : 2.9.0
  Upstream Author : AMD
* URL :
https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface
* License : MIT/X11 and BSD-2
  Programming Lang: C
  Description : Radeon Open Compute Thunk Interface

Will be maintained under ROCm team.

Bug#943559: ITP: python3-sphinx-click -- A Sphinx plugin to automatically document click-based applications

[Drew Parsons]

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 

* Package name: python3-sphinx-click
  Version : 2.1.0
  Upstream Author : Stephen Finucane http://that.guru/
* URL : https://github.com/click-contrib/sphinx-click
* License : MIT
  Programming Lang: Python
  Description : A Sphinx plugin to automatically document click-based 
applications

sphinx-click is a Sphinx plugin that allows you to automatically
extract documentation from a click-based application and include it in
your docs.

Needed to build documentation for dask 2.6.0.

To be maintained under the Debian Python Modules Team alongside sphinx
and other sphinx extensions.

Re: should all bug reports be filed against /source/ packages?

[Guillem Jover]

Hi!

On Wed, 2019-10-23 at 08:32:11 +0200, Ansgar wrote:
> 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 exist; or when the same binary is built from
> different sources on different architectures;

I think this is a bogus practice that dak or ftp-masters should
outright reject on NEW processing. The second case might have been
valid in the past, but I don't think it is anymore since we have
versioned provides. I consider these to be bogus because I don't
think we can properly tell the infra which would be which w/o some
kind of manual intervention.

I've personally filed bugs on packages that have used this kind of
cross-naming when I've noticed them, and will keep doing that if
they are not banned from the root.

> or when binary and source versions don't match (version tracking really
> should use source versions).

debbugs at least has the apparent support for source and binary
versions at least at filing time, where you can do:

  Package: binary
  Version: version-binary

or

  Source: source
  Source-Version: version-source

if that does not really do what it's supposed to do, or other parts
get confused, I'd say this is a bug in debbugs that should ideally
be fixed.

> In addition there are issues when binary packages get
> renamed (e.g. when libfoo1 gets dropped in favor of libfoo2).

This is indeed a valid point, and it would be nice to get support to
handle this in an easier way. Say a debbugs command to mass reassign,
or some way to designate the new package as a successor of the old
one, so that the infra could do the reassignment itself, or similar.

> I believe bugs should always be assigned to source packages as source
> packages are really the unit we use to keep track of packages.

In some contexts that might be true, but for bug tracking and triaging
just using the source package implies a massive loss of relevant data
and grouping. :/

> So I'm wondering if we should start just filing all bug reports against
> source packages?  Reportbug could probably be easily changed to use
> `Source: ...` instead of `Package: ...`; more places could follow later.

I actually find it slightly annoying when getting bug reports relevant
only to a binary package filed against the source package, as that's
something else I need to fix.

Personally I only ever file against source packages, when the bug is
relevant to the actual source package, say f.ex. the packaging bits or
the upstream build system, something in the actual source, say some
licensing issues, etc.

So this proposal looks like an annoying regression to me.

Thanks,
Guillem

Re: should all bug reports be filed against /source/ packages?

[Bernd Zeimetz]

On 10/23/19 11:53 PM, Moritz Mühlenhoff wrote:
> Fully agreed. It's also hard for users to pinpoint the correct binary
> package and they tend to get stale with changes to binary names anyway
> (soname changes to libs etc.)

I think its easier for users to find the binary package name, as the
package is being installed and the user might even to remember that
they've installed the package. Or if there is a segfault in libfoo123, I
think the first idea would be to report a bug against libfoo123 and not
against foo-bar-fuzz, the source of libfoo.
So I think at the end reportbug just needs to do the right thing

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: [RFC] Proposal for new source format

[Theodore Y. Ts'o]

On Wed, Oct 23, 2019 at 11:40:06AM -0700, Russ Allbery wrote:
> Marvin Renich  writes:
> 
> > The source package has historically (prior to the widespread use of VCS)
> > also provided the basis for future development.  Since most development
> > these days is done using VCS, it's natural to try to adapt the source
> > package to contain the VCS.  I believe this is a mistake.  I think the
> > source package should remain a succinct encapsulation of the source
> > required to build a specific version of the binary packages.  It should
> > also identify the canonical VCS location where new development occurs
> > (and from which this snapshot was taken), but it does not need, and
> > should not have, the complete VCS history.
> 
> I think I'm coming around to this position.  I don't think it's the best
> or most elegant design in the abstract, but given where we're starting
> from and the various concerns involved, it does seem like the most
> practical design.

I think we will need to support the source tar.gz for the forseeable
future.  At very least, *deprecating* the tar.gz/tar.gz.asc format
should be independent of question we also support a format that
involves a URL to a git repoistory plus a signed git commit ID or a
signed git tag.

> That said, I don't like accepting the idea that we're always going to
> point to random different VCSs per package, which may be down,
> inaccessible, deleted by the maintainer, and so forth.  I don't want to
> force anyone to do anything, but I think there is immense value in the Git
> repositories created by dgit from archive uploads, and that value gets
> even stronger if those repositories are enhanced by including the
> maintainer and upstream history where available.

I believe that the hypothetical git source format which involves a git
URL must involve a git server under the Debian project's control.
That is, Debian must keep a permanent archive of the git repository,
regardless of whether or not it is the primary repository for the
purposes of making changes.  Certainly the dgit repositories would
qualify, but potentially other git hosting solutions might qualify.

I do think, though that we should allow the specification of
*multiple* git repositories, with some kind of type specifier so it
can be clear whether a particular repository is just a read-only clone
versus a read/write "master" repository, and whether a
repository+branch is the upstream repository, and/or used by the
debian maintainer's to maintain its packaging.

It probably would also be useful if the metadata had some standardized
way to indicate the preferred way to propose changes to either
upstream or the debian packaging maintainer --- whether it's e-mail to
a particular e-mail address, or a pull request, etc.

   - Ted

Re: [RFC] Proposal for new source format

[Russ Allbery]

"Theodore Y. Ts'o"  writes:

> I do think, though that we should allow the specification of *multiple*
> git repositories, with some kind of type specifier so it can be clear
> whether a particular repository is just a read-only clone versus a
> read/write "master" repository, and whether a repository+branch is the
> upstream repository, and/or used by the debian maintainer's to maintain
> its packaging.

Oh, sure, absolutely.  Like you, I maintain all of my packages in multiple
Git repositories (once I add Salsa, there will generally be four of them)
for each package.

> It probably would also be useful if the metadata had some standardized
> way to indicate the preferred way to propose changes to either upstream
> or the debian packaging maintainer --- whether it's e-mail to a
> particular e-mail address, or a pull request, etc.

Hm, that's an interesting thought.  I do generally include that sort of
information in the docuemntation of all packages for which I'm upstream,
but for Debian I've assumed the preferred way to propose changes is the
BTS.  Now that's potentially changing with Salsa.  I don't really mind
monitoring multiple input formats, but some people will.

-- 
Russ Allbery (r...@debian.org)  

Re: should all bug reports be filed against /source/ packages?

[Paul Wise]

On Wed, Oct 23, 2019 at 2:32 PM Ansgar wrote:

> It gets confused if a source & binary package with the same name, but
> otherwise unrelated exist; or when the same binary is built from
> different sources on different architectures; or when binary and source
> versions don't match (version tracking really should use source
> versions).  In addition there are issues when binary packages get
> renamed (e.g. when libfoo1 gets dropped in favor of libfoo2).

These seem like deficiencies in debbugs that should get solved by
adding fixes and features there and in reportbug.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise