Re: Bug#942768: lcl-units-2.0: file conflict with lazarus-src-2.0 (versin 2.0.2+dfsg-5)

[Jan Volec]

Awesome, can confirm the 2.0.2+dfsg-6 version works for me again!


Best wishes,

Jan

> 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 code from the Debian policy manual [3] and 
> that
> code was wrong:
> The given example is missing closing bracket. I should noticed it before, but
> for some obscure reason it is passing on my computer:if [ upgrade != "$1 || 
> dpkg
> --compare-versions "$2" lt 1.0-2; then
> I've checked it again and I've fixed it. Will upload soon.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823706
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898310
> [3] https://www.debian.org/doc/debian-policy/ap-pkg-diversions.html-- 
> Cheers,
> Abou Al Montacir

Re: [RFC] Proposal for new source format

[Bastian Blank]

Hi Ansgar

Thanks for filling in the gaps I left in my explanation.

On Wed, Oct 23, 2019 at 10:15:16AM +0200, Ansgar wrote:
> kernel.org uses a similar scheme: there are signatures for the
> uncompressed tarballs by the maintainer (linux-*.tar.sign).  In addition
> there is a sha256sums.asc which has strong hashes of the compresssed
> files (linux-*.tar.{gz,xz}) and is signed by their archive management
> system.

That's what I was thinking about.  My expection was:

The source .dsc file contains checksums for uncompressed files.  Those
can be built easily in a reproducible way, just as you mentioned that
the output of "git archive" is already pretty stable over time.  Those
are also the values dak uses to find identical files.

The upload .changes file contains checksums of the actually uploaded
compressed files.

The archive Sources file will be filled with checksums for either only
the compressed files or both.

The only piece of software that would be susceptible to attacks on the
decompressor are tools to download .dsc and the listed source files
directly without going throw a Sources file.

Regards,
Bastian

-- 
Schshschshchsch.
-- The Gorn, "Arena", stardate 3046.2

Re: [RFC] Proposal for new source format

[Russ Allbery]

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.

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.  As much as possible, we
should try to centralize this information and these repositories on
project assets.  That doesn't mean the maintainer needs to *only* use
project hosting or even *primarily* use project hosting, but mirroring
this information into project hosting seems like a clear improvement for
everyone.

> One important aspect of this separation is that the VCS can include the
> original, unmodified upstream source, as long as it is redistributable
> in that fashion.  It has always bothered me that the modifications
> needed to convert the upstream source to a DFSG-compatible source are
> lost in the Debian source package.  Keeping the VCS separate allows it
> to contain the original, non-DFSG source and show what was done to make
> it DFSG and why.

Agreed, altough that "as long as it is redistributable" caveat is
important.  But you're right, this is a major advantage of separating the
Git repository from the source archive that I wasn't considering in my
message.

> I think the VCS-agnostic aspect of this has not been brought up in the
> related "Git Packaging" thread, but I think this is important.  While
> git is overwhelmingly the most popular VCS, it is not the only one (it's
> also not my preferred VCS for usability reasons).  I think it is
> short-sighted for Debian policy to mandate or even to strongly encourage
> a specific VCS.

I don't really agree with this.  The advantages of encouraging people to
standardize on a VCS are huge.  I'm not saying that we need to require
everyone use Git, but we should strongly encourage it, and a lot of things
in Debian will be much easier if you use Git (and should be).

That said, it may not matter that we don't agree here, since it sounds
like we're aligned on the high-level goal discussed in this thread and you
are arguing for adding an additional layer of abstraction over what I'd
add.  That's fine with me; I'm happy to make compromises like that if we
can get tag2upload support for Git.

> This effectively shuts down the use of any other VCS, and extremely
> hinders attempts to get a new or better VCS to be used for Debian
> development.

I don't believe this is the case because, practically, I believe
interoperability with Git is going to be a mandatory feature for any
future VCS that has any hope of achieving Git's level of support and
usage, regardless of anything Debian does or doesn't do.

> The tools for interacting with the archive, e.g. making it trivial to
> upload a signed commit to be built on official Debian hardware, should
> define a very small set of standard features necessary to accomplish
> that, such as clone, commit, checkout, push, pull, and tag (with
> signature).  This API should have a minimum of options, and it should be
> easy for someone to implement a shim from that API to a specific VCS.

This sounds like a fine (if more complicated) way to support tag2upload.

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

Re: [RFC] Proposal for new source format

[Marvin Renich]

I think this discussion has conflated two separate needs that should be
kept distinct.  The current source package provides a record of how the
binary packages were built from source.  This includes signatures and
verifiability of source, and, more recently, reproducibility.  It
provides the ability to build the binary packages on a user's own
machine, and can be a starting point for building them in an environment
not supported by Debian (in simple cases this might be exactly the same
as building on a current Debian architecture).

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 do believe that Debian should strongly encourage use of a publicly
accessible VCS for packaging, and should define some VCS-agnostic
standards that the repositories SHOULD (RFC implications) follow, e.g.
basic branch structures, tag naming conventions, etc.

Separating the source package from the VCS repository, but having both,
allows both Russ' and Russell's goals to be met easily.

One important aspect of this separation is that the VCS can include the
original, unmodified upstream source, as long as it is redistributable
in that fashion.  It has always bothered me that the modifications
needed to convert the upstream source to a DFSG-compatible source are
lost in the Debian source package.  Keeping the VCS separate allows it
to contain the original, non-DFSG source and show what was done to make
it DFSG and why.  It will also help to facilitate using a single
repository to build both a source package for main and a corresponding
source package for non-free, when that is appropriate.

[Perhaps the following should be moved to the Git Packaging thread, but
I think much of this sub-thread could also be said to belong there.]

I think the VCS-agnostic aspect of this has not been brought up in the
related "Git Packaging" thread, but I think this is important.  While
git is overwhelmingly the most popular VCS, it is not the only one (it's
also not my preferred VCS for usability reasons).  I think it is
short-sighted for Debian policy to mandate or even to strongly encourage
a specific VCS.  This effectively shuts down the use of any other VCS,
and extremely hinders attempts to get a new or better VCS to be used for
Debian development.

Debian should separate everyday development with the VCS from
interaction between the VCS and the Debian archive.  The tools provided
for the former can be very VCS-specific, and can make full use of that
VCS' features.

The tools for interacting with the archive, e.g. making it trivial to
upload a signed commit to be built on official Debian hardware, should
define a very small set of standard features necessary to accomplish
that, such as clone, commit, checkout, push, pull, and tag (with
signature).  This API should have a minimum of options, and it should be
easy for someone to implement a shim from that API to a specific VCS.

This separation would allow much greater freedom of choice, but still
allow the developer to take full advantage of the chosen VCS.

...Marvin

Bug#943349: ITP: openxr-sdk-source -- openxr loader, basic API layers, and example code

[李健秋]

Package: wnpp
Severity: wishlist
Owner: Andrew Lee (李健秋) 

* Package name: openxr-sdk-source
  Version : 1.0.0
  Upstream Author : The Khronos Group Inc
* URL : https://github.com/KhronosGroup/OpenXR-SDK-Source
* License : Apache2.0
  Programming Lang: C, C++, Python
  Description : openxr loader, basic API layers, and example code

 This package contains source code and build scripts for implementations
 of the OpenXR loader, validation layers, and code samples.

Re: [RFC] Proposal for new source format

[Sean Whitton]

Hello,

On Wed 23 Oct 2019 at 09:49AM -04, Theodore Y. Ts'o wrote:

> Generating a reproducible source package given a particuar git commit
> is trivial.  All you have to do is use "git archive".  For example:
>
> #!/bin/bash
> #
> # Generate the e2fsprogs release tar ball
> #
>
> commit=HEAD
>
> if test -n "$1" ; then
> commit="$1"
> fi
>
> ver=`git show ${commit}:version.h | grep E2FSPROGS_VERSION  \
>   | awk '{print $3}' | tr \" " " | awk '{print $1}'`
> fn=e2fsprogs-${ver}.tar.gz
>
> git archive --prefix=e2fsprogs-${ver}/ ${commit} | gzip -9n > $fn
> echo "Generated $fn"
>
> Note that most of the hair is in deciding what *name* the source tar
> file.

Just for the benefit of those that might not know, this is implemented
in git-deborig in devscripts (though perhaps git-deborig doesn't quite
fit e2fsprogs's needs).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: [RFC] Proposal for new source format

[Theodore Y. Ts'o]

On Wed, Oct 23, 2019 at 11:18:24AM +1000, Russell Stuart wrote:
> 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's reasonable to assume
> it's difficult, and thinking that it's so is not excessively
> pessimistic.

Generating a reproducible source package given a particuar git commit
is trivial.  All you have to do is use "git archive".  For example:

#!/bin/bash
#
# Generate the e2fsprogs release tar ball
#

commit=HEAD

if test -n "$1" ; then
commit="$1"
fi

ver=`git show ${commit}:version.h | grep E2FSPROGS_VERSION  \
| awk '{print $3}' | tr \" " " | awk '{print $1}'`
fn=e2fsprogs-${ver}.tar.gz

git archive --prefix=e2fsprogs-${ver}/ ${commit} | gzip -9n > $fn
echo "Generated $fn"

Note that most of the hair is in deciding what *name* the source tar
file.

- Ted

Re: [RFC] Proposal for new source format

[Ian Jackson]

Russ Allbery writes ("Re: [RFC] Proposal for new source format"):
> That said, Bastian's point about what we should do if we find that the Git
> repository contains something that isn't distributable is valid and needs
> to be dealt with regardless.  I think one of our points of disagreement is
> that I don't see how this is a concern specific to the archive; we already
> have this problem because Salsa is an official project service, so we need
> to solve this problem for arbitrary Git repositories already.

It is also a problem that the dgit git service could face.  That is
also an official project service.  I have anticipated the potential
need to deal with this issue.

With the assistance of the dgit server admin, a maintainer can rewrite
the history; and the server admin can blocklist the troublesome git
objects (which will prevent them from ever being pushed again).  The
server admin can also of course simply delete a package entirely.

So far this has not been necessary.  I don't know how often a similar
situation has arisen with alioth and now salsa.

(I agree with everything else you wrote, too.)

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Merge request friendly handling of debian/changelog

[Simon Richter]

Hi,

On Tue, Oct 22, 2019 at 04:47:53AM +0200, Bastian Blank wrote:

> In Debian most people prefer to have changelog entries with all changes,
> so changes always contain a modification to debian/changelog.

It's worse than that: changelogs are supposed to contain the linear history
of the branch they are on, so the bug tracking system can determine fork
points and find out whether a particular bug is fixed in a particular
version.

> If we also start to use merge requests on Salsa, all those changes will
> contain modifications to debian/changelog, which will usualy conflict
> with each other.  Or worse, are applied to an old changelog entry.  This
> for example happens on the linux packaging project.

Yes, changelog merging needs to be special-cased with a tool that
understands the semantics, in the same way you are not presented with a
conflict resolution screen for the commit message when merging two branches
in a VCS.

Your proposal loses a bit of metadata in the VCS, because the changelog
entry is shown as having been created by the final release commit, and
backtracking through the VCS is made harder because of this. I'd consider
"git blame debian/changelog" to be a very useful tool.

   Simon

+1 (Re: should all bug reports be filed against /source/ packages?)

[Holger Levsen]

On Wed, Oct 23, 2019 at 08:32:11AM +0200, 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.

I agree we should.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#943316: ITP: fst -- Free Studio Technology for audio plugins

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: fst
  Version : 0.1
  Upstream Author : IOhannes m zmölnig 
* URL : https://git.iem.at/zmoelnig/FST/
* License : GPL3
  Programming Lang: C
  Description : Free Studio Technology for audio plugins

 Free Studio Technology (FST) is an audio plugin software interface
 that integrates software synthesizer and effects in digital audio
 workstations.
 It is an unencumbered, bona-fide reverse-engineered SDK compatible with
 the ubiquitous but proprietary, deprecated and retracted VST2 interface.

I intend to maintain this under the multimedia-team umbrella.

Bug#943315: ITP: vst3sdk -- professional audio plugin development kit

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: vst3sdk
  Version : 3.6.13
  Upstream Author : Steinberg Media Technologies GmbH
* URL : https://github.com/steinbergmedia/vst3sdk
* License : GPL3
  Programming Lang: C
  Description : professional audio plugin development kit

 Virtual Studio Technology (VST) is an audio plugin software interface
 that integrates software synthesizer and effects in digital audio
 workstations.
 VST and similar technologies use digital signal processing to simulate
 traditional recording studio hardware in software.
 .
 VST is the de-facto industry standard for audio plugins and plugin hosts.

I intend to package this under the umbrella of the multimedia-team.

Re: [RFC] Proposal for new source format

[Ansgar]

Simon McVittie writes:
> 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 able to cope with malicious/crafted files
> without introducing security vulnerabilities (whether that means arbitrary
> code execution via parser bugs, or denial of service via "zip bombs")
> is the PGP signature verification on the (uncompressed) .dsc. Everything
> else is authenticated before being decompressed, either directly via
> the PGP signature or via the authenticated hashes in the .dsc.

I think there are two separate uses:

 - if you want to validate that the upload is as intended by the
   maintainer, then a signature of the uncompressed source is
   sufficient. (A signature over the compressed source works too if you
   do not want to switch to new compression format later.)

 - for all other purposes (regular downloads, ...), one would like a
   signature over the data that is used, i.e. usually for downloads of
   the compressed variant.

kernel.org uses a similar scheme: there are signatures for the
uncompressed tarballs by the maintainer (linux-*.tar.sign).  In addition
there is a sha256sums.asc which has strong hashes of the compresssed
files (linux-*.tar.{gz,xz}) and is signed by their archive management
system.

As far as I understand git-archive is fairly good as reproducing
identical uncompressed tarballs at a later time from the git repository.

Ansgar

📌 debian.org - Site report

[Taylor T. [WP Optim]]

 Hello,

Your website, *debian.org * was recently tested
with our *Speed
Test Software*.

Optimization report: wpoptim.co/#1909271808933f2a6326

There are multiple *bottlenecks* and opportunities to *optimize performance*.
This has a *high impact on search engine* visibility and *bounce rate!*

Here's how we can help:

   1. We provide *fully managed hosting*, custom optimized for *WordPress*,
   using *single tenant* private servers.
   All powered by *Amazon Cloud platform*, making websites run blazing fast.

   2. If needed, we can also implement full redesigns using the best
   premium WordPress themes, at no cost whatsoever, for all our customers.



Would you be interested in fixing your site problems?



---

*Taylor T.* - WordPress Specialist
*WP Optim * - Powered by Amazon
Web Services