📌 debian.org - Site report

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

Re: [RFC] Proposal for new source format

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 >

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

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 :

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

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 au

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

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. --

Re: Merge request friendly handling of debian/changelog

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

Re: [RFC] Proposal for new source format

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 > t

Re: [RFC] Proposal for new source format

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

Re: [RFC] Proposal for new source format

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 > > i

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

Re: [RFC] Proposal for new source format

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 abilit

Re: [RFC] Proposal for new source format

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 mis

Re: [RFC] Proposal for new source format

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

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

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,