Thread overview
October 01
First beta for the 2.076.1 point release.

http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.076.1.html

Please report any bugs at https://issues.dlang.org

- -Martin

October 01
Could you include the "default_ddoc_theme.ddoc" and "config.sh" in the source releases? The sources cannot be compiled without them.

-- 
Marco
October 01
P.S.: The directory layout could be improved as well. Currently there is:

src\
   +-dmd
   +-druntime
   +-phobos

But druntime in posix.mak:10 expects a src directory inside the dmd directory:

dmd\
   +-src

So effectively the directory names have to be swapped for that to work. At that point the superfluous directories for the other operating systems, containing only dmd.conf could be removed as well.

Other than that I'm happy with the package, as it provides the man pages, pre-built HTML documentation and a binary to bootstrap dmd on systems that lack a D compiler. (The use case being compilation from source for Gentoo Linux.)

-- 
Marco

October 07
On Sunday, 1 October 2017 at 17:36:12 UTC, Marco Leise wrote:
> Other than that I'm happy with the package, as it provides the man pages, pre-built HTML documentation and a binary to bootstrap dmd on systems that lack a D compiler. (The use case being compilation from source for Gentoo Linux.)

I won't reorganize the folder structure in a point release. But thanks for pointing out that this needs a fix.
Would getting the sources as a separate download (or just from github) be a feasible alternative.
October 07
On Saturday, 7 October 2017 at 12:45:30 UTC, Martin Nowak wrote:
> On Sunday, 1 October 2017 at 17:36:12 UTC, Marco Leise wrote:
>> Other than that I'm happy with the package, as it provides the man pages, pre-built HTML documentation and a binary to bootstrap dmd on systems that lack a D compiler. (The use case being compilation from source for Gentoo Linux.)
>
> I won't reorganize the folder structure in a point release. But thanks for pointing out that this needs a fix.
> Would getting the sources as a separate download (or just from github) be a feasible alternative.

But please consider something different than github as alternative. GitHub doesn't guarantee that it always generates the same tarball for the same commit/release, so the checksum can change and the downloaded tarball looks corrupted, though it has absolutely the same content.
October 09
On 10/07/2017 03:20 PM, Eugene Wissner wrote:
> But please consider something different than github as alternative. GitHub doesn't guarantee that it always generates the same tarball for the same commit/release, so the checksum can change and the downloaded tarball looks corrupted, though it has absolutely the same content.

Ah good to know, indeed seems to be a problem for GH's archive endpoints? Would of course be a nogo for distro build receipts. https://github.com/libgit2/libgit2/issues/4343#issuecomment-328631745
October 09
On Monday, 9 October 2017 at 18:56:13 UTC, Martin Nowak wrote:
> On 10/07/2017 03:20 PM, Eugene Wissner wrote:
>> But please consider something different than github as alternative. GitHub doesn't guarantee that it always generates the same tarball for the same commit/release, so the checksum can change and the downloaded tarball looks corrupted, though it has absolutely the same content.
>
> Ah good to know, indeed seems to be a problem for GH's archive endpoints? Would of course be a nogo for distro build receipts. https://github.com/libgit2/libgit2/issues/4343#issuecomment-328631745

I had this problem about two weeks ago.
As an example.. Slackware is a half-binary, half-source based Linux. The core system is provided as binary packages and the most users build other programs from slackbuilds.org which provides a huge collection of third-party packages as automated build scripts (but they don't keep the sources, only scripts that build a package from the source). There are also automation tools to compile all the dependencies if needed. It is slightly similar to how freebsd ports work. Such a tool has to verify that the downloaded source is not corrupted and it is done with md5.
Actually I think that it can be a problem for many smaller linux distributions that are community-driven and not  backed by commercial organizations and don't have the power to keep all sources themselves like debian does.
GitHub breaks the archives very very seldom but if it happens it is very painful