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

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

-- 
Marco

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

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.

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.

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

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

Am Sat, 07 Oct 2017 12:45:30 +0000
schrieb Martin Nowak <code@dawg.eu>:

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

Yes, it is absolutely feasible to download several files.
Currently the URIs are computable from the release year and
version, so maintaining 2 or 3 URIs is ok. Also now that the
path issues are worked around on my side they have no running
maintenance cost. It is different with missing files, because
then you have to manually collect the version that matches the
release from GitHub.
If you thought of removing the sources from the archives
entirely and point to GitHub that's fine with me. The concern
Eugene brought up about checksum verification failures still
holds though. It then depends on how quickly the package
maintainers respond and fix their scripts.

-- 
Marco