[Pkg-d-devel] Process for adding dinotify and unit-threaded

[Matthias Klumpp]

2017-11-24 10:25 GMT+01:00 Russel Winder <russel at winder.org.uk>:
> On Thu, 2017-11-23 at 20:02 +0100, Matthias Klumpp wrote:
> […]
>> Absolutely! It just needs someone to do the packaging work and to
>> maintain the packages (that is, update to newer versions and fix
>> bugs).
>
> If someone can induct me into the Correct Way™ of doing packaging
> within the pkg-d-devel context, I can set some stuff up and ensure it
> all works.

I can help with that :-) If you are using Meson, there isn't much you
can do wrong. SCons is a bit trickier, but also not hard at all (I do
hope that that D bug gets fixed to make unit-threaded also work with
Meson).
Do you have any (Debian) packaging experience?
Looking at the packaging for gir-to-d might be a good starting point,
because it's pretty simple:
https://anonscm.debian.org/git/pkg-d/gir-to-d.git/tree/debian

> However, I do not have the signatures on my PGP keys to
> qualify as a Debian Maintainer. So someone else would have to do the
> final bit.

That's not an issue. Becoming DM would obviously be the goal here,
because that grants you the ability to upload a selected amount of
packages. However meanwhile I can sponsor changes for you (which means
you would check in changes in Git, ping me when you want an upload to
happen and then I take a look at the changes and upload the package).

> […]
>> tl;dr: We need package maintainers for D stuff! If you are interested
>> in doing the packaging work, I could review & sponsor packages, and
>> we
>> could also give access to the Debian D Team Git repository (although
>> I
>> need to research how that works now with Debian switching to Gitlab
>> for packaging).
>
> I have a GitLab account. I am surprised at Debian switching to that but
> maybe they can no longer sustain their own infrastructure, and so are
> happy with the indirect sponsorship from GitLab.

Well, we will always have our own infrastructure, Gitlab means the
software here, not the service provided by the Gitlab company. Using
Gitlab was ultimately a decision made by our sysadmins.

> For Debian is GitLab a better resource than GitHub?

GitHub is non-free software, and therefore a no-go for Debian.

>> The benefit of having more D code in Debian is that D becomes a lot
>> more visible in the community, and D compilers get much better
>> supported in general in the distribution (and it apparently also
>> means
>> we find tons of bugs in LDC and LLVM, at the moment
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879040 is still
>> unresolved).
>
> With the licence change, perhaps now is the time to push for DMD
> getting into Debian to join LDC and GDC? Making D-Apt redundant ought
> to be a goal. :-)

Yes, having DMD would actually be possible now in Debian. I assume a
DMD package will be more advanced though and not as straightforward as
a packaging a library.

Also, there is the question of which compiler we use by default for D
packages in Debian. At the moment that is LDC, and at some point might
be GDC even (depends on how it evolves). Reason for that is that we do
want the optimizations LDC/GDC provide over DMD, and since we have
plenty of build power, buildtimes don't matter at all.
We still should have DMD in the archive though - we'd just need
someone to maintain the package ;-)

It looks like the new infrastructure on salsa.debian.org isn't ready
yet, so we can use the existing infrastructure for now. Just create an
account at https://alioth.debian.org/ and request to be added to the D
team: https://alioth.debian.org/projects/pkg-d/ (there should be a
button for that somewhere).

That is a prerequisite to give you access to the D-team Git repository
at https://anonscm.debian.org/git/pkg-d/
How to build packages with git-buildpackage might also be interesting
to you (https://wiki.debian.org/PackagingWithGit has a bit of
information, but there are a lot of different styles on how to layout
the Git repository, so don't get confused by that).


Cheers,
    Matthias

-- 
I welcome VSRE emails. See http://vsre.info/