Re: Bug#740862: Fwd: Bug#740862: duck: Should cease to pass "mailto:" URLs to curl
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Am 2014-03-07 09:54, schrieb Andreas Tille:
> Hi Simon,
>
> On Fri, Mar 07, 2014 at 09:09:02AM +0100, Simon Kainz wrote:
>>>
>>>> My *personal* opinion is that I would be fine with either of
>>>> these two options:
>>>
>>>> 1. Bug-Submit might allow Hyperlinks and mailto: links 2.
>>>> Bug-Submit should be a Hyperlink and we should enable another
>>>> field Bug-Mailto for e-mail addresses.
>>>
>> 2 is currently implemented and working, 1 is close to being
>> finished, with the following check:
>>
>> If Bug-Submit is mailto: - Style: Grab the email address, and
>> try to find out if an A(AAA) record for the given domain exists.
>> Checking for MX record is not enough in my opinion, as MTA use
>> A(AAA) records to deliver mail if no MX was found. This should
>> at least report email addresses which cannot receive emails
>> because there is no domain registered.
>>
>> If it's a Hyperlink: business as usual.
>>
>> Please share your thoughts about this.
>
> I'm pretty mazed whyt nifty stuff you can do with lintian! :-)
>
>
>> Another issue:
>>
>> The Repository: field is specified as "URL to a repository
>> containing the upstream sources." This is just the plain URL,
>> without indication what kind of VCS upstream might use. So I'm
>> having a hard time to distinguish an https:// based SVN url from
>> an https:// based GIT url. Same for hg,darcs and some others.
>>
>> Currently I try to be smart about detecting this (grepping for
>> shh://, git://, etc, but for those not-so-clear cases i can
>> currently only check whether the url is not 404, without
>> actually being able to check if the given VCS would work.
>>
>> Should this field be changed somehow, like Repository-Git? I'm
>> not sure if trying to find out which kind of repo upstream uses
>> by trying to appen well known postfixes (eg.
>> _darcs/hashed_inventory for DARCS) is the right way. I think
>> this is also an issue for humans, trying to use the Repository
>> URL: One would havve to first open the url using a browser and
>> then try to find out which VCS was used.
>>
>> Please share your thoughts about this.
>
> Since in d/control files we are distinguishing between
>
> Vcs-Browser Vcs-Git Vcs-Svn ...
>
> it might make sense to apply the same philosophy to upstream
> metadata and I somehow guess that the according tests would exist.
Hmm, thinking more about this, i would come up with a different approach:
d/control is follwing the VCS-* schema, because we know, which VCS's
we support (see [1] for the complete list) for debian (= which VCSs
debcheckout can work with).
In case this list is "complete" (like covering all possible VCSs,
which i hardly believe) this would suffice, but as i assume there are
(much) more different VCS tools out there, i would propose the
following approach, based on the Reference field in [2] :
- - Repository:
Type: Git
Url: git://foo.bar/baz.git
- - Repository:
Type: Git
Url: https://github.com/skainz/
- - Repository:
Type: Svn
Url: https://github.com/skainz/NiceCharts
- - Repository:
Type: Hg
Url: http://selenic.com/repo/hello
This would allow to define multiple upstream repos (as in d/control)
and would also provide an easy way to add new/different VCs types
without needing to alter the DEP12 schema.
Comments are welcome!
Bye, Simon
[1]
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields
[2] https://wiki.debian.org/UpstreamMetadata
>
>> Thank you,
>
> Thank you for your serious work on this
>
> Andreas.
>
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJTGZizAAoJEBy08PeN7K/pvM4P/1ya9HjPc0a64OH6KiUhTgfq
ByZGXFwoAAAOY/unPVGN0lr9Bt5/4Jm5ViP2b6fYhP53spW0hrAjAicGdwNy2VGb
F5IhuU6cVTJC2gqpDOc0n7xv1oYHL4ocK8kNAGarvxDbvdFFSxX/l2fMa8cVyByA
xw/ASzCp7aeUAqsX2wIaAJgX81y749uuxbKmS+8e3tYTIxXzVTuE8w/kKRlR5RbH
d6v8Pw5pcDXYREMctswxh+JxzdcnLkOKix7QMlxQXF7UzuZhBuglEgdffYwn/qFr
zyBNvVob2AKY+XqklM4y4HkTimMEGycrwW8tM5sjSIzF7OoNSlWQo2LbQ7IeIMM5
2pFmeoV4RnR3jCba9grKm/R4YNy5b2c56OHZIJNCbgciUvderXkTIvE44B/NZYLC
sNAWgoZGVXpyz7yRSdSDOKdf5djamcQkYZaWPxOtZHzqkT+rt81xD3bg1MD5XMOs
0QGX320ty6P0nuUg9y3Qz99OP7sDhDCv9PcqCqIJiLGK51KnI8XrG767YShWOn/K
cnrQEKOwfZ0RNu1Pf9jZeFy6zMVAWTv2O/mejMeNY4QlvnhHtLD1mFzK5IM7dnjh
jRHi3AapTjq6PYrz633ptv2VJIaQdAInBs79QYR3Z6xEopL2LwexAn55nzzSz6L/
SNWlYs8WtPMQjinhjrrx
=xRFW
-----END PGP SIGNATURE-----
Reply to: