www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Official dub packages for Debian and Ubuntu

reply Matthias Klumpp <matthias tenstral.net> writes:
Hello!
I am very new to the D community and just recently finished a 
project in D, which I want to make available in Debian (reason 
for choosing D was mostly its speed and similarity to C++ and C, 
making a very shallow learning curve for someone knowing these 
languages. And porting Python code to D was incredibly easy. I'll 
likely blog about my experience with D).

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

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

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.

Cheers,
     Matthias

https://packages.debian.org/stretch/dub
http://packages.ubuntu.com/xenial/dub

[1]: Especially from the d-apt people - helping with official 
Debian packages is possible even if you're no Debian Developer / 
Maintainer.
Apr 11 2016
next sibling parent Edwin van Leeuwen <edder tkwsping.nl> writes:
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
Apr 11 2016
prev sibling next sibling parent reply Jordi Sayol via Digitalmars-d-announce writes:
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
<https://code.dlang.org/download> 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.
Apr 11 2016
parent reply Matthias Klumpp <matthias tenstral.net> writes:
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 <https://code.dlang.org/download> 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
Apr 11 2016
next sibling parent Matthias Klumpp <matthias tenstral.net> writes:
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
Apr 11 2016
prev sibling parent reply Jordi Sayol via Digitalmars-d-announce writes:
El 11/04/16 a les 19:41, Matthias Klumpp via Digitalmars-d-announce ha escrit:

 About the d-apt dub deb package, they're built using binaries from
<https://code.dlang.org/download> and do not compile anything.


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


I know it. This is the reason of my comment :-)



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



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?

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

Regards,
Jordi
Apr 11 2016
parent Matthias Klumpp <matthias tenstral.net> writes:
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 
:-)
Apr 11 2016
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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
Apr 11 2016
parent reply Matthias Klumpp <matthias tenstral.net> writes:
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).
Apr 11 2016
next sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Tue, 2016-04-12 at 01:58 +0000, Matthias Klumpp via Digitalmars-d-
announce wrote:

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

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

=20






[=E2=80=A6]


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


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


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?

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

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?


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


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


Sane, yes, but dmd =E2=86=92 ldc2 =E2=86=92 gdc is probably a better choice=
 simply
because ldc tends to be more up to date than gdc =E2=80=93 this is not a
maintainer problem just a release flow problem.


 It's really bad that GDC isn't part of the official GCC yet, and=C2=A0
 the standard libraries differ so much between the compilers=C2=A0
 (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.

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.=C2=A0

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


 For Debian Stretch I assume the situation will be much better=C2=A0
 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 =C2=AD=E2=80=93 which already happens =E2=
=80=93 and in
Fedora Rawhide =E2=80=93 which no-one but me seems to think is important.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 12 2016
parent reply Matthias Klumpp <matthias tenstral.net> writes:
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
Apr 12 2016
parent reply Jordi Sayol via Digitalmars-d-announce writes:
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?
Apr 12 2016
parent reply Matthias Klumpp <matthias tenstral.net> writes:
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.
Apr 14 2016
parent reply Jordi Sayol via Digitalmars-d-announce writes:
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?
Apr 14 2016
parent reply Matthias Klumpp <matthias tenstral.net> writes:
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").
Apr 14 2016
parent reply Jordi Sayol via Digitalmars-d-announce writes:
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!
Apr 15 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 15 2016
next sibling parent Jordi Sayol via Digitalmars-d-announce writes:
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.
Apr 15 2016
prev sibling parent Russel Winder via Digitalmars-d-announce writes:
On Fri, 2016-04-15 at 20:03 +0200, Jordi Sayol via Digitalmars-d-
announce wrote:

=C2=A0[=E2=80=A6]
 Many thanks Andrei, and all d-apt users.


Thanks for creating and running D-Apt =E2=80=93 all it's users a A-D-Apt-ab=
le.
;-)


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.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 16 2016
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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!
Apr 12 2016
next sibling parent reply Matthias Klumpp <matthias tenstral.net> writes:
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!


:-)
Apr 14 2016
parent reply Matthias Klumpp <matthias tenstral.net> writes:
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
Apr 14 2016
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 14 Apr 2016 16:29:31 +0000
schrieb Matthias Klumpp <matthias tenstral.net>:


 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).
Apr 14 2016
parent reply Matthias Klumpp <matthias tenstral.net> writes:
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).
Apr 14 2016
parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 14 Apr 2016 23:16:49 +0000
schrieb Matthias Klumpp <matthias tenstral.net>:


 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...
Apr 15 2016
parent Matthias Klumpp <matthias tenstral.net> writes:
On Friday, 15 April 2016 at 09:15:05 UTC, Johannes Pfau wrote:

 Am Thu, 14 Apr 2016 23:16:49 +0000
 schrieb Matthias Klumpp <matthias tenstral.net>:


 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!
Apr 16 2016
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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.
Apr 16 2016
parent Matthias Klumpp <matthias tenstral.net> writes:
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/<package>`[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/`)
Apr 16 2016
prev sibling parent reply Matthias Klumpp <matthias tenstral.net> writes:
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 <markos debian.org> about it.
Alternatively, I can also report a bug against LDC (need to find 
time for that, maybe tomorrow).

Cheers,
     Matthias
Apr 18 2016
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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 <markos debian.org> 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.
Apr 18 2016
parent reply Matthias Klumpp <matthias tenstral.net> writes:
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 <markos debian.org> 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.
Apr 18 2016
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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 :-)
Apr 21 2016
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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!
Apr 21 2016
parent Matthias Klumpp <matthias tenstral.net> writes:
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 ;-)
Apr 24 2016
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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?
Apr 11 2016
parent Matthias Klumpp <matthias tenstral.net> writes:
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.
Apr 12 2016