[pacman-dev] [PATCH 0/6] VCS versioning modifications
From: Matthew Monaco
From: Matthew Monaco
On 13/03/12 04:53, dgbaley27@0x01b.net wrote:
From: Matthew Monaco
--- scripts/makepkg.sh.in | 1 - 1 file changed, 1 deletion(-)
Pulled to my patchqueue. Thanks, Allan
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 89cd118..05a611d 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1714,7 +1714,6 @@ devel_check() { # calls to makepkg via fakeroot will explicitly pass the version # number to avoid having to determine the version number twice. # Also do a check to make sure we have the VCS tool available. - oldpkgver=$pkgver if [[ -n ${_darcstrunk} && -n ${_darcsmod} ]] ; then if ! type -p darcs >/dev/null; then warning "$(gettext "Cannot find the %s binary required to determine latest %s revision.")" "darcs" "darcs"
From: Matthew Monaco
On Mon, Mar 12, 2012 at 12:53:11PM -0600, dgbaley27@0x01b.net wrote:
From: Matthew Monaco
Rather than prioritizing an arbitrary VCS, collect all development directives. If there is more than one, use the package name as a hint. If that doesn't work, abort. ---
I'm not really sure I understand the need for this. In what use case are multiple VCS definitions needed?
scripts/makepkg.sh.in | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 05a611d..1eb62ca 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1714,6 +1714,27 @@ devel_check() { # calls to makepkg via fakeroot will explicitly pass the version # number to avoid having to determine the version number twice. # Also do a check to make sure we have the VCS tool available. + local vcs=() + + [[ -n ${_darcstrunk} && -n ${_darcsmod} ]] && vcs+=("darcs") + [[ -n ${_cvsroot} && -n ${_cvsmod} ]] && vcs+=("cvs") + [[ -n ${_gitroot} && -n ${_gitname} ]] && vcs+=("git") + [[ -n ${_svntrunk} && -n ${_svnmod} ]] && vcs+=("svn") + [[ -n ${_bzrtrunk} && -n ${_bzrmod} ]] && vcs+=("bzr") + [[ -n ${_hgroot} && -n ${_hgrepo} ]] && vcs+=("hg") + + if [[ ${#vcs[@]} -eq 0 ]]; then
We generally use arithmetic contexts elsewhere for numeric comparison.
+ return + elif [[ ${#vcs[@]} -ge 2 ]]; then + local vcslen=${#vcs[@]} + vcs=(${vcs[@]/${pkgname##*-}/})
I think you're intentionally performing whitespace splitting here to avoid counting problems. Even if that isn't the reason, it's not kosher.
+ if [[ ${#vcs[@]} -eq $vcslen ]]; then + warning "$(gettext "Ambiguous VCS package. Cannot pick from: %s.")" "${vcs[*]}" + return 0 + fi + vcs=${pkgname##*-}
And after all that array business, vcs is now treated as a string. I appreciate bash's "dynamic" typing, but I rarely seek to abuse it.
+ fi + if [[ -n ${_darcstrunk} && -n ${_darcsmod} ]] ; then if ! type -p darcs >/dev/null; then warning "$(gettext "Cannot find the %s binary required to determine latest %s revision.")" "darcs" "darcs" -- 1.7.9.3
On 03/12/2012 01:13 PM, Dave Reisner wrote:
On Mon, Mar 12, 2012 at 12:53:11PM -0600, dgbaley27@0x01b.net wrote:
From: Matthew Monaco
Rather than prioritizing an arbitrary VCS, collect all development directives. If there is more than one, use the package name as a hint. If that doesn't work, abort. ---
I'm not really sure I understand the need for this. In what use case are multiple VCS definitions needed?
I've only seen multiples when a project is transitioning to a new system. Either way, I think that splitting the check for the which vcs is being used and setting the new version might be useful.
scripts/makepkg.sh.in | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 05a611d..1eb62ca 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1714,6 +1714,27 @@ devel_check() { # calls to makepkg via fakeroot will explicitly pass the version # number to avoid having to determine the version number twice. # Also do a check to make sure we have the VCS tool available. + local vcs=() + + [[ -n ${_darcstrunk} && -n ${_darcsmod} ]] && vcs+=("darcs") + [[ -n ${_cvsroot} && -n ${_cvsmod} ]] && vcs+=("cvs") + [[ -n ${_gitroot} && -n ${_gitname} ]] && vcs+=("git") + [[ -n ${_svntrunk} && -n ${_svnmod} ]] && vcs+=("svn") + [[ -n ${_bzrtrunk} && -n ${_bzrmod} ]] && vcs+=("bzr") + [[ -n ${_hgroot} && -n ${_hgrepo} ]] && vcs+=("hg") + + if [[ ${#vcs[@]} -eq 0 ]]; then
We generally use arithmetic contexts elsewhere for numeric comparison.
ok
+ return + elif [[ ${#vcs[@]} -ge 2 ]]; then + local vcslen=${#vcs[@]} + vcs=(${vcs[@]/${pkgname##*-}/})
I think you're intentionally performing whitespace splitting here to avoid counting problems. Even if that isn't the reason, it's not kosher.
it's a quick way to test if the -suffix matches the two _vcs variables. also, the potential list is confined to what is above and a vcs with a space in the name isn't likely.
+ if [[ ${#vcs[@]} -eq $vcslen ]]; then + warning "$(gettext "Ambiguous VCS package. Cannot pick from: %s.")" "${vcs[*]}" + return 0 + fi + vcs=${pkgname##*-}
And after all that array business, vcs is now treated as a string. I appreciate bash's "dynamic" typing, but I rarely seek to abuse it.
ok
+ fi + if [[ -n ${_darcstrunk} && -n ${_darcsmod} ]] ; then if ! type -p darcs >/dev/null; then warning "$(gettext "Cannot find the %s binary required to determine latest %s revision.")" "darcs" "darcs" -- 1.7.9.3
From: Matthew Monaco
On 13/03/12 06:37, dgbaley27@0x01b.net wrote:
From: Matthew Monaco
EDITS: - user arithmetic contexts for integer comparison - use the regex comparison operator to test array membership
Rather than prioritizing an arbitrary VCS, collect all development directives. If there is more than one, use the package name as a hint. If that doesn't work, abort. --- scripts/makepkg.sh.in | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 05a611d..55df323 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1714,6 +1714,25 @@ devel_check() { # calls to makepkg via fakeroot will explicitly pass the version # number to avoid having to determine the version number twice. # Also do a check to make sure we have the VCS tool available. + local vcs=() + + [[ -n ${_darcstrunk} && -n ${_darcsmod} ]] && vcs+=("darcs") + [[ -n ${_cvsroot} && -n ${_cvsmod} ]] && vcs+=("cvs") + [[ -n ${_gitroot} && -n ${_gitname} ]] && vcs+=("git") + [[ -n ${_svntrunk} && -n ${_svnmod} ]] && vcs+=("svn") + [[ -n ${_bzrtrunk} && -n ${_bzrmod} ]] && vcs+=("bzr") + [[ -n ${_hgroot} && -n ${_hgrepo} ]] && vcs+=("hg") + + if (( ${#vcs[@]} == 0 )); then + return + elif (( ${#vcs[@]} >= 2 )); then + if [[ ${vcs[@]} =~ "${pkgname##*-}" ]]; then
If you remove this check based on the package name, I will ack patches 2 to 4. Allan
On 13/03/12 05:22, Matthew Monaco wrote:
On 03/12/2012 01:13 PM, Dave Reisner wrote:
On Mon, Mar 12, 2012 at 12:53:11PM -0600, dgbaley27@0x01b.net wrote:
From: Matthew Monaco
Rather than prioritizing an arbitrary VCS, collect all development directives. If there is more than one, use the package name as a hint. If that doesn't work, abort. ---
I'm not really sure I understand the need for this. In what use case are multiple VCS definitions needed?
I've only seen multiples when a project is transitioning to a new system. Either way, I think that splitting the check for the which vcs is being used and setting the new version might be useful.
I do not understand this argument. I have never seen a project transitioning from one VCS to another in such a way that you had to use both VCS systems to get the source. If that happens, you probably have two different projects managed by the same people and should have two packages.
On 03/12/2012 04:56 PM, Allan McRae wrote:
On 13/03/12 05:22, Matthew Monaco wrote:
On 03/12/2012 01:13 PM, Dave Reisner wrote:
On Mon, Mar 12, 2012 at 12:53:11PM -0600, dgbaley27@0x01b.net wrote:
From: Matthew Monaco
Rather than prioritizing an arbitrary VCS, collect all development directives. If there is more than one, use the package name as a hint. If that doesn't work, abort. ---
I'm not really sure I understand the need for this. In what use case are multiple VCS definitions needed?
I've only seen multiples when a project is transitioning to a new system. Either way, I think that splitting the check for the which vcs is being used and setting the new version might be useful.
I do not understand this argument. I have never seen a project transitioning from one VCS to another in such a way that you had to use both VCS systems to get the source. If that happens, you probably have two different projects managed by the same people and should have two packages.
It wasn't the point of the change; just a potential scenario given when asked. I was in the function and figured Murphy's Law indicated at some point someone was going to do something funny. The real change that I'm after is that a package has to be named appropriately to get an automatic version bump by default.
From: Matthew Monaco
From: Matthew Monaco
On Mon, Mar 12, 2012 at 12:53:13PM -0600, dgbaley27@0x01b.net wrote:
From: Matthew Monaco
The case structure allows the syntax to focus on what's actually being done here. --- scripts/makepkg.sh.in | 61 +++++++++++++++++++++++++++---------------------- 1 file changed, 34 insertions(+), 27 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index c5259c9..d4798ca 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1742,34 +1742,41 @@ devel_check() {
msg "$(gettext "Determining latest %s revision...")" "$vcs"
- if [[ -n ${_darcstrunk} && -n ${_darcsmod} ]] ; then - newpkgver=$(date +%Y%m%d) - elif [[ -n ${_cvsroot} && -n ${_cvsmod} ]] ; then - newpkgver=$(date +%Y%m%d) - elif [[ -n ${_gitroot} && -n ${_gitname} ]] ; then - newpkgver=$(date +%Y%m%d) - elif [[ -n ${_svntrunk} && -n ${_svnmod} ]] ; then - newpkgver=$(LC_ALL=C svn info $_svntrunk | sed -n 's/^Last Changed Rev: \([0-9]*\)$/\1/p') - elif [[ -n ${_bzrtrunk} && -n ${_bzrmod} ]] ; then - newpkgver=$(bzr revno ${_bzrtrunk}) - elif [[ -n ${_hgroot} && -n ${_hgrepo} ]] ; then - if [[ -d ./src/$_hgrepo ]] ; then - cd ./src/$_hgrepo - local ret=0 - hg pull || ret=$? - if (( ! ret )); then - hg update - elif (( ret != 1 )); then - return 1 + case "$vcs" in + darcs) + newpkgver=$(date +%Y%m%d) + ;; + cvs) + newpkgver=$(date +%Y%m%d) + ;; + git) + newpkgver=$(date +%Y%m%d) + ;; + svn) + newpkgver=$(LC_ALL=C svn info $_svntrunk | sed -n 's/^Last Changed Rev: \([0-9]*\)$/\1/p') + ;; + bzr) + newpkgver=$(bzr revno ${_bzrtrunk}) + ;; + hg) + if [[ -d ./src/$_hgrepo ]] ; then + cd ./src/$_hgrepo
If we're going to be changing this, please use pushd/popd, quote properly, and check for errors.
+ local ret=0 + hg pull || ret=$? + if (( ! ret )); then + hg update + elif (( ret != 1 )); then + return 1 + fi + else + [[ ! -d ./src/ ]] && mkdir ./src/ + hg clone $_hgroot/$_hgrepo ./src/$_hgrepo + cd ./src/$_hgrepo fi - else - [[ ! -d ./src/ ]] && mkdir ./src/ - hg clone $_hgroot/$_hgrepo ./src/$_hgrepo - cd ./src/$_hgrepo - fi - newpkgver=$(hg tip --template "{rev}") - cd ../../ - fi + newpkgver=$(hg tip --template "{rev}") + cd ../../ + ;; + esac
if [[ -n $newpkgver ]]; then msg2 "$(gettext "Version found: %s")" "$newpkgver" -- 1.7.9.3
On 03/12/2012 01:19 PM, Dave Reisner wrote:
On Mon, Mar 12, 2012 at 12:53:13PM -0600, dgbaley27@0x01b.net wrote:
From: Matthew Monaco
The case structure allows the syntax to focus on what's actually being done here. --- scripts/makepkg.sh.in | 61 +++++++++++++++++++++++++++---------------------- 1 file changed, 34 insertions(+), 27 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index c5259c9..d4798ca 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1742,34 +1742,41 @@ devel_check() {
msg "$(gettext "Determining latest %s revision...")" "$vcs"
- if [[ -n ${_darcstrunk} && -n ${_darcsmod} ]] ; then - newpkgver=$(date +%Y%m%d) - elif [[ -n ${_cvsroot} && -n ${_cvsmod} ]] ; then - newpkgver=$(date +%Y%m%d) - elif [[ -n ${_gitroot} && -n ${_gitname} ]] ; then - newpkgver=$(date +%Y%m%d) - elif [[ -n ${_svntrunk} && -n ${_svnmod} ]] ; then - newpkgver=$(LC_ALL=C svn info $_svntrunk | sed -n 's/^Last Changed Rev: \([0-9]*\)$/\1/p') - elif [[ -n ${_bzrtrunk} && -n ${_bzrmod} ]] ; then - newpkgver=$(bzr revno ${_bzrtrunk}) - elif [[ -n ${_hgroot} && -n ${_hgrepo} ]] ; then - if [[ -d ./src/$_hgrepo ]] ; then - cd ./src/$_hgrepo - local ret=0 - hg pull || ret=$? - if (( ! ret )); then - hg update - elif (( ret != 1 )); then - return 1 + case "$vcs" in + darcs) + newpkgver=$(date +%Y%m%d) + ;; + cvs) + newpkgver=$(date +%Y%m%d) + ;; + git) + newpkgver=$(date +%Y%m%d) + ;; + svn) + newpkgver=$(LC_ALL=C svn info $_svntrunk | sed -n 's/^Last Changed Rev: \([0-9]*\)$/\1/p') + ;; + bzr) + newpkgver=$(bzr revno ${_bzrtrunk}) + ;; + hg) + if [[ -d ./src/$_hgrepo ]] ; then + cd ./src/$_hgrepo
If we're going to be changing this, please use pushd/popd, quote properly, and check for errors.
I can do this, but this set didn't touch any of the code that sets newpkgver.
+ local ret=0 + hg pull || ret=$? + if (( ! ret )); then + hg update + elif (( ret != 1 )); then + return 1 + fi + else + [[ ! -d ./src/ ]] && mkdir ./src/ + hg clone $_hgroot/$_hgrepo ./src/$_hgrepo + cd ./src/$_hgrepo fi - else - [[ ! -d ./src/ ]] && mkdir ./src/ - hg clone $_hgroot/$_hgrepo ./src/$_hgrepo - cd ./src/$_hgrepo - fi - newpkgver=$(hg tip --template "{rev}") - cd ../../ - fi + newpkgver=$(hg tip --template "{rev}") + cd ../../ + ;; + esac
if [[ -n $newpkgver ]]; then msg2 "$(gettext "Version found: %s")" "$newpkgver" -- 1.7.9.3
From: Matthew Monaco
On Mon, Mar 12, 2012 at 12:53:14PM -0600, dgbaley27@0x01b.net wrote:
From: Matthew Monaco
If the package's name does not end in -git/svn/etc, then don't touch the pkgver or pkgrel. This changes the current semantics of makepkg, but it shouldn't be too mind blowing.
And I strongly disagree... What's the point in holding the package version if you can't tell the VCS behind the source files to obey this arbitrary date (e.g. in the case of git)?
Currently in core/extra there are two vcs packages (svn) which use _svntrunk and _svnmod. They also use -svn in the pkgname so they won't be affected (mplayer-svn, seom-svn). In addition, vim uses the _hg directives but with a double underscore (presumably to avoid automatic versioning despite not being vim-git).
In community there are a few packages which use the vcs directives but do not have a -vcs name. Most of these appear to never want an automatic version number (blender, boinc, bti, cfml, go, lorcon, sfml).
The exceptions in community are: fusion-icon, ldc, notion, opencollada.
And in my opinion, these packages are wrong.
--- doc/PKGBUILD.5.txt | 3 ++- scripts/makepkg.sh.in | 5 +++++ 2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/doc/PKGBUILD.5.txt b/doc/PKGBUILD.5.txt index a21c1df..7459521 100644 --- a/doc/PKGBUILD.5.txt +++ b/doc/PKGBUILD.5.txt @@ -389,7 +389,8 @@ makepkg supports building development versions of packages without having to manually update the pkgver in the PKGBUILD. This was formerly done using the separate utility 'versionpkg'. In order to utilize this functionality, your PKGBUILD must use correct variable names depending on the SCM being fetched -from (e.g., 'makepkg-git', 'mplayer-svn'). +from *and* the name of the package must end in -SCM (e.g., 'makepkg-git', +'mplayer-svn').
*CVS*:: The generated pkgver will be the date the package is built. diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index d4798ca..dd545c6 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1735,6 +1735,11 @@ devel_check() { vcs=${pkgname##*-} fi
+ if [[ "$vcs" != "${pkgname##*-}" ]]; then + warning "$(gettext "The pkgname does not end in -%s, skipping automatic versioning.")" "$vcs" + return 0 + fi + if ! type -p "$vcs" >/dev/null; then warning "$(gettext "Cannot find the %s binary required to determine latest %s revision.")" "$vcs" "$vcs" return 0 -- 1.7.9.3
On 03/12/2012 01:22 PM, Dave Reisner wrote:
On Mon, Mar 12, 2012 at 12:53:14PM -0600, dgbaley27@0x01b.net wrote:
From: Matthew Monaco
If the package's name does not end in -git/svn/etc, then don't touch the pkgver or pkgrel. This changes the current semantics of makepkg, but it shouldn't be too mind blowing.
And I strongly disagree... What's the point in holding the package version if you can't tell the VCS behind the source files to obey this arbitrary date (e.g. in the case of git)?
I'm not sure I follow. If the package uses _gitroot and _gitname, but is not -git, then from what I saw in packages.git and community.git, most of the time the package is built using git, but the intention is to still build some specific version. (There are a lot of packages that have to use __gitroot, __gitname...). The situation I intend(ed) to help with is when there is some package in the repos that I temporarily want to replace with the git version until the next release. For this, I grab the -git version but set the pkgver to some number just before the next release so future upgrades will happen automatically. That, coupled with my look through existing packages, made it seem like packages that don't have a -vcs shouldn't have the version's automatically set.
Currently in core/extra there are two vcs packages (svn) which use _svntrunk and _svnmod. They also use -svn in the pkgname so they won't be affected (mplayer-svn, seom-svn). In addition, vim uses the _hg directives but with a double underscore (presumably to avoid automatic versioning despite not being vim-git).
In community there are a few packages which use the vcs directives but do not have a -vcs name. Most of these appear to never want an automatic version number (blender, boinc, bti, cfml, go, lorcon, sfml).
The exceptions in community are: fusion-icon, ldc, notion, opencollada.
And in my opinion, these packages are wrong.
So then I'm not sure where the disagreement is =)
--- doc/PKGBUILD.5.txt | 3 ++- scripts/makepkg.sh.in | 5 +++++ 2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/doc/PKGBUILD.5.txt b/doc/PKGBUILD.5.txt index a21c1df..7459521 100644 --- a/doc/PKGBUILD.5.txt +++ b/doc/PKGBUILD.5.txt @@ -389,7 +389,8 @@ makepkg supports building development versions of packages without having to manually update the pkgver in the PKGBUILD. This was formerly done using the separate utility 'versionpkg'. In order to utilize this functionality, your PKGBUILD must use correct variable names depending on the SCM being fetched -from (e.g., 'makepkg-git', 'mplayer-svn'). +from *and* the name of the package must end in -SCM (e.g., 'makepkg-git', +'mplayer-svn').
*CVS*:: The generated pkgver will be the date the package is built. diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index d4798ca..dd545c6 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1735,6 +1735,11 @@ devel_check() { vcs=${pkgname##*-} fi
+ if [[ "$vcs" != "${pkgname##*-}" ]]; then + warning "$(gettext "The pkgname does not end in -%s, skipping automatic versioning.")" "$vcs" + return 0 + fi + if ! type -p "$vcs" >/dev/null; then warning "$(gettext "Cannot find the %s binary required to determine latest %s revision.")" "$vcs" "$vcs" return 0 -- 1.7.9.3
On Mon, Mar 12, 2012 at 01:33:47PM -0600, Matthew Monaco wrote:
On 03/12/2012 01:22 PM, Dave Reisner wrote:
And in my opinion, these packages are wrong.
So then I'm not sure where the disagreement is =)
*rereads* I'm not sure either. I'm going to get some more coffee. Ignore my rambling.
On 13/03/12 04:53, dgbaley27@0x01b.net wrote:
From: Matthew Monaco
If the package's name does not end in -git/svn/etc, then don't touch the pkgver or pkgrel. This changes the current semantics of makepkg, but it shouldn't be too mind blowing.
Well... even if Dave's ramblings are to be ignored, I am very strongly against this. 1) If you have defined _gitroot etc then you have a git package. The name of the package is immaterial. 2) If you do not want to update your pkgver then use the --holdver flag. (which is crap... but achieves the same as this patch). What problem is this solving? All I can see is adding a restriction to what a package name can be with absolutely no benefit. Allan
On 03/12/2012 05:12 PM, Allan McRae wrote:
On 13/03/12 04:53, dgbaley27@0x01b.net wrote:
From: Matthew Monaco
If the package's name does not end in -git/svn/etc, then don't touch the pkgver or pkgrel. This changes the current semantics of makepkg, but it shouldn't be too mind blowing.
Well... even if Dave's ramblings are to be ignored, I am very strongly against this.
Fair enough
1) If you have defined _gitroot etc then you have a git package. The name of the package is immaterial.
2) If you do not want to update your pkgver then use the --holdver flag. (which is crap... but achieves the same as this patch).
What problem is this solving? All I can see is adding a restriction to what a package name can be with absolutely no benefit.
I thought that requiring a package to be named appropriately to be considered a development package was at least worthy of discussion.
Allan
On Mon, Mar 12, 2012 at 05:54:52PM -0600, Matthew Monaco wrote:
On 03/12/2012 05:12 PM, Allan McRae wrote:
I thought that requiring a package to be named appropriately to be considered a development package was at least worthy of discussion.
Why not display a warning? Automagically modifying things is very unlike what pacman tools do, but vcs naming conventions are something I'd like to see encouraged. Since I'm currently out of aur helpers, I search for packages manually by name and missing packages because they don't stick to the convention is something I'd like to avoid. So, while we're at it, what other approaches on this can you suggest? Downloading pkgbuilds and checking the way mathew's code does now? cheers! mar77i
From: Matthew Monaco
From: Matthew Monaco
participants (5)
-
Allan McRae
-
Dave Reisner
-
dgbaley27＠0x01b.net
-
Martti Kühne
-
Matthew Monaco