Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Thursday, 21 April 2016 at 22:00:11 UTC, Joseph Rushton 
Wakeling wrote:
On Thursday, 21 April 2016 at 20:13:07 UTC, Joseph Rushton 
Wakeling wrote:
On Monday, 18 April 2016 at 21:54:43 UTC, Matthias Klumpp 
wrote:
Unfortunately it FTBFSes... Hopefully we can get the patch 
for that in as well: 
https://github.com/ldc-developers/ldc/commit/cb709bfc0a0a3ee8a730c0a99fa53198b6d75364.patch

(I'm working on that)


I see you succeeded -- many thanks again :-)


Might amuse you to know: I just did a fresh 16.04 install this 
evening, and ldc was the first package I installed, followed by 
dub ;-)


Both seem to work like a charm.  And besides the packages, 
thanks for the updated new ldc description!


Thanks! :-) The updated ldc description wasn't me though, that 
was Konstantinos with the 1:0.17.1-1 release ;-)

Re: Official dub packages for Debian and Ubuntu

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 21 April 2016 at 20:13:07 UTC, Joseph Rushton 
Wakeling wrote:

On Monday, 18 April 2016 at 21:54:43 UTC, Matthias Klumpp wrote:
Unfortunately it FTBFSes... Hopefully we can get the patch for 
that in as well: 
https://github.com/ldc-developers/ldc/commit/cb709bfc0a0a3ee8a730c0a99fa53198b6d75364.patch

(I'm working on that)


I see you succeeded -- many thanks again :-)


Might amuse you to know: I just did a fresh 16.04 install this 
evening, and ldc was the first package I installed, followed by 
dub ;-)


Both seem to work like a charm.  And besides the packages, thanks 
for the updated new ldc description!

Re: Official dub packages for Debian and Ubuntu

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 18 April 2016 at 21:54:43 UTC, Matthias Klumpp wrote:
Unfortunately it FTBFSes... Hopefully we can get the patch for 
that in as well: 
https://github.com/ldc-developers/ldc/commit/cb709bfc0a0a3ee8a730c0a99fa53198b6d75364.patch

(I'm working on that)


I see you succeeded -- many thanks again :-)

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Monday, 18 April 2016 at 19:47:46 UTC, Joseph Rushton Wakeling 
wrote:

On Monday, 18 April 2016 at 16:57:27 UTC, Matthias Klumpp wrote:
Freeze exception for LDC was approved last-minute, which means 
the final release will be in Xenial :-)


That's fantastic, thank you very much for making this happen :-)


Unfortunately it FTBFSes... Hopefully we can get the patch for 
that in as well: 
https://github.com/ldc-developers/ldc/commit/cb709bfc0a0a3ee8a730c0a99fa53198b6d75364.patch

(I'm working on that)

Yeah, the description is really off-putting and should 
absolutely be changed... You can contect the Debian 
maintainer, Konstantinos Margaritis  about 
it.
Alternatively, I can also report a bug against LDC (need to 
find time for that, maybe tomorrow).


I'll try to follow up on this in the next days -- I'll try to 
come up with a proposed alternative text for the LDC devs to 
bless.


Nice! Btw, I have a note in my code that LDC apparently failed 
when using std.parallelism.parallel - I'll take a look if that 
issue still exists and if that's in my code or in LDC.

Re: Official dub packages for Debian and Ubuntu

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 18 April 2016 at 16:57:27 UTC, Matthias Klumpp wrote:
Freeze exception for LDC was approved last-minute, which means 
the final release will be in Xenial :-)


That's fantastic, thank you very much for making this happen :-)

Yeah, the description is really off-putting and should 
absolutely be changed... You can contect the Debian maintainer, 
Konstantinos Margaritis  about it.
Alternatively, I can also report a bug against LDC (need to 
find time for that, maybe tomorrow).


I'll try to follow up on this in the next days -- I'll try to 
come up with a proposed alternative text for the LDC devs to 
bless.

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Tuesday, 12 April 2016 at 16:57:41 UTC, Joseph Rushton 
Wakeling wrote:
On Tuesday, 12 April 2016 at 01:58:13 UTC, Matthias Klumpp 
wrote:

[...]
I can ask, but given that the Xenial final freeze is on 24. 
April (release on 26.) and changing compiler versions that 
late in the cycle is potentially dangerous, I guess there is 
only a slim chance of success... On the pro-side is that 
having a beta compiler in the LTS release is undesirable, but 
even then I need to find an Ubuntu developer who does have 
time to do the sync and get the feature-freeze-exception. LDC 
FTBFSing on armel in Debian (and not entering testing due to 
that at time) is also an issue :-/


Ouch :-(  Well, if you are happy to look into it, that would be 
great -- no pressure, though. :-)


Freeze exception for LDC was approved last-minute, which means 
the final release will be in Xenial :-)


BTW, the package description for ldc, in both Debian and 
Ubuntu, is insanely out of date: it reads,


   LDC already compiles a lot of D code, but should still be
   considered beta quality. Take a look at the tickets to get
   a better impression on what still needs to be implemented.

... which AFAICT is unchanged from something like 5+ years ago, 
when the ldc packaged in Debian/Ubuntu was a D1-only compiler 
still in heavy development.


Yeah, the description is really off-putting and should absolutely 
be changed... You can contect the Debian maintainer, Konstantinos 
Margaritis  about it.
Alternatively, I can also report a bug against LDC (need to find 
time for that, maybe tomorrow).


Cheers,
Matthias

Re: Official dub packages for Debian and Ubuntu

[Russel Winder via Digitalmars-d-announce]

On Fri, 2016-04-15 at 20:03 +0200, Jordi Sayol via Digitalmars-d-
announce wrote:
> […]
> Many thanks Andrei, and all d-apt users.

Thanks for creating and running D-Apt – all it's users a A-D-Apt-able.
;-)


I wish there was an equivalent RPM store for Fedora Rawhide. I'd be
happy to help out creating something, but not if I am the only user.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Friday, 15 April 2016 at 09:15:05 UTC, Johannes Pfau wrote:

Am Thu, 14 Apr 2016 23:16:49 +
schrieb Matthias Klumpp :

On Thursday, 14 April 2016 at 17:46:55 UTC, Johannes Pfau 
wrote:
> OSS projects do not use interface files though: It prevents 
> inlining of functions and there's no real benefit for OSS 
> projects. Interface files are (theoretically) useful for 
> closed source libraries if you don't want to ship the source 
> code.


I think those would also be useful for FLOSS projects, if you 
ship a compiled binary and don't want to recompile the code. 
This is the case for example for very huge projects which take 
long to compile (think in WebKit or Eigen3 dimensions), or for 
Linux distributions which want to separate as much code as 
possible and prevent code duplication and statically linked 
stuff to make security uploads easier and faster.


I totally agree it makes sense to ship precompiled libraries. 
But even with precompiled libraries you can still ship the full 
source code instead of header files. An example:


[...]

The important point here is that you can use the normal source 
code as headers. The source code of a library is not 
recompiled, it's only used to parse function definitions and 
similar stuff. The compilation speed should be very similar for 
.d and .di files as well. The benefit of shipping the complete 
source code is that fooFunc can be inlined into main.d with the 
foo.d source, but not with foo.di.


Shipping .di files only makes sense if you have to hide the 
source code.


Or when the source-code is very large, I guess. But the way D 
handles this makes much sense to me!



[...]


I agree having a common ABI should be prioritized. It's really
annoying for distributions (E.g. archlinux installs 
druntime/phobos into

different directories /usr/include/dlang/{gdc,dmd,ldc} and never
installs compiled libraries). Shared D libraries are useless in
practice because of this issue.


Yeah, and this makes D pretty hard to sell to distributors. While 
I would argue that for applications it is no longer essential to 
be packages and shipped by distributions (or rather it won't be 
in future), for a "new" programming language this is a crucial 
thing.
As soon as it is easy to try out for developers, more people will 
"just try it" and maybe stick with it. If testing it is hard due 
to incompatible standard libraries, runtimes, or simply missing 
free D compilers, people won't try it.
In fact, that it also is pretty hard for people to compile 
applications written in D on distributions other than Debian (and 
even there it was not without issues...) was *the* biggest 
concern for me.


This needs coordinated work from all compiler teams though. For 
GDC I'll finally have to finish shared library support first...


That would be awesome to have! Thank you for working on this!

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Saturday, 16 April 2016 at 09:48:01 UTC, Joseph Rushton 
Wakeling wrote:

[..]
As for further dub stuff, it is important that 
https://github.com/D-Programming-Language/dub/issues/811 is 
addressed, so we can build software using dub without 
downloading stuff from the internet.
Btw, since D doesn't know traditional headers like C/C++, how 
would I link against a library without having the full 
sourcecode present somewhere?


Is there anything wrong -- in principle -- with (for now) 
treating open-source D libraries much like the various Boost 
C++ libraries, which AFAICT are almost entirely header-based?


It's a bit ugly, because we are essentially embedding code copies 
into every binary, instead of having a proper shared library 
stuff can link to (and we also need to recompile everything 
again).
Aside from that, there is no real issue - Debian policy allows 
doing that, and in fact, this is the thing I am currently 
attempting to do to work around the ABI issues.


I ask because so far as I can tell that would work around the 
immediate problems of compiler incompatibilities, it would not 
add any extra work compiler-wise that's not already there with 
dub's current way of doing things, and for template-heavy D 
code (which is quite a lot of code), it makes no difference, 
since that would have to be available in .d or .di files anyway.


Jup - what dub would still need to do though is to find the 
globally installed software, so we don't need to patch each 
dub.(json|sdl) file to find the code which was installed via 
distro packages.
At time, I install the D code into `/usr/include/d/`[1] 
where dub could theoretically automatically find it.


[1]: Probably not the best location since this isn't actually a 
header... (alternative could be `/usr/share/dlang/`)

Re: Official dub packages for Debian and Ubuntu

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Thursday, 14 April 2016 at 16:29:31 UTC, Matthias Klumpp wrote:
FTR, I filed 
https://bugs.launchpad.net/ubuntu/+source/ldc/+bug/1570006 - if 
we are lucky, this still has a chance to go in.


That's great, thank you very much.

As for further dub stuff, it is important that 
https://github.com/D-Programming-Language/dub/issues/811 is 
addressed, so we can build software using dub without 
downloading stuff from the internet.
Btw, since D doesn't know traditional headers like C/C++, how 
would I link against a library without having the full 
sourcecode present somewhere?


Is there anything wrong -- in principle -- with (for now) 
treating open-source D libraries much like the various Boost C++ 
libraries, which AFAICT are almost entirely header-based?


I ask because so far as I can tell that would work around the 
immediate problems of compiler incompatibilities, it would not 
add any extra work compiler-wise that's not already there with 
dub's current way of doing things, and for template-heavy D code 
(which is quite a lot of code), it makes no difference, since 
that would have to be available in .d or .di files anyway.

Re: Official dub packages for Debian and Ubuntu

[Jordi Sayol via Digitalmars-d-announce]

El 15/04/16 a les 19:52, Andrei Alexandrescu via Digitalmars-d-announce ha 
escrit:
> Awesomne, Jordi. I recently got a notice that the dmd compiler has been 
> updated by Ubuntu's package manager. Clicked, got it, all went smoothly. 
> Should I take it we owe all of that to you? -- Andrei

I think so :-)
Many thanks Andrei, and all d-apt users.

Re: Official dub packages for Debian and Ubuntu

[Andrei Alexandrescu via Digitalmars-d-announce]

On 04/15/2016 01:34 PM, Jordi Sayol via Digitalmars-d-announce wrote:

I'll include "Provides: d-compiler" on dlang dmd deb package and d-apt dmd-bin 
deb too. Many thanks!


Awesomne, Jordi. I recently got a notice that the dmd compiler has been 
updated by Ubuntu's package manager. Clicked, got it, all went smoothly. 
Should I take it we owe all of that to you? -- Andrei

Re: Official dub packages for Debian and Ubuntu

[Jordi Sayol via Digitalmars-d-announce]

El 15/04/16 a les 01:09, Matthias Klumpp via Digitalmars-d-announce ha escrit:
> On Thursday, 14 April 2016 at 18:42:49 UTC, Jordi Sayol wrote:
>> El 14/04/16 a les 17:54, Matthias Klumpp via Digitalmars-d-announce ha 
>> escrit:
>>> On Tuesday, 12 April 2016 at 13:28:29 UTC, Jordi Sayol wrote:
>>> [...]
>>> I think with "property" you mean "virtual package". See 
>>> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual
>>> Basically, the dmd package needs a "Provides: d-compiler" line, then it 
>>> should be able to satisfy the dependencies of the dub package.
>>
>> Thanks. What happen is multiple packages, all of them not installed, sets 
>> "Provides: d-compiler"? Which one is installed?
> 
> I think in that case the (alphabetically) first real package is installed. 
> This is an uncommon case though, usually when virtual packages are used, a 
> default dependency is provided (so you have "default | virtual").
> 

I'll include "Provides: d-compiler" on dlang dmd deb package and d-apt dmd-bin 
deb too. Many thanks!

Re: Official dub packages for Debian and Ubuntu

[Johannes Pfau via Digitalmars-d-announce]

Am Thu, 14 Apr 2016 23:16:49 +
schrieb Matthias Klumpp :

> On Thursday, 14 April 2016 at 17:46:55 UTC, Johannes Pfau wrote:
> > OSS projects do not use interface files though: It prevents 
> > inlining of functions and there's no real benefit for OSS 
> > projects. Interface files are (theoretically) useful for closed 
> > source libraries if you don't want to ship the source code.  
> 
> I think those would also be useful for FLOSS projects, if you 
> ship a compiled binary and don't want to recompile the code.
> This is the case for example for very huge projects which take 
> long to compile (think in WebKit or Eigen3 dimensions), or for 
> Linux distributions which want to separate as much code as 
> possible and prevent code duplication and statically linked stuff 
> to make security uploads easier and faster.
> 

I totally agree it makes sense to ship precompiled libraries. But even
with precompiled libraries you can still ship the full source code
instead of header files. An example:

a/foo.d:

module foo;
int fooFunc() {return 42;}


=> dmd -H a/foo.d => b/foo.di

// D import file generated from 'foo.d'
module foo;
int fooFunc();


dmd -lib a/foo.d -oflibfoo.a

main.d

import foo;
void main(){fooFunc()}


// We need foo.di or foo.d in the import path
dmd main.d -L-L. -L-lfoo
main.d(1): Error: module foo is in file 'foo.d' which cannot be read

// This uses the foo.di header
dmd main.d -L-L. -L-lfoo -Ib

// This uses foo.d as a header, but does _not_ compile foo.d
dmd main.d -L-L. -L-lfoo -Ia


The important point here is that you can use the normal source code as
headers. The source code of a library is not recompiled, it's only used
to parse function definitions and similar stuff. The compilation speed
should be very similar for .d and .di files as well. The benefit of
shipping the complete source code is that fooFunc can be inlined into
main.d with the foo.d source, but not with foo.di.

Shipping .di files only makes sense if you have to hide the source
code.

> > If you built a library with GDC you can't use it with LDC or 
> > DMD. This is one reason why dub compiles everything from 
> > source. (Even different frontend versions can sometimes break 
> > ABI compatibility).  
> 
> Is there any way this can be fixed? 
> https://dlang.org/spec/abi.html gave me the impression D has a 
> defined ABI the compilers adhere too (which would be a great 
> advantage over C++).
> Fixing this would be pretty useful, not only for the distro 
> usecase, I think.

The ABI is partially standardized:
* Name mangling is the same for all compilers.
* D has a special calling convention on X86 windows, but all other
  architectures and all other OS use the C calling convention. The
  compilers should be compatible, but this is something which needs
  some testing. 

* Exception handling: DMD recently implemented DWARF exception
  handling, so the compilers could be compatible but the personality
  functions are not. I'm not sure if the implementations are
  compatible, but not even the function names match
  (__dmd_personality_v0 / __gdc_personality_v0)
* The biggest problem is druntime: we need to make sure that the
  druntime libraries used by different compilers have a compatible ABI.

> Thanks for the explanations, this is useful to know and helps me 
> to work around some of the issues short-term (long-term we would 
> really need a solution for these issues, since this will become a 
> huge issue if/when more D code makes it into distros).

I agree having a common ABI should be prioritized. It's really
annoying for distributions (E.g. archlinux installs druntime/phobos into
different directories /usr/include/dlang/{gdc,dmd,ldc} and never
installs compiled libraries). Shared D libraries are useless in
practice because of this issue.

This needs coordinated work from all compiler teams though. For GDC
I'll finally have to finish shared library support first... 

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Thursday, 14 April 2016 at 17:46:55 UTC, Johannes Pfau wrote:

[...]

(1) Interface files

We have .di interface files as a replacement for C/C++ headers 
(although the .di extension is only a convention, you can also 
use the .d extension). These files do not contain function 
bodies, but they still need the complete source code for 
templates. The compilers can generate interface files from 
normal source code.


https://dlang.org/dmd-linux.html#interface-files


Looks like a pretty good choice for handling the 
interface-with-library issue.


OSS projects do not use interface files though: It prevents 
inlining of functions and there's no real benefit for OSS 
projects. Interface files are (theoretically) useful for closed 
source libraries if you don't want to ship the source code.


I think those would also be useful for FLOSS projects, if you 
ship a compiled binary and don't want to recompile the code.
This is the case for example for very huge projects which take 
long to compile (think in WebKit or Eigen3 dimensions), or for 
Linux distributions which want to separate as much code as 
possible and prevent code duplication and statically linked stuff 
to make security uploads easier and faster.



(2) Linking against installed libraries

The compilers can of course link against pre-compiled D 
libraries. IIRC dub does not have integrated support for this. 
The real problem is the D compilers are not ABI compatible.


Urgh...

If you built a library with GDC you can't use it with LDC or 
DMD. This is one reason why dub compiles everything from 
source. (Even different frontend versions can sometimes break 
ABI compatibility).


Is there any way this can be fixed? 
https://dlang.org/spec/abi.html gave me the impression D has a 
defined ABI the compilers adhere too (which would be a great 
advantage over C++).
Fixing this would be pretty useful, not only for the distro 
usecase, I think.


Thanks for the explanations, this is useful to know and helps me 
to work around some of the issues short-term (long-term we would 
really need a solution for these issues, since this will become a 
huge issue if/when more D code makes it into distros).

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Thursday, 14 April 2016 at 18:42:49 UTC, Jordi Sayol wrote:
El 14/04/16 a les 17:54, Matthias Klumpp via 
Digitalmars-d-announce ha escrit:

On Tuesday, 12 April 2016 at 13:28:29 UTC, Jordi Sayol wrote:
[...]
I think with "property" you mean "virtual package". See 
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual
Basically, the dmd package needs a "Provides: d-compiler" 
line, then it should be able to satisfy the dependencies of 
the dub package.


Thanks. What happen is multiple packages, all of them not 
installed, sets "Provides: d-compiler"? Which one is installed?


I think in that case the (alphabetically) first real package is 
installed. This is an uncommon case though, usually when virtual 
packages are used, a default dependency is provided (so you have 
"default | virtual").

Re: Official dub packages for Debian and Ubuntu

[Jordi Sayol via Digitalmars-d-announce]

El 14/04/16 a les 17:54, Matthias Klumpp via Digitalmars-d-announce ha escrit:
> On Tuesday, 12 April 2016 at 13:28:29 UTC, Jordi Sayol wrote:
>> El 12/04/16 a les 14:26, Matthias Klumpp via Digitalmars-d-announce ha 
>> escrit:
 I assume that the DMD package from dlang, or better d-apt, sets the d- 
 compiler property. Should dmd be prefered if it is present?
>>>
>>> I think so, since when installing it from non-free 3rd-party sources, the 
>>> user made an explicit choice for DMD.
>>> In terms of packaging, the packaging doesn't really care, any D compiler 
>>> will satisfy the requirements of the dub package.
>>
>>
>> No, dmd deb packages from dlang and d-apt do not set any d-compiler 
>> property. Where should it be set?
> 
> I think with "property" you mean "virtual package". See 
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual
> Basically, the dmd package needs a "Provides: d-compiler" line, then it 
> should be able to satisfy the dependencies of the dub package.

Thanks. What happen is multiple packages, all of them not installed, sets 
"Provides: d-compiler"? Which one is installed?

Re: Official dub packages for Debian and Ubuntu

[Johannes Pfau via Digitalmars-d-announce]

Am Thu, 14 Apr 2016 16:29:31 +
schrieb Matthias Klumpp :

> On Thursday, 14 April 2016 at 16:05:04 UTC, Matthias Klumpp wrote:
> > On Tuesday, 12 April 2016 at 16:57:41 UTC, Joseph Rushton 
> > Wakeling wrote:  
> >> On Tuesday, 12 April 2016 at 01:58:13 UTC, Matthias Klumpp 
> >> wrote:  
> >>> On Monday, 11 April 2016 at 21:58:55 UTC, Joseph Rushton [...]
> >>> I can ask, but given that the Xenial final freeze is on 24. 
> >>> April (release on 26.) and changing compiler versions that 
> >>> late in the cycle is potentially dangerous, I guess there is 
> >>> only a slim chance of success... On the pro-side is that 
> >>> having a beta compiler in the LTS release is undesirable, but 
> >>> even then I need to find an Ubuntu developer who does have 
> >>> time to do the sync and get the feature-freeze-exception. LDC 
> >>> FTBFSing on armel in Debian (and not entering testing due to 
> >>> that at time) is also an issue :-/  
> >>
> >> Ouch :-(  Well, if you are happy to look into it, that would 
> >> be great -- no pressure, though. :-)  
> 
> FTR, I filed 
> https://bugs.launchpad.net/ubuntu/+source/ldc/+bug/1570006 - if 
> we are lucky, this still has a chance to go in.
> 
> As for further dub stuff, it is important that 
> https://github.com/D-Programming-Language/dub/issues/811 is 
> addressed, so we can build software using dub without downloading 
> stuff from the internet.
> Btw, since D doesn't know traditional headers like C/C++, how 
> would I link against a library without having the full sourcecode 
> present somewhere?
> 

(1) Interface files

We have .di interface files as a replacement for C/C++ headers (although
the .di extension is only a convention, you can also use the .d
extension). These files do not contain function bodies, but they still
need the complete source code for templates. The compilers can generate
interface files from normal source code.

https://dlang.org/dmd-linux.html#interface-files

OSS projects do not use interface files though: It prevents inlining of
functions and there's no real benefit for OSS projects. Interface files
are (theoretically) useful for closed source libraries if you don't
want to ship the source code.


(2) Linking against installed libraries

The compilers can of course link against pre-compiled D libraries. IIRC
dub does not have integrated support for this. The real problem is the
D compilers are not ABI compatible. If you built a library with GDC you
can't use it with LDC or DMD. This is one reason why dub compiles
everything from source. (Even different frontend versions can sometimes
break ABI compatibility).

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Thursday, 14 April 2016 at 16:05:04 UTC, Matthias Klumpp wrote:
On Tuesday, 12 April 2016 at 16:57:41 UTC, Joseph Rushton 
Wakeling wrote:
On Tuesday, 12 April 2016 at 01:58:13 UTC, Matthias Klumpp 
wrote:

On Monday, 11 April 2016 at 21:58:55 UTC, Joseph Rushton [...]
I can ask, but given that the Xenial final freeze is on 24. 
April (release on 26.) and changing compiler versions that 
late in the cycle is potentially dangerous, I guess there is 
only a slim chance of success... On the pro-side is that 
having a beta compiler in the LTS release is undesirable, but 
even then I need to find an Ubuntu developer who does have 
time to do the sync and get the feature-freeze-exception. LDC 
FTBFSing on armel in Debian (and not entering testing due to 
that at time) is also an issue :-/


Ouch :-(  Well, if you are happy to look into it, that would 
be great -- no pressure, though. :-)


FTR, I filed 
https://bugs.launchpad.net/ubuntu/+source/ldc/+bug/1570006 - if 
we are lucky, this still has a chance to go in.


As for further dub stuff, it is important that 
https://github.com/D-Programming-Language/dub/issues/811 is 
addressed, so we can build software using dub without downloading 
stuff from the internet.
Btw, since D doesn't know traditional headers like C/C++, how 
would I link against a library without having the full sourcecode 
present somewhere?


Ideally, we would compile something like mustache-d[1] when 
building a .deb package for it, then have a dependency on that 
library pick up the prebuilt static library (or dynamic library, 
ideally, if there is one) and link against it (so we don't 
rebuild the code over and over again).
There doesn't seem to be a way though to export the interfaces a 
D library provides to link against a D library at time, so we 
likely would need to ship the full source additionally to the D 
library in the -dev package, and have dub figure out the details 
(make it pick up the existing binary instead of recompiling the 
module)...
These issues need to be solved for any distro, not only Debian, 
before packaging D code that is using dub becomes easily possible 
(ideally, a solution exists already, that I just don't know about 
yet ^^).


[1]: https://github.com/repeatedly/mustache-d

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Tuesday, 12 April 2016 at 16:57:41 UTC, Joseph Rushton 
Wakeling wrote:
On Tuesday, 12 April 2016 at 01:58:13 UTC, Matthias Klumpp 
wrote:
On Monday, 11 April 2016 at 21:58:55 UTC, Joseph Rushton 
Wakeling wrote:
Related note: I see the lcd version in xenial is 0.17.0~beta2 
-- I don't suppose there's any chance of upgrading that to 
the stable 0.17.1 release ... ?  (Not asking you to do it 
personally, just wondering if that's something that could be 
achieved.)


I can ask, but given that the Xenial final freeze is on 24. 
April (release on 26.) and changing compiler versions that 
late in the cycle is potentially dangerous, I guess there is 
only a slim chance of success... On the pro-side is that 
having a beta compiler in the LTS release is undesirable, but 
even then I need to find an Ubuntu developer who does have 
time to do the sync and get the feature-freeze-exception. LDC 
FTBFSing on armel in Debian (and not entering testing due to 
that at time) is also an issue :-/


Ouch :-(  Well, if you are happy to look into it, that would be 
great -- no pressure, though. :-)


I get the point about not updating compilers late in the 
development cycle, but this update is likely to produce a 
better package and I can't see it triggering any other package 
rebuilds beyond the LDC phobos/druntime packages.


BTW, the package description for ldc, in both Debian and 
Ubuntu, is insanely out of date: it reads,


   LDC already compiles a lot of D code, but should still be
   considered beta quality. Take a look at the tickets to get
   a better impression on what still needs to be implemented.

... which AFAICT is unchanged from something like 5+ years ago, 
when the ldc packaged in Debian/Ubuntu was a D1-only compiler 
still in heavy development.


There is no real policy, at least I have found none. But from 
my tests, ldc simply crashed right away when trying to 
compile, later it wasn't able to process some code gdc had no 
problems with (I haven't tried the upcoming release). Since 
the GNU Compiler Collection is Debian's default compiler, I 
have set the compiler dependency of dub to gdc | ldc | 
d-compiler, so gdc is preferred, but replacing it with any 
other compiler will work too.


That's very odd.  What were you trying to build ... ?


This is likely a packaging issue - I tried this again on Xenial, 
and got

```
Warning: failed to locate the configuration file ldc2.conf
Error: cannot find source code for runtime library file 'object.d'
   ldc2 might not be correctly installed.
```
So yeah, this doesn't look like an upstream issue. I'll play 
around with LDC a bit more (and update it to a non-beta version, 
and maybe to Git master), maybe this evening - I really want 
std.concurrency.Generator, which GDC doesn't provide and which I 
currently embed in my code. The better std.getopt in newer 
standard library versions would also be nice (not sure how recent 
that is in LDC).


I didn't touch that, since dub seems to automatically find the 
right compiler. The preference seems to be dmd >> gdc >> ldc2, 
which looks sane to me.


Yea, sounds good.

Related note: would it be viable in principle to get dmd itself 
into Debian and Ubuntu repositories via (respectively) non-free 
and multiverse ... ?  Again, not asking you to do the work, but 
just curious based on your experience of being a Debian 
packager.


For non-free/multiverse: Maybe. Proprietary compilers are 
generally something not liked very much in the Debian community, 
and pushing the free compilers would be seen as the much better 
approach.
That being said, if someone wants to do the work and do proper 
packaging of dmd, nobody would stop that work being done either.


For Debian Stretch I assume the situation will be much better 
though :-) (given the state of the LDC and GDC Git repos).


Looking forward to it :-)  And, thank you again!


:-)

Re: Official dub packages for Debian and Ubuntu

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Tuesday, 12 April 2016 at 01:58:13 UTC, Matthias Klumpp wrote:
On Monday, 11 April 2016 at 21:58:55 UTC, Joseph Rushton 
Wakeling wrote:
Related note: I see the lcd version in xenial is 0.17.0~beta2 
-- I don't suppose there's any chance of upgrading that to the 
stable 0.17.1 release ... ?  (Not asking you to do it 
personally, just wondering if that's something that could be 
achieved.)


I can ask, but given that the Xenial final freeze is on 24. 
April (release on 26.) and changing compiler versions that late 
in the cycle is potentially dangerous, I guess there is only a 
slim chance of success... On the pro-side is that having a beta 
compiler in the LTS release is undesirable, but even then I 
need to find an Ubuntu developer who does have time to do the 
sync and get the feature-freeze-exception. LDC FTBFSing on 
armel in Debian (and not entering testing due to that at time) 
is also an issue :-/


Ouch :-(  Well, if you are happy to look into it, that would be 
great -- no pressure, though. :-)


I get the point about not updating compilers late in the 
development cycle, but this update is likely to produce a better 
package and I can't see it triggering any other package rebuilds 
beyond the LDC phobos/druntime packages.


BTW, the package description for ldc, in both Debian and Ubuntu, 
is insanely out of date: it reads,


   LDC already compiles a lot of D code, but should still be
   considered beta quality. Take a look at the tickets to get
   a better impression on what still needs to be implemented.

... which AFAICT is unchanged from something like 5+ years ago, 
when the ldc packaged in Debian/Ubuntu was a D1-only compiler 
still in heavy development.


There is no real policy, at least I have found none. But from 
my tests, ldc simply crashed right away when trying to compile, 
later it wasn't able to process some code gdc had no problems 
with (I haven't tried the upcoming release). Since the GNU 
Compiler Collection is Debian's default compiler, I have set 
the compiler dependency of dub to gdc | ldc | d-compiler, so 
gdc is preferred, but replacing it with any other compiler will 
work too.


That's very odd.  What were you trying to build ... ?

I didn't touch that, since dub seems to automatically find the 
right compiler. The preference seems to be dmd >> gdc >> ldc2, 
which looks sane to me.


Yea, sounds good.

Related note: would it be viable in principle to get dmd itself 
into Debian and Ubuntu repositories via (respectively) non-free 
and multiverse ... ?  Again, not asking you to do the work, but 
just curious based on your experience of being a Debian packager.


For Debian Stretch I assume the situation will be much better 
though :-) (given the state of the LDC and GDC Git repos).


Looking forward to it :-)  And, thank you again!

Re: Official dub packages for Debian and Ubuntu

[Jordi Sayol via Digitalmars-d-announce]

El 12/04/16 a les 14:26, Matthias Klumpp via Digitalmars-d-announce ha escrit:
>> I assume that the DMD package from dlang, or better d-apt, sets the d- 
>> compiler property. Should dmd be prefered if it is present?
> 
> I think so, since when installing it from non-free 3rd-party sources, the 
> user made an explicit choice for DMD.
> In terms of packaging, the packaging doesn't really care, any D compiler will 
> satisfy the requirements of the dub package.


No, dmd deb packages from dlang and d-apt do not set any d-compiler property. 
Where should it be set?

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Tuesday, 12 April 2016 at 07:03:44 UTC, Russel Winder wrote:

[...]

If the Debian ldc2 compiler is crashing on the same source that 
gdc compiles that sounds like a packaging problem. Or use of 
outdated D? ldc is generally much more up to date that gdc so 
shouldn't the order be ldc | gdc | d-compiler?


I didn't get it to compile properly with LDC, which might of 
course have been due to the outdated LDC version in Debian and 
Ubuntu at that time.
Also, GDC is available for more architectures and wasn't stuck in 
unstable at the time dub was packaged.


On Debian Sid ldc2 is 2.068.2 and gdc doesn't advertise which 
version of D it is.


Should be D2, there doesn't seem to be much D1 code around 
anymore...


I assume that the DMD package from dlang, or better d-apt, sets 
the d- compiler property. Should dmd be prefered if it is 
present?


I think so, since when installing it from non-free 3rd-party 
sources, the user made an explicit choice for DMD.
In terms of packaging, the packaging doesn't really care, any D 
compiler will satisfy the requirements of the dub package.


> And has dub's config been tweaked accordingly in terms of 
> which compiler it prefers to use ... ?
I didn't touch that, since dub seems to automatically find the 
right compiler. The preference seems to be dmd >> gdc >> ldc2, 
which looks sane to me.


Sane, yes, but dmd → ldc2 → gdc is probably a better choice 
simply because ldc tends to be more up to date than gdc – this 
is not a maintainer problem just a release flow problem.


I can't comment on that... In any case, users and packagers can 
choose whatever D compiler they prefer, there is no "enforcement" 
of any kind happening (just default choices).


It's really bad that GDC isn't part of the official GCC yet, 
and the standard libraries differ so much between the 
compilers (mainly due to phobos progressing very quickly).


GDC is definitely ipart of the GCC thanks to Iain's ongoing 
efforts, with support from others. GDC would not be in the 
Debian repository if it wasn't part of GCC.


That's unfortunately not the case. If you download 
gcc-5_5.3.1.orig.tar.gz from 
https://packages.debian.org/source/sid/gcc-5 , you can see that 
GDC was manually inserted. I think the problem might lie in the 
GDC frontend code not being subjected to the FSF CLA, but that's 
just a guess - Iain likely knows more :)


The problem here is that the Fedora GCC packagers package 
GCC-Go but do not package GDC. This means GDC is not present in 
any of Fedora, CentOS, RHEL, Scientific Linux.


The last on this list is more important than you might think.


Coming from a scientific background, I am with you on this... 
Problem again is that gccgo is part of GCC, so you just need to 
enable it, while gdc is out-of-tree.


Also the ldc package in Rawhide is only 0.16.1 which is really 
rather ancient.


Jup - to be honest, I think the state of the free compilers in 
Linux distributions is really something which is limiting D the 
most at time.
New programming languages like Rust have it much easier in that 
regard.



For Debian Stretch I assume the situation will be much better
though :-) (given the state of the LDC and GDC Git repos).


I think the policy simply has to be to make sure that LDC and 
GDC are as up to date as possible in Sid ­– which already 
happens


Jup - ideally, the Debian D team would give some advice on 
default compilers and versions. But that team seems to be dead.


– and in Fedora Rawhide – which no-one but me seems to think is 
important.


Ideally find a Fedora developer (who ideally also works on RHEL) 
and convince him. The easiest way to get the compiler in would be 
a killer application written in D which requires an up-to-date 
toolchain. E.g. Docker is written in Go, many people want Docker, 
so Go is up-to-date (that's over-simplified, but it generally 
works that way...).


Cheers,
Matthias

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Tuesday, 12 April 2016 at 02:42:09 UTC, jmh530 wrote:

On Monday, 11 April 2016 at 14:21:46 UTC, Matthias Klumpp wrote:


On the roadmap are adding debhelper sequences to simplify 
packaging dub-based D code in Debian based distros, auto-test 
support in Debian's CI, and of course the usual bugfixing.




Is adding to Linux Mint something you would consider as well?


That's up to the Mint people, I only can speak for Debian and to 
a limited degree for Ubuntu.
Since Mint bases on Ubuntu LTS releases, it is pretty certain 
though that this will be available via the Ubuntu Xenial sources.

Re: Official dub packages for Debian and Ubuntu

[jmh530 via Digitalmars-d-announce]

On Monday, 11 April 2016 at 14:21:46 UTC, Matthias Klumpp wrote:


On the roadmap are adding debhelper sequences to simplify 
packaging dub-based D code in Debian based distros, auto-test 
support in Debian's CI, and of course the usual bugfixing.




Is adding to Linux Mint something you would consider as well?

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Monday, 11 April 2016 at 21:58:55 UTC, Joseph Rushton Wakeling 
wrote:

On Monday, 11 April 2016 at 14:21:46 UTC, Matthias Klumpp wrote:
As part of that work, the dub package an build management 
system is now available in Debian, and I will ensure it works 
well.
Additionally, it was possible to make dub available late in 
the Ubuntu 16.04 (Xenial) development cycle, so dub will also 
be part of the upcoming LTS release of Ubuntu (kudos here go 
to Matthias Klose for pointing me at the "new" --push-state 
linker directive to work around dub not linking properly 
against libcurl when the latter is compiled with --as-needed).


That's great news.  Thank you very much!

Related note: I see the lcd version in xenial is 0.17.0~beta2 
-- I don't suppose there's any chance of upgrading that to the 
stable 0.17.1 release ... ?  (Not asking you to do it 
personally, just wondering if that's something that could be 
achieved.)


I can ask, but given that the Xenial final freeze is on 24. April 
(release on 26.) and changing compiler versions that late in the 
cycle is potentially dangerous, I guess there is only a slim 
chance of success... On the pro-side is that having a beta 
compiler in the LTS release is undesirable, but even then I need 
to find an Ubuntu developer who does have time to do the sync and 
get the feature-freeze-exception. LDC FTBFSing on armel in Debian 
(and not entering testing due to that at time) is also an issue 
:-/


On the roadmap are adding debhelper sequences to simplify 
packaging dub-based D code in Debian based distros, auto-test 
support in Debian's CI, and of course the usual bugfixing.


That sounds very cool.  I'm very grateful that you are doing 
this work; it's going to save me my usual from-source install, 
and looks like it opens the gates for a bunch more D code 
getting into the Debian + Ubuntu universe.


Yes, that's the plan - for this to happen, we need some additions 
to dub though, to search in common global paths for packages. I 
opened bug 
https://github.com/D-Programming-Language/dub/issues/811 for 
that. Until that's fixed, I can't package more D code using dub 
(and adding debhelper bits also depends on this being resolved).


Curious question: what's the Debian policy these days on what D 
compiler should be used to build D packages?


There is no real policy, at least I have found none. But from my 
tests, ldc simply crashed right away when trying to compile, 
later it wasn't able to process some code gdc had no problems 
with (I haven't tried the upcoming release). Since the GNU 
Compiler Collection is Debian's default compiler, I have set the 
compiler dependency of dub to gdc | ldc | d-compiler, so gdc is 
preferred, but replacing it with any other compiler will work too.


And has dub's config been tweaked accordingly in terms of which 
compiler it prefers to use ... ?


I didn't touch that, since dub seems to automatically find the 
right compiler. The preference seems to be dmd >> gdc >> ldc2, 
which looks sane to me.


It's really bad that GDC isn't part of the official GCC yet, and 
the standard libraries differ so much between the compilers 
(mainly due to phobos progressing very quickly).


For Debian Stretch I assume the situation will be much better 
though :-) (given the state of the LDC and GDC Git repos).

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Monday, 11 April 2016 at 18:05:31 UTC, Jordi Sayol wrote:

[...]

Well, this makes useful have dub in both repositories, 
Debian/Ubuntu and d-apt. All Debian/Ubuntu users can always use 
dub on their system. If the last release is needed for any 
reason they can add d-apt repository to install it. d-apt takes 
1-2 day to update dub deb packages after dub release. The deb 
package is not a problem because we use the same package name, 
and the version shouldn't be a problem too, the newer version 
will be installed regardless its source, isn't it?


Yes.

$ dpkg --compare-versions "0.9.25-0" gt "0.9.24-1ubuntu1" && 
echo "greater" || echo "NOT greater"


As long as you keep the Debian revision at 0, everything is fine 
and there should be no conflicts, if the binary package names in 
Debian and your repo match. Please just don't increase the Debian 
revision to something bigger than zero, that can result in 
breakage.
You could use a revision like "-0~1" or "-0.1" when making 
changes to the package without a new upstream releases.
But that seems to be the case already, so there's no problem here 
:-)

Re: Official dub packages for Debian and Ubuntu

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 11 April 2016 at 14:21:46 UTC, Matthias Klumpp wrote:
As part of that work, the dub package an build management 
system is now available in Debian, and I will ensure it works 
well.
Additionally, it was possible to make dub available late in the 
Ubuntu 16.04 (Xenial) development cycle, so dub will also be 
part of the upcoming LTS release of Ubuntu (kudos here go to 
Matthias Klose for pointing me at the "new" --push-state linker 
directive to work around dub not linking properly against 
libcurl when the latter is compiled with --as-needed).


That's great news.  Thank you very much!

Related note: I see the lcd version in xenial is 0.17.0~beta2 -- 
I don't suppose there's any chance of upgrading that to the 
stable 0.17.1 release ... ?  (Not asking you to do it personally, 
just wondering if that's something that could be achieved.)



On the roadmap are adding debhelper sequences to simplify 
packaging dub-based D code in Debian based distros, auto-test 
support in Debian's CI, and of course the usual bugfixing.


That sounds very cool.  I'm very grateful that you are doing this 
work; it's going to save me my usual from-source install, and 
looks like it opens the gates for a bunch more D code getting 
into the Debian + Ubuntu universe.


Curious question: what's the Debian policy these days on what D 
compiler should be used to build D packages?  And has dub's 
config been tweaked accordingly in terms of which compiler it 
prefers to use ... ?


Thanks & best wishes,

-- Joe

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Monday, 11 April 2016 at 17:41:44 UTC, Matthias Klumpp wrote:

[...]
Eww, that's not something we can do for official packages - 
it's fine though for 3rd-party stuff :-)


"can not do", obviously... :P

Re: Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Monday, 11 April 2016 at 14:26:32 UTC, Edwin van Leeuwen wrote:

On Monday, 11 April 2016 at 14:21:46 UTC, Matthias Klumpp wrote:
And porting Python code to D was incredibly easy. I'll likely 
blog about my experience with D).


That would be great. Do you have a link to your blog (and its 
rss feed)?


That would be http://blog.tenstral.net/ and 
http://blog.tenstral.net/feed - no D content there yet though, 
lots of Freedesktop and distro engineering stuff instead ^^


As part of that work, the dub package an build management 
system is now available in Debian, and I will ensure it works 
well.


Nice, that will make it a lot easier, for people that are not 
using D, to install D programs/packages


Jup - the biggest issue is that GDC and LDC are lagging behind 
the proprietary DMD compiler, especially in terms of supporting a 
more recent Phobos version. The latter makes many things 
buildable only with DMD, which won't be found in any mainstream 
Linux distribution (no free software).


On Monday, 11 April 2016 at 17:18:28 UTC, Jordi Sayol wrote:
El 11/04/16 a les 16:21, Matthias Klumpp via 
Digitalmars-d-announce ha escrit:

[...]
Co-maintainers[1] and feedback from the dub developers is very 
welcome, and I hope this addition is useful for you.

[...]
[1]: Especially from the d-apt people - helping with official 
Debian packages is possible even if you're no Debian Developer 
/ Maintainer.


I'm the only one d-apt maintainer.

About the d-apt dub deb package, they're built using binaries 
from  and do not compile 
anything.


Eww, that's not something we can do for official packages - it's 
fine though for 3rd-party stuff :-)


How long will it take from a dub release until dub deb package 
will be available on the Debian stable repositories? And for 
Ubuntu?


Depends on the release cycle of Debian and Ubuntu. Generally, 
once software is in stable, it will only receive security fixes, 
and no further upstream versions will be added. That is part of 
the stability promise we give to users. Every new upstream 
release might include changes in behavior, breaking things or 
introducing new bugs.


That being said, new upstream releases can be made available via 
backports, if there is demand for it (it's relatively easy, if 
the code compiles with the older GDC release in stable at that 
time).


The Ubuntu Xenial (16.04) release (due in April) will have dub 
0.9.24, and Debian Stretch (9), which will likely be released in 
spring next year, will have whatever dub version is current then 
(or if the dub developers prefer a certain version for stable, 
that version).


Cheers,
  Matthias

Re: Official dub packages for Debian and Ubuntu

[Jordi Sayol via Digitalmars-d-announce]

El 11/04/16 a les 16:21, Matthias Klumpp via Digitalmars-d-announce ha escrit:
> As part of that work, the dub package an build management system is now 
> available in Debian, and I will ensure it works well.
> Additionally, it was possible to make dub available late in the Ubuntu 16.04 
> (Xenial) development cycle, so dub will also be part of the upcoming LTS 
> release of Ubuntu

This is a very good news!

> Co-maintainers[1] and feedback from the dub developers is very welcome, and I 
> hope this addition is useful for you.
[...]
> [1]: Especially from the d-apt people - helping with official Debian packages 
> is possible even if you're no Debian Developer / Maintainer. 

I'm the only one d-apt maintainer. 

About the d-apt dub deb package, they're built using binaries from 
 and do not compile anything.

How long will it take from a dub release until dub deb package will be 
available on the Debian stable repositories? And for Ubuntu?

Regards,
Jordi.

Re: Official dub packages for Debian and Ubuntu

[Edwin van Leeuwen via Digitalmars-d-announce]

On Monday, 11 April 2016 at 14:21:46 UTC, Matthias Klumpp wrote:
And porting Python code to D was incredibly easy. I'll likely 
blog about my experience with D).


That would be great. Do you have a link to your blog (and its rss 
feed)?


As part of that work, the dub package an build management 
system is now available in Debian, and I will ensure it works 
well.


Nice, that will make it a lot easier, for people that are not 
using D, to install D programs/packages