On 26 September 2012 16:46, David Nadlinger <see@klickverbot.at> wrote:
> On Friday, 21 September 2012 at 19:59:36 UTC, Joseph Rushton Wakeling wrote:
>>
>> I'd add here that you're talking about by far the most widely used distro.
>> […]
>> Isn't it worth someone from the LDC team discussing with the Ubuntu people
>> concerned (e.g. the person who decided to blacklist the package) and try and
>> get their feedback and advice on packaging?  My experience is that the
>> Ubuntu team are fairly friendly and helpful.
>
>
> I don't doubt that distro packages are vital for providing a smooth experience for Linux users. However, and this is unfortunately a big "however", at the same time I don't think I will be able to look into providing those packages myself any time soon (besides for Arch, but that front is already covered; big thanks to Sven/svenstaro!), simply because I'm happy if I find enough time to look into any LDC issues whatsoever at all right now.
>
> Joseph, Russel, you seem to be both personally interested in D/LDC and quite knowledgeable about Debian-style packaging. Might I suggest that you think about joining the LDC forces as a package maintainer? It certainly isn't a huge amount of work to do, but many small items also add up…
>
> Thanks,
> David


Was it Mattias or Arthur who was the last maintainer?  I could probably pull some strings with them to pass it down to a more active / willing maintainer.  Heck, I don't mind putting my name down as the package maintainer.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Wed, Sep 26, 2012 at 06:11:08PM +0100, Iain Buclaw wrote:
> On 26 September 2012 16:46, David Nadlinger <see@klickverbot.at> wrote:
[...]
> > Joseph, Russel, you seem to be both personally interested in D/LDC and quite knowledgeable about Debian-style packaging. Might I suggest that you think about joining the LDC forces as a package maintainer? It certainly isn't a huge amount of work to do, but many small items also add up…
> >
> > Thanks,
> > David
> 
> 
> Was it Mattias or Arthur who was the last maintainer?  I could probably pull some strings with them to pass it down to a more active / willing maintainer.  Heck, I don't mind putting my name down as the package maintainer.
[...]

I'm willing to sponsor uploads. I just don't have the time/patience to play around with LDC (or GDC) packaging right now.


T

-- 
I am Ohm of Borg. Resistance is voltage over current.

On Wed, 26 Sep 2012, Iain Buclaw wrote:
> On 26 September 2012 16:46, David Nadlinger <see@klickverbot.at> wrote:
> > On Friday, 21 September 2012 at 19:59:36 UTC, Joseph Rushton Wakeling wrote:
> >>
> >> I'd add here that you're talking about by far the most widely used distro.
> >> [?]
> >> Isn't it worth someone from the LDC team discussing with the Ubuntu people
> >> concerned (e.g. the person who decided to blacklist the package) and try and
> >> get their feedback and advice on packaging?  My experience is that the
> >> Ubuntu team are fairly friendly and helpful.
> >
> >
> > I don't doubt that distro packages are vital for providing a smooth experience for Linux users. However, and this is unfortunately a big "however", at the same time I don't think I will be able to look into providing those packages myself any time soon (besides for Arch, but that front is already covered; big thanks to Sven/svenstaro!), simply because I'm happy if I find enough time to look into any LDC issues whatsoever at all right now.
> >
> > Joseph, Russel, you seem to be both personally interested in D/LDC and quite knowledgeable about Debian-style packaging. Might I suggest that you think about joining the LDC forces as a package maintainer? It certainly isn't a huge amount of work to do, but many small items also add up?
> >
> > Thanks,
> > David
> 
> 
> Was it Mattias or Arthur who was the last maintainer?  I could probably pull some strings with them to pass it down to a more active / willing maintainer.  Heck, I don't mind putting my name down as the package maintainer.
> 
> 
> Regards
> -- 
> Iain Buclaw
> 
> *(p < e ? p++ : p) = (c & 0x0f) + '0';

I have on my personal todo list a few major items (among many others):

1) add support for multiple projects (dmd2 being the only one currently)
2) add packaging of built artifacts for master builds
3) add uploading of packaged builds to github
4) on-demand builds of specific tags -- intended for release builds

I have made some of the internal cleanups to the build server to prepare for #1, but there's still a lot to do, though mostly in the administrative interfaces, not _that_ much on the get things to run a build side.

It's been my intent to use gdc and/or ldc as the first examples of non-dmd projects supported by the auto-tester.

The result of the above features would be that releases would be fully automated, at least from the point of tag creation through uploaded and publically available packages.

I don't know what's involved in getting built-packages into the various distributions.  I suspect that a number of them prefer to be built by their own automation from original (or forked) sources.  I'd be happy to engage with the appropriate people to explore ways to work together in this space.

No promises on any delivery dates, but work is in progress.

Thoughts?

Later,
Brad

On Wed, Sep 26, 2012 at 05:58:08PM -0700, Brad Roberts wrote: [...]
> I don't know what's involved in getting built-packages into the various distributions.  I suspect that a number of them prefer to be built by their own automation from original (or forked) sources.  I'd be happy to engage with the appropriate people to explore ways to work together in this space.
[...]

For Debian, the process is relatively simple:

1) Create a debian/ subdir in the source tree, with appropriate
   control files (for existing packages, this has already been done)
   a) Update debian/changelog to reflect the new version number.
   b) Adjust any necessary dependencies, etc., in debian/control.

2) Build the package by running 'dpkg-buildpackage ...' in the source
   tree. This creates a bunch of files (including the binary .deb) in
   the parent directory.

3) [Optional] Preferably, test the .deb to make sure it doesn't cause
   massive system breakage.

4) Upload the generated package files in the parent directory by the
   build process, either by sending it to a sponsor or uploading it
   directly to the upload queue if you have upload access. The dupload
   script automatically determines which file(s) should be uploaded.

Once the package is uploaded successfully, the autobuilder infrastructure can be used to build the package for the umpteen architectures that Debian supports.

IIRC, once the package gets into the Debian archive it will eventually find its way into Ubuntu (and possibly the other Debian derivatives).


T

-- 
VI = Visual Irritation

On Wed, 26 Sep 2012, H. S. Teoh wrote:

> On Wed, Sep 26, 2012 at 05:58:08PM -0700, Brad Roberts wrote: [...]
> > I don't know what's involved in getting built-packages into the various distributions.  I suspect that a number of them prefer to be built by their own automation from original (or forked) sources.  I'd be happy to engage with the appropriate people to explore ways to work together in this space.
> [...]
> 
> For Debian, the process is relatively simple:
> 
> 1) Create a debian/ subdir in the source tree, with appropriate
>    control files (for existing packages, this has already been done)
>    a) Update debian/changelog to reflect the new version number.
>    b) Adjust any necessary dependencies, etc., in debian/control.
> 
> 2) Build the package by running 'dpkg-buildpackage ...' in the source
>    tree. This creates a bunch of files (including the binary .deb) in
>    the parent directory.
> 
> 3) [Optional] Preferably, test the .deb to make sure it doesn't cause
>    massive system breakage.
> 
> 4) Upload the generated package files in the parent directory by the
>    build process, either by sending it to a sponsor or uploading it
>    directly to the upload queue if you have upload access. The dupload
>    script automatically determines which file(s) should be uploaded.
> 
> Once the package is uploaded successfully, the autobuilder infrastructure can be used to build the package for the umpteen architectures that Debian supports.
> 
> IIRC, once the package gets into the Debian archive it will eventually find its way into Ubuntu (and possibly the other Debian derivatives).

That works well for packages which are single source tree.  The current dmd, druntime, phobos, d-programming-language, tools separation makes that a little more challenging to put together, but not a lot.  It's probably worth doing regardless.  I realize that gdc and ldc are both in better shape in this area already.

#4 there implies it's a source package, though I could be mis-interpreting you.  Is there a path for externally built binary packages?  That's fairly counter to the general distribution philosophy for most of them, so I'm giong to guess no.

Thanks,
Brad

On 27 September 2012 03:14, Brad Roberts <braddr@puremagic.com> wrote:
> On Wed, 26 Sep 2012, H. S. Teoh wrote:
>
>> On Wed, Sep 26, 2012 at 05:58:08PM -0700, Brad Roberts wrote: [...]
>> > I don't know what's involved in getting built-packages into the various distributions.  I suspect that a number of them prefer to be built by their own automation from original (or forked) sources.  I'd be happy to engage with the appropriate people to explore ways to work together in this space.
>> [...]
>>
>> For Debian, the process is relatively simple:
>>
>> 1) Create a debian/ subdir in the source tree, with appropriate
>>    control files (for existing packages, this has already been done)
>>    a) Update debian/changelog to reflect the new version number.
>>    b) Adjust any necessary dependencies, etc., in debian/control.
>>
>> 2) Build the package by running 'dpkg-buildpackage ...' in the source
>>    tree. This creates a bunch of files (including the binary .deb) in
>>    the parent directory.
>>
>> 3) [Optional] Preferably, test the .deb to make sure it doesn't cause
>>    massive system breakage.
>>
>> 4) Upload the generated package files in the parent directory by the
>>    build process, either by sending it to a sponsor or uploading it
>>    directly to the upload queue if you have upload access. The dupload
>>    script automatically determines which file(s) should be uploaded.
>>
>> Once the package is uploaded successfully, the autobuilder infrastructure can be used to build the package for the umpteen architectures that Debian supports.
>>
>> IIRC, once the package gets into the Debian archive it will eventually find its way into Ubuntu (and possibly the other Debian derivatives).
>
> That works well for packages which are single source tree.  The current dmd, druntime, phobos, d-programming-language, tools separation makes that a little more challenging to put together, but not a lot.  It's probably worth doing regardless.  I realize that gdc and ldc are both in better shape in this area already.
>
> #4 there implies it's a source package, though I could be mis-interpreting you.  Is there a path for externally built binary packages?  That's fairly counter to the general distribution philosophy for most of them, so I'm giong to guess no.
>
> Thanks,
> Brad

For #4, yes.  Ubuntu is a better platform to approach for externally built binary-only packages.  But for debian, you could possibly do something similar to how eg: the flash-plugin installer package works - downloads the tar.gz/zip from an external site, extract and install / configure in system.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 9/27/2012 12:02 AM, Iain Buclaw wrote:
> On 27 September 2012 03:14, Brad Roberts <braddr@puremagic.com> wrote:
>>
>> #4 there implies it's a source package, though I could be mis-interpreting you.  Is there a path for externally built binary packages?  That's fairly counter to the general distribution philosophy for most of them, so I'm giong to guess no.
>>
> 
> For #4, yes.  Ubuntu is a better platform to approach for externally built binary-only packages.  But for debian, you could possibly do something similar to how eg: the flash-plugin installer package works - downloads the tar.gz/zip from an external site, extract and install / configure in system.

On reflection, #4 is not going to work for dmd.. neither ubuntu nor debian, nor most distributions are going to be happy with the license situation.  Nor are they happy with binary only packages anyway.  The right path is to do #4 but only for use on the dlang.org site (hosted via github's downloads api).  Then, add step #5 which is to automate source bundling and pushing to distributions.

Focusing back on gdc, what do you currently have in the way of build/test infrastructure today?  I poked around the website and wiki and didn't see anything obvious (not that the dmd side is terribly obvious either).  If you want to take this offline, feel free to send me mail directly.

- Brad

On 2012-09-27 09:02, Iain Buclaw wrote:

> For #4, yes.  Ubuntu is a better platform to approach for externally
> built binary-only packages.  But for debian, you could possibly do
> something similar to how eg: the flash-plugin installer package works
> - downloads the tar.gz/zip from an external site, extract and install
> / configure in system.

Sorry for hijacking this thread a bit but it would be nice with pre-built binaries of both ldc and gdc. I'm planning to add ldc and gdc to DVM sometime in the future.

-- 
/Jacob Carlborg

On 27/09/12 09:20, Brad Roberts wrote:
> On reflection, #4 is not going to work for dmd.. neither ubuntu nor debian, nor most distributions are going to be happy
> with the license situation.

Would Debian have a problem with a dmd package in non-free?  Would Ubuntu have a problem with it in the multiverse or partner repositories?

On 26/09/12 17:46, David Nadlinger wrote:
> Joseph, Russel, you seem to be both personally interested in D/LDC and quite
> knowledgeable about Debian-style packaging. Might I suggest that you think about
> joining the LDC forces as a package maintainer? It certainly isn't a huge amount
> of work to do, but many small items also add up…

I'd love to, but it would be irresponsible to commit to it as (right now especially) I don't have a very good idea of what time I'll be able to offer.

I also managed to royally screw up when going through beginners' packaging instructions for Ubuntu, so I'm not sure I'm the best choice here ... :-\