tandem
/
numerus
2
0
Fork 0
Code Issues 39 Pull Requests Packages Projects 1 Releases 1 Wiki Activity
numerus/go.sum

209 lines
20 KiB
Plaintext
Raw Normal View History

Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
github.com/BurntSushi/toml v0.3.1/go.mod h1:xHWCNGjB5oqiDr8zfno3MHue2Ht5sIBksp03qcyfWMU=
github.com/Masterminds/semver/v3 v3.1.1/go.mod h1:VPu/7SZ7ePZ3QOrcuXROw5FAcLl4a0cBrbBpGY/8hQs=
github.com/cockroachdb/apd v1.1.0 h1:3LFP3629v+1aKXU5Q37mxmRxX/pIu1nijXydLShEq5I=
github.com/cockroachdb/apd v1.1.0/go.mod h1:8Sl8LxpKi29FqWXR16WEFZRNSz3SoPzUzeMeY4+DwBQ=
github.com/coreos/go-systemd v0.0.0-20190321100706-95778dfbb74e/go.mod h1:F5haX7vjVVG0kc13fIWeqUViNPyEJxv/OmvnBo0Yme4=
github.com/coreos/go-systemd v0.0.0-20190719114852-fd7a80b32e1f/go.mod h1:F5haX7vjVVG0kc13fIWeqUViNPyEJxv/OmvnBo0Yme4=
github.com/creack/pty v1.1.7/go.mod h1:lj5s0c3V2DBrqTV7llrYr5NG6My20zk30Fl46Y7DoTY=
Add the simplest possible web server to test login This is a very rough test to actually check the login function outside pgTAP; it is very ugly, in both design and code, and (i hope) does not reflect future quality. I was about to use Echo[0] as a “web framework”, but something feels wrong when using a framework with Go—i do not know what. I actually tried it and was even more put off by the JSON-formatted logger that can not be disabled; i was already losing control of the application! I created the folder following the apparently de facto guidelines for Go projects, and i see no problem with mixing Go’s folders with Sqitch’s: both are part of the same application and there are not conflicts. [0]: https://echo.labstack.com/ [1]: https://github.com/golang-standards/project-layout
2023-01-13 19:43:42 +00:00
github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
github.com/go-kit/log v0.1.0/go.mod h1:zbhenjAZHb184qTLMA9ZjW7ThYL0H2mk7Q6pNt4vbaY=
github.com/go-logfmt/logfmt v0.5.0/go.mod h1:wCYkCAKZfumFQihp8CzCvQ3paCTfi41vtzG1KdI/P7A=
github.com/go-stack/stack v1.8.0/go.mod h1:v0f6uXyyMGvRgIKkXu+yp6POWl0qKG85gN/melR3HDY=
github.com/gofrs/uuid v4.0.0+incompatible h1:1SD/1F5pU8p29ybwgQSwpQk+mwdRrXCYuPhW6m+TnJw=
github.com/gofrs/uuid v4.0.0+incompatible/go.mod h1:b2aQJv3Z4Fp6yNu3cdSllBxTCLRxnplIgP/c0N/04lM=
github.com/google/renameio v0.1.0/go.mod h1:KWCgfxg9yswjAJkECMjeO8J8rahYeXnNhOm40UhjYkI=
Fix use of API methods not available in Go 1.16 Apparently, url.Values.Has and math.MaxInt was added to Go 1.17, but on Debian Bullseye there is only Go 1.16. I do not want to install a new version of Go to the server unless there is an overwhelming reason, and a couple of methods are not. Thus, now i use Go 1.16 too on my development machine, to avoid situations like this.
2023-02-13 09:32:26 +00:00
github.com/jackc/chunkreader v1.0.0 h1:4s39bBR8ByfqH+DKm8rQA3E1LHZWB9XWcrz8fqaZbe0=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
github.com/jackc/chunkreader v1.0.0/go.mod h1:RT6O25fNZIuasFJRyZ4R/Y2BbhasbmZXF9QQ7T3kePo=
github.com/jackc/chunkreader/v2 v2.0.0/go.mod h1:odVSm741yZoC3dpHEUXIqA9tQRhFrgOHwnPIn9lDKlk=
github.com/jackc/chunkreader/v2 v2.0.1 h1:i+RDz65UE+mmpjTfyz0MoVTnzeYxroil2G82ki7MGG8=
github.com/jackc/chunkreader/v2 v2.0.1/go.mod h1:odVSm741yZoC3dpHEUXIqA9tQRhFrgOHwnPIn9lDKlk=
github.com/jackc/pgconn v0.0.0-20190420214824-7e0022ef6ba3/go.mod h1:jkELnwuX+w9qN5YIfX0fl88Ehu4XC3keFuOJJk9pcnA=
github.com/jackc/pgconn v0.0.0-20190824142844-760dd75542eb/go.mod h1:lLjNuW/+OfW9/pnVKPazfWOgNfH2aPem8YQ7ilXGvJE=
github.com/jackc/pgconn v0.0.0-20190831204454-2fabfa3c18b7/go.mod h1:ZJKsE/KZfsUgOEh9hBm+xYTstcNHg7UPMVJqRfQxq4s=
github.com/jackc/pgconn v1.8.0/go.mod h1:1C2Pb36bGIP9QHGBYCjnyhqu7Rv3sGshaQUvmfGIB/o=
github.com/jackc/pgconn v1.9.0/go.mod h1:YctiPyvzfU11JFxoXokUOOKQXQmDMoJL9vJzHH8/2JY=
github.com/jackc/pgconn v1.9.1-0.20210724152538-d89c8390a530/go.mod h1:4z2w8XhRbP1hYxkpTuBjTS3ne3J48K83+u0zoyvg2pI=
github.com/jackc/pgconn v1.13.0 h1:3L1XMNV2Zvca/8BYhzcRFS70Lr0WlDg16Di6SFGAbys=
github.com/jackc/pgconn v1.13.0/go.mod h1:AnowpAqO4CMIIJNZl2VJp+KrkAZciAkhEl0W0JIobpI=
github.com/jackc/pgio v1.0.0 h1:g12B9UwVnzGhueNavwioyEEpAmqMe1E/BN9ES+8ovkE=
github.com/jackc/pgio v1.0.0/go.mod h1:oP+2QK2wFfUWgr+gxjoBH9KGBb31Eio69xUb0w5bYf8=
github.com/jackc/pgmock v0.0.0-20190831213851-13a1b77aafa2/go.mod h1:fGZlG77KXmcq05nJLRkk0+p82V8B8Dw8KN2/V9c/OAE=
github.com/jackc/pgmock v0.0.0-20201204152224-4fe30f7445fd/go.mod h1:hrBW0Enj2AZTNpt/7Y5rr2xe/9Mn757Wtb2xeBzPv2c=
github.com/jackc/pgmock v0.0.0-20210724152146-4ad1a8207f65 h1:DadwsjnMwFjfWc9y5Wi/+Zz7xoE5ALHsRQlOctkOiHc=
github.com/jackc/pgmock v0.0.0-20210724152146-4ad1a8207f65/go.mod h1:5R2h2EEX+qri8jOWMbJCtaPWkrrNc7OHwsp2TCqp7ak=
Add the simplest possible web server to test login This is a very rough test to actually check the login function outside pgTAP; it is very ugly, in both design and code, and (i hope) does not reflect future quality. I was about to use Echo[0] as a “web framework”, but something feels wrong when using a framework with Go—i do not know what. I actually tried it and was even more put off by the JSON-formatted logger that can not be disabled; i was already losing control of the application! I created the folder following the apparently de facto guidelines for Go projects, and i see no problem with mixing Go’s folders with Sqitch’s: both are part of the same application and there are not conflicts. [0]: https://echo.labstack.com/ [1]: https://github.com/golang-standards/project-layout
2023-01-13 19:43:42 +00:00
github.com/jackc/pgpassfile v1.0.0 h1:/6Hmqy13Ss2zCq62VdNG8tM1wchn8zjSGOBJ6icpsIM=
github.com/jackc/pgpassfile v1.0.0/go.mod h1:CEx0iS5ambNFdcRtxPj5JhEz+xB6uRky5eyVu/W2HEg=
Fix use of API methods not available in Go 1.16 Apparently, url.Values.Has and math.MaxInt was added to Go 1.17, but on Debian Bullseye there is only Go 1.16. I do not want to install a new version of Go to the server unless there is an overwhelming reason, and a couple of methods are not. Thus, now i use Go 1.16 too on my development machine, to avoid situations like this.
2023-02-13 09:32:26 +00:00
github.com/jackc/pgproto3 v1.1.0 h1:FYYE4yRw+AgI8wXIinMlNjBbp/UitDJwfj5LqqewP1A=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
github.com/jackc/pgproto3 v1.1.0/go.mod h1:eR5FA3leWg7p9aeAqi37XOTgTIbkABlvcPB3E5rlc78=
github.com/jackc/pgproto3/v2 v2.0.0-alpha1.0.20190420180111-c116219b62db/go.mod h1:bhq50y+xrl9n5mRYyCBFKkpRVTLYJVWeCc+mEAI3yXA=
github.com/jackc/pgproto3/v2 v2.0.0-alpha1.0.20190609003834-432c2951c711/go.mod h1:uH0AWtUmuShn0bcesswc4aBTWGvw0cAxIJp+6OB//Wg=
github.com/jackc/pgproto3/v2 v2.0.0-rc3/go.mod h1:ryONWYqW6dqSg1Lw6vXNMXoBJhpzvWKnT95C46ckYeM=
github.com/jackc/pgproto3/v2 v2.0.0-rc3.0.20190831210041-4c03ce451f29/go.mod h1:ryONWYqW6dqSg1Lw6vXNMXoBJhpzvWKnT95C46ckYeM=
github.com/jackc/pgproto3/v2 v2.0.6/go.mod h1:WfJCnwN3HIg9Ish/j3sgWXnAfK8A9Y0bwXYU5xKaEdA=
github.com/jackc/pgproto3/v2 v2.1.1/go.mod h1:WfJCnwN3HIg9Ish/j3sgWXnAfK8A9Y0bwXYU5xKaEdA=
github.com/jackc/pgproto3/v2 v2.3.1 h1:nwj7qwf0S+Q7ISFfBndqeLwSwxs+4DPsbRFjECT1Y4Y=
github.com/jackc/pgproto3/v2 v2.3.1/go.mod h1:WfJCnwN3HIg9Ish/j3sgWXnAfK8A9Y0bwXYU5xKaEdA=
Add the simplest possible web server to test login This is a very rough test to actually check the login function outside pgTAP; it is very ugly, in both design and code, and (i hope) does not reflect future quality. I was about to use Echo[0] as a “web framework”, but something feels wrong when using a framework with Go—i do not know what. I actually tried it and was even more put off by the JSON-formatted logger that can not be disabled; i was already losing control of the application! I created the folder following the apparently de facto guidelines for Go projects, and i see no problem with mixing Go’s folders with Sqitch’s: both are part of the same application and there are not conflicts. [0]: https://echo.labstack.com/ [1]: https://github.com/golang-standards/project-layout
2023-01-13 19:43:42 +00:00
github.com/jackc/pgservicefile v0.0.0-20200714003250-2b9c44734f2b h1:C8S2+VttkHFdOOCXJe+YGfa4vHYwlt4Zx+IVXQ97jYg=
github.com/jackc/pgservicefile v0.0.0-20200714003250-2b9c44734f2b/go.mod h1:vsD4gTJCa9TptPL8sPkXrLZ+hDuNrZCnj29CQpr4X1E=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
github.com/jackc/pgtype v0.0.0-20190421001408-4ed0de4755e0/go.mod h1:hdSHsc1V01CGwFsrv11mJRHWJ6aifDLfdV3aVjFF0zg=
github.com/jackc/pgtype v0.0.0-20190824184912-ab885b375b90/go.mod h1:KcahbBH1nCMSo2DXpzsoWOAfFkdEtEJpPbVLq8eE+mc=
github.com/jackc/pgtype v0.0.0-20190828014616-a8802b16cc59/go.mod h1:MWlu30kVJrUS8lot6TQqcg7mtthZ9T0EoIBFiJcmcyw=
github.com/jackc/pgtype v1.8.1-0.20210724151600-32e20a603178/go.mod h1:C516IlIV9NKqfsMCXTdChteoXmwgUceqaLfjg2e3NlM=
github.com/jackc/pgtype v1.12.0 h1:Dlq8Qvcch7kiehm8wPGIW0W3KsCCHJnRacKW0UM8n5w=
github.com/jackc/pgtype v1.12.0/go.mod h1:LUMuVrfsFfdKGLw+AFFVv6KtHOFMwRgDDzBt76IqCA4=
github.com/jackc/pgx/v4 v4.0.0-20190420224344-cc3461e65d96/go.mod h1:mdxmSJJuR08CZQyj1PVQBHy9XOp5p8/SHH6a0psbY9Y=
github.com/jackc/pgx/v4 v4.0.0-20190421002000-1b8f0016e912/go.mod h1:no/Y67Jkk/9WuGR0JG/JseM9irFbnEPbuWV2EELPNuM=
github.com/jackc/pgx/v4 v4.0.0-pre1.0.20190824185557-6972a5742186/go.mod h1:X+GQnOEnf1dqHGpw7JmHqHc1NxDoalibchSk9/RWuDc=
github.com/jackc/pgx/v4 v4.12.1-0.20210724153913-640aa07df17c/go.mod h1:1QD0+tgSXP7iUjYm9C1NxKhny7lq6ee99u/z+IHFcgs=
github.com/jackc/pgx/v4 v4.17.2 h1:0Ut0rpeKwvIVbMQ1KbMBU4h6wxehBI535LK6Flheh8E=
github.com/jackc/pgx/v4 v4.17.2/go.mod h1:lcxIZN44yMIrWI78a5CpucdD14hX0SBDbNRvjDBItsw=
github.com/jackc/puddle v0.0.0-20190413234325-e4ced69a3a2b/go.mod h1:m4B5Dj62Y0fbyuIc15OsIqK0+JU8nkqQjsgx7dvjSWk=
github.com/jackc/puddle v0.0.0-20190608224051-11cab39313c9/go.mod h1:m4B5Dj62Y0fbyuIc15OsIqK0+JU8nkqQjsgx7dvjSWk=
github.com/jackc/puddle v1.1.3/go.mod h1:m4B5Dj62Y0fbyuIc15OsIqK0+JU8nkqQjsgx7dvjSWk=
github.com/jackc/puddle v1.3.0 h1:eHK/5clGOatcjX3oWGBO/MpxpbHzSwud5EWTSCI+MX0=
github.com/jackc/puddle v1.3.0/go.mod h1:m4B5Dj62Y0fbyuIc15OsIqK0+JU8nkqQjsgx7dvjSWk=
Replace default router with github.com/julienschmidt/httprouter I would fuck up handling URL parameters and this router has per-method handlers, that are easier to work with, in some cases.
2023-02-03 11:30:56 +00:00
github.com/julienschmidt/httprouter v1.3.0 h1:U0609e9tgbseu3rBINet9P48AI/D3oJs4dN7jwJOQ1U=
github.com/julienschmidt/httprouter v1.3.0/go.mod h1:JR6WtHb+2LUe8TCKY3cZOxFyyO8IZAc4RVcycCCAKdM=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
github.com/kisielk/gotool v1.0.0/go.mod h1:XhKaO+MFFWcvkIS/tQcRk01m1F5IRFswLeQ+oQHNcck=
github.com/konsorten/go-windows-terminal-sequences v1.0.1/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
github.com/konsorten/go-windows-terminal-sequences v1.0.2/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
github.com/kr/pretty v0.1.0/go.mod h1:dAy3ld7l9f0ibDNOQOHHMYYIIbhfbHSm3C4ZsoJORNo=
github.com/kr/pty v1.1.1/go.mod h1:pFQYn66WHrOpPYNljwOMqo10TkYh1fy3cYio2l3bCsQ=
github.com/kr/pty v1.1.8/go.mod h1:O1sed60cT9XZ5uDucP5qwvh+TE3NnUj51EiZO/lmSfw=
github.com/kr/text v0.1.0/go.mod h1:4Jbv+DJW3UT/LiOwJeYQe1efqtUx/iVham/4vfdArNI=
Add Catalan and Spanish translation with gotext[3] I had to choose between [1], [2], and [3]. As far as i could find, [1] is not easy to work with templates[4] and at the moment is not maintained[5]. Both [2] and [3] use the same approach to be used from within templates: you have to define a FuncMap with template functions that call the message catalog. Also, both libraries seems to be reasonably maintained, and have packages in Debian’s repository. However, [2] repeats the same mistakes that POSIX did with its catalogs—using identifiers that are not the strings in the source language—, however this time the catalogs are written in JSON or YAML! This, somehow, makes things worse…. [3], the one i settled with, is fine and decently maintained. There are some surprising things, such as to be able to use directly the PO file, and that it has higher priority over the corresponding MO, or that the order of parameters is reversed in respect to gettext. However, it uses a saner format, and is a lot easier to work with than [3]. The problem, of course, is that xgettext does not know how to find translatable strings inside the template. [3] includes a CLI tool similar to xgettext, but is not a drop-in replacement[6] and does not process templates. The proper way to handle this would be to add a parser to xgettext, but for now i found out that if i surround the call to the translation functions from within the template with parentheses, i can trick xgettext into believing it is parsing Scheme code, and extracts the strings successfully—at least, for what i have tried. Had to add the keyword for pgettext, because Schemed does not have it, but at least i can do that with command line parameters. For now i left only Spanish and Catalan as the two available languages, even though the source text is written in English, because that way i can make sure i do not leave strings untranslated. [1]: https://golang.org/x/text [2]: https://github.com/nicksnyder/go-i18n [3]: https://github.com/leonelquinteros/gotext [4]: https://github.com/golang/go/issues/39954 [5]: https://github.com/golang/go/issues/12750 [6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
github.com/leonelquinteros/gotext v1.5.1 h1:vmddRn3gHp67YFjZLZE2AZsgYMT4IBTJhua4yfe7/4Q=
github.com/leonelquinteros/gotext v1.5.1/go.mod h1:/A4Y7BvIsf5JHO60E43ZQDVkV3qO+7eP8HjeqD6ChIA=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
github.com/lib/pq v1.0.0/go.mod h1:5WUZQaWbwv1U+lTReE5YruASi9Al49XbQIvNi/34Woo=
github.com/lib/pq v1.1.0/go.mod h1:5WUZQaWbwv1U+lTReE5YruASi9Al49XbQIvNi/34Woo=
github.com/lib/pq v1.2.0/go.mod h1:5WUZQaWbwv1U+lTReE5YruASi9Al49XbQIvNi/34Woo=
github.com/lib/pq v1.10.2 h1:AqzbZs4ZoCBp+GtejcpCpcxM3zlSMx29dXbUSeVtJb8=
github.com/lib/pq v1.10.2/go.mod h1:AlVN5x4E4T544tWzH6hKfbfQvm3HdbOxrmggDNAPY9o=
github.com/mattn/go-colorable v0.1.1/go.mod h1:FuOcm+DKB9mbwrcAfNl7/TZVBZ6rcnceauSikq3lYCQ=
github.com/mattn/go-colorable v0.1.6/go.mod h1:u6P/XSegPjTcexA+o6vUJrdnUu04hMope9wVRipJSqc=
github.com/mattn/go-isatty v0.0.5/go.mod h1:Iq45c/XA43vh69/j3iqttzPXn0bhXyGjM0Hdxcsrc5s=
github.com/mattn/go-isatty v0.0.7/go.mod h1:Iq45c/XA43vh69/j3iqttzPXn0bhXyGjM0Hdxcsrc5s=
github.com/mattn/go-isatty v0.0.12/go.mod h1:cbi8OIDigv2wuxKPP5vlRcQ1OAZbq2CE4Kysco4FUpU=
github.com/pkg/errors v0.8.1 h1:iURUrRGxPUNPdy5/HRSm+Yj6okJ6UtLINN0Q9M4+h3I=
github.com/pkg/errors v0.8.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
Add the simplest possible web server to test login This is a very rough test to actually check the login function outside pgTAP; it is very ugly, in both design and code, and (i hope) does not reflect future quality. I was about to use Echo[0] as a “web framework”, but something feels wrong when using a framework with Go—i do not know what. I actually tried it and was even more put off by the JSON-formatted logger that can not be disabled; i was already losing control of the application! I created the folder following the apparently de facto guidelines for Go projects, and i see no problem with mixing Go’s folders with Sqitch’s: both are part of the same application and there are not conflicts. [0]: https://echo.labstack.com/ [1]: https://github.com/golang-standards/project-layout
2023-01-13 19:43:42 +00:00
github.com/pmezard/go-difflib v1.0.0 h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZbAQM=
github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
github.com/rogpeppe/go-internal v1.3.0/go.mod h1:M8bDsm7K2OlrFYOpmOWEs/qY81heoFRclV5y23lUDJ4=
github.com/rs/xid v1.2.1/go.mod h1:+uKXf+4Djp6Md1KODXJxgGQPKngRmWyn10oCKFzNHOQ=
github.com/rs/zerolog v1.13.0/go.mod h1:YbFCdg8HfsridGWAh22vktObvhZbQsZXe4/zB0OKkWU=
github.com/rs/zerolog v1.15.0/go.mod h1:xYTKnLHcpfU2225ny5qZjxnj9NvkumZYjJHlAThCjNc=
github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0=
github.com/shopspring/decimal v0.0.0-20180709203117-cd690d0c9e24/go.mod h1:M+9NzErvs504Cn4c5DxATwIqPbtswREoFCre64PpcG4=
github.com/shopspring/decimal v1.2.0 h1:abSATXmQEYyShuxI4/vyW3tV1MrKAJzCZ/0zLUXYbsQ=
github.com/shopspring/decimal v1.2.0/go.mod h1:DKyhrW/HYNuLGql+MJL6WCR6knT2jwCFRcu2hWCYk4o=
github.com/sirupsen/logrus v1.4.1/go.mod h1:ni0Sbl8bgC9z8RoU9G6nDWqqs/fq4eDPysMBDgk/93Q=
github.com/sirupsen/logrus v1.4.2/go.mod h1:tLMulIdttU9McNUspp0xgXVQah82FyeX6MwdIuYE2rE=
Add the simplest possible web server to test login This is a very rough test to actually check the login function outside pgTAP; it is very ugly, in both design and code, and (i hope) does not reflect future quality. I was about to use Echo[0] as a “web framework”, but something feels wrong when using a framework with Go—i do not know what. I actually tried it and was even more put off by the JSON-formatted logger that can not be disabled; i was already losing control of the application! I created the folder following the apparently de facto guidelines for Go projects, and i see no problem with mixing Go’s folders with Sqitch’s: both are part of the same application and there are not conflicts. [0]: https://echo.labstack.com/ [1]: https://github.com/golang-standards/project-layout
2023-01-13 19:43:42 +00:00
github.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
github.com/stretchr/objx v0.1.1/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
github.com/stretchr/objx v0.2.0/go.mod h1:qt09Ya8vawLte6SNmTgCsAVtYtaKzEcn8ATUoHMkEqE=
github.com/stretchr/objx v0.4.0/go.mod h1:YvHI0jy2hoMjB+UWwv71VJQ9isScKT/TqJzVSSt89Yw=
github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs=
Add the simplest possible web server to test login This is a very rough test to actually check the login function outside pgTAP; it is very ugly, in both design and code, and (i hope) does not reflect future quality. I was about to use Echo[0] as a “web framework”, but something feels wrong when using a framework with Go—i do not know what. I actually tried it and was even more put off by the JSON-formatted logger that can not be disabled; i was already losing control of the application! I created the folder following the apparently de facto guidelines for Go projects, and i see no problem with mixing Go’s folders with Sqitch’s: both are part of the same application and there are not conflicts. [0]: https://echo.labstack.com/ [1]: https://github.com/golang-standards/project-layout
2023-01-13 19:43:42 +00:00
github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UVUgZn+9EI=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
github.com/stretchr/testify v1.4.0/go.mod h1:j7eGeouHqKxXV5pUuKE4zz7dFj8WfuZ+81PSLYec5m4=
Add the simplest possible web server to test login This is a very rough test to actually check the login function outside pgTAP; it is very ugly, in both design and code, and (i hope) does not reflect future quality. I was about to use Echo[0] as a “web framework”, but something feels wrong when using a framework with Go—i do not know what. I actually tried it and was even more put off by the JSON-formatted logger that can not be disabled; i was already losing control of the application! I created the folder following the apparently de facto guidelines for Go projects, and i see no problem with mixing Go’s folders with Sqitch’s: both are part of the same application and there are not conflicts. [0]: https://echo.labstack.com/ [1]: https://github.com/golang-standards/project-layout
2023-01-13 19:43:42 +00:00
github.com/stretchr/testify v1.5.1/go.mod h1:5W2xD1RspED5o8YsWQXVCued0rvSQ+mT+I5cxcmMvtA=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
github.com/stretchr/testify v1.7.0/go.mod h1:6Fq8oRcR53rry900zMqJjRRixrwX3KX962/h/Wwjteg=
github.com/stretchr/testify v1.7.1/go.mod h1:6Fq8oRcR53rry900zMqJjRRixrwX3KX962/h/Wwjteg=
Add the simplest possible web server to test login This is a very rough test to actually check the login function outside pgTAP; it is very ugly, in both design and code, and (i hope) does not reflect future quality. I was about to use Echo[0] as a “web framework”, but something feels wrong when using a framework with Go—i do not know what. I actually tried it and was even more put off by the JSON-formatted logger that can not be disabled; i was already losing control of the application! I created the folder following the apparently de facto guidelines for Go projects, and i see no problem with mixing Go’s folders with Sqitch’s: both are part of the same application and there are not conflicts. [0]: https://echo.labstack.com/ [1]: https://github.com/golang-standards/project-layout
2023-01-13 19:43:42 +00:00
github.com/stretchr/testify v1.8.0 h1:pSgiaMZlXftHpm5L7V1+rVB+AZJydKsMxsQBIJw4PKk=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
github.com/stretchr/testify v1.8.0/go.mod h1:yNjHg4UonilssWZ8iaSj1OCr/vHnekPRkoO+kdMU+MU=
Add Catalan and Spanish translation with gotext[3] I had to choose between [1], [2], and [3]. As far as i could find, [1] is not easy to work with templates[4] and at the moment is not maintained[5]. Both [2] and [3] use the same approach to be used from within templates: you have to define a FuncMap with template functions that call the message catalog. Also, both libraries seems to be reasonably maintained, and have packages in Debian’s repository. However, [2] repeats the same mistakes that POSIX did with its catalogs—using identifiers that are not the strings in the source language—, however this time the catalogs are written in JSON or YAML! This, somehow, makes things worse…. [3], the one i settled with, is fine and decently maintained. There are some surprising things, such as to be able to use directly the PO file, and that it has higher priority over the corresponding MO, or that the order of parameters is reversed in respect to gettext. However, it uses a saner format, and is a lot easier to work with than [3]. The problem, of course, is that xgettext does not know how to find translatable strings inside the template. [3] includes a CLI tool similar to xgettext, but is not a drop-in replacement[6] and does not process templates. The proper way to handle this would be to add a parser to xgettext, but for now i found out that if i surround the call to the translation functions from within the template with parentheses, i can trick xgettext into believing it is parsing Scheme code, and extracts the strings successfully—at least, for what i have tried. Had to add the keyword for pgettext, because Schemed does not have it, but at least i can do that with command line parameters. For now i left only Spanish and Catalan as the two available languages, even though the source text is written in English, because that way i can make sure i do not leave strings untranslated. [1]: https://golang.org/x/text [2]: https://github.com/nicksnyder/go-i18n [3]: https://github.com/leonelquinteros/gotext [4]: https://github.com/golang/go/issues/39954 [5]: https://github.com/golang/go/issues/12750 [6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
github.com/yuin/goldmark v1.4.1/go.mod h1:mwnBkeHKe2W/ZEtQ+71ViKU8L12m81fl3OWwC1Zlc8k=
Fix use of API methods not available in Go 1.16 Apparently, url.Values.Has and math.MaxInt was added to Go 1.17, but on Debian Bullseye there is only Go 1.16. I do not want to install a new version of Go to the server unless there is an overwhelming reason, and a couple of methods are not. Thus, now i use Go 1.16 too on my development machine, to avoid situations like this.
2023-02-13 09:32:26 +00:00
github.com/yuin/goldmark v1.4.13/go.mod h1:6yULJ656Px+3vBD8DxQVa3kxgyrAnzto9xy5taEt/CY=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
github.com/zenazn/goji v0.9.0/go.mod h1:7S9M489iMyHBNxwZnk9/EHS098H4/F6TATF2mIxtB1Q=
go.uber.org/atomic v1.3.2/go.mod h1:gD2HeocX3+yG+ygLZcrzQJaqmWj9AIm7n08wl/qW/PE=
go.uber.org/atomic v1.4.0/go.mod h1:gD2HeocX3+yG+ygLZcrzQJaqmWj9AIm7n08wl/qW/PE=
go.uber.org/atomic v1.5.0/go.mod h1:sABNBOSYdrvTF6hTgEIbc7YasKWGhgEQZyfxyTvoXHQ=
go.uber.org/atomic v1.6.0/go.mod h1:sABNBOSYdrvTF6hTgEIbc7YasKWGhgEQZyfxyTvoXHQ=
go.uber.org/multierr v1.1.0/go.mod h1:wR5kodmAFQ0UK8QlbwjlSNy0Z68gJhDJUG5sjR94q/0=
go.uber.org/multierr v1.3.0/go.mod h1:VgVr7evmIr6uPjLBxg28wmKNXyqE9akIJ5XnfpiKl+4=
go.uber.org/multierr v1.5.0/go.mod h1:FeouvMocqHpRaaGuG9EjoKcStLC43Zu/fmqdUMPcKYU=
go.uber.org/tools v0.0.0-20190618225709-2cfd321de3ee/go.mod h1:vJERXedbb3MVM5f9Ejo0C68/HhF8uaILCdgjnY+goOA=
go.uber.org/zap v1.9.1/go.mod h1:vwi/ZaCAaUcBkycHslxD9B2zi4UTXhF60s6SWpuDF0Q=
go.uber.org/zap v1.10.0/go.mod h1:vwi/ZaCAaUcBkycHslxD9B2zi4UTXhF60s6SWpuDF0Q=
go.uber.org/zap v1.13.0/go.mod h1:zwrFLgMcdUuIBviXEYEH1YKNaOBnKXsx2IPda5bBwHM=
golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
golang.org/x/crypto v0.0.0-20190411191339-88737f569e3a/go.mod h1:WFFai1msRO1wXaEeE5yQxYXgSfI8pQAWXbQop6sCtWE=
golang.org/x/crypto v0.0.0-20190510104115-cbcb75029529/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
golang.org/x/crypto v0.0.0-20190820162420-60c769a6c586/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
golang.org/x/crypto v0.0.0-20201203163018-be400aefbc4c/go.mod h1:jdWPYTVW3xRLrWPugEBEK3UY2ZEsg3UU495nc5E+M+I=
golang.org/x/crypto v0.0.0-20210616213533-5ff15b29337e/go.mod h1:GvvjBRRGRdwPK5ydBHafDWAxML/pGHZbMvKqRZ5+Abc=
golang.org/x/crypto v0.0.0-20210711020723-a769d52b0f97/go.mod h1:GvvjBRRGRdwPK5ydBHafDWAxML/pGHZbMvKqRZ5+Abc=
Add Catalan and Spanish translation with gotext[3] I had to choose between [1], [2], and [3]. As far as i could find, [1] is not easy to work with templates[4] and at the moment is not maintained[5]. Both [2] and [3] use the same approach to be used from within templates: you have to define a FuncMap with template functions that call the message catalog. Also, both libraries seems to be reasonably maintained, and have packages in Debian’s repository. However, [2] repeats the same mistakes that POSIX did with its catalogs—using identifiers that are not the strings in the source language—, however this time the catalogs are written in JSON or YAML! This, somehow, makes things worse…. [3], the one i settled with, is fine and decently maintained. There are some surprising things, such as to be able to use directly the PO file, and that it has higher priority over the corresponding MO, or that the order of parameters is reversed in respect to gettext. However, it uses a saner format, and is a lot easier to work with than [3]. The problem, of course, is that xgettext does not know how to find translatable strings inside the template. [3] includes a CLI tool similar to xgettext, but is not a drop-in replacement[6] and does not process templates. The proper way to handle this would be to add a parser to xgettext, but for now i found out that if i surround the call to the translation functions from within the template with parentheses, i can trick xgettext into believing it is parsing Scheme code, and extracts the strings successfully—at least, for what i have tried. Had to add the keyword for pgettext, because Schemed does not have it, but at least i can do that with command line parameters. For now i left only Spanish and Catalan as the two available languages, even though the source text is written in English, because that way i can make sure i do not leave strings untranslated. [1]: https://golang.org/x/text [2]: https://github.com/nicksnyder/go-i18n [3]: https://github.com/leonelquinteros/gotext [4]: https://github.com/golang/go/issues/39954 [5]: https://github.com/golang/go/issues/12750 [6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
golang.org/x/crypto v0.0.0-20210921155107-089bfa567519/go.mod h1:GvvjBRRGRdwPK5ydBHafDWAxML/pGHZbMvKqRZ5+Abc=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
golang.org/x/crypto v0.0.0-20220722155217-630584e8d5aa/go.mod h1:IxCIyHEi3zRg3s0A5j5BB6A9Jmi73HwBIUl50j+osU4=
Add the simplest possible web server to test login This is a very rough test to actually check the login function outside pgTAP; it is very ugly, in both design and code, and (i hope) does not reflect future quality. I was about to use Echo[0] as a “web framework”, but something feels wrong when using a framework with Go—i do not know what. I actually tried it and was even more put off by the JSON-formatted logger that can not be disabled; i was already losing control of the application! I created the folder following the apparently de facto guidelines for Go projects, and i see no problem with mixing Go’s folders with Sqitch’s: both are part of the same application and there are not conflicts. [0]: https://echo.labstack.com/ [1]: https://github.com/golang-standards/project-layout
2023-01-13 19:43:42 +00:00
golang.org/x/crypto v0.0.0-20220829220503-c86fa9a7ed90 h1:Y/gsMcFOcR+6S6f3YeMKl5g+dZMEWqcz5Czj/GWYbkM=
golang.org/x/crypto v0.0.0-20220829220503-c86fa9a7ed90/go.mod h1:IxCIyHEi3zRg3s0A5j5BB6A9Jmi73HwBIUl50j+osU4=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
golang.org/x/lint v0.0.0-20190930215403-16217165b5de/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc=
golang.org/x/mod v0.0.0-20190513183733-4bf6d317e70e/go.mod h1:mXi4GBBbnImb6dmsKGUJ2LatrhH/nqhxcFungHvyanc=
golang.org/x/mod v0.1.1-0.20191105210325-c90efee705ee/go.mod h1:QqPTAvyqsEbceGzBzNggFXnrqF1CaUcvgkdR5Ot7KZg=
Add Catalan and Spanish translation with gotext[3] I had to choose between [1], [2], and [3]. As far as i could find, [1] is not easy to work with templates[4] and at the moment is not maintained[5]. Both [2] and [3] use the same approach to be used from within templates: you have to define a FuncMap with template functions that call the message catalog. Also, both libraries seems to be reasonably maintained, and have packages in Debian’s repository. However, [2] repeats the same mistakes that POSIX did with its catalogs—using identifiers that are not the strings in the source language—, however this time the catalogs are written in JSON or YAML! This, somehow, makes things worse…. [3], the one i settled with, is fine and decently maintained. There are some surprising things, such as to be able to use directly the PO file, and that it has higher priority over the corresponding MO, or that the order of parameters is reversed in respect to gettext. However, it uses a saner format, and is a lot easier to work with than [3]. The problem, of course, is that xgettext does not know how to find translatable strings inside the template. [3] includes a CLI tool similar to xgettext, but is not a drop-in replacement[6] and does not process templates. The proper way to handle this would be to add a parser to xgettext, but for now i found out that if i surround the call to the translation functions from within the template with parentheses, i can trick xgettext into believing it is parsing Scheme code, and extracts the strings successfully—at least, for what i have tried. Had to add the keyword for pgettext, because Schemed does not have it, but at least i can do that with command line parameters. For now i left only Spanish and Catalan as the two available languages, even though the source text is written in English, because that way i can make sure i do not leave strings untranslated. [1]: https://golang.org/x/text [2]: https://github.com/nicksnyder/go-i18n [3]: https://github.com/leonelquinteros/gotext [4]: https://github.com/golang/go/issues/39954 [5]: https://github.com/golang/go/issues/12750 [6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
golang.org/x/mod v0.6.0-dev.0.20220106191415-9b9b3d81d5e3/go.mod h1:3p9vT2HGsQu2K1YbXdKPJLVgG5VJdoTa1poYQBtP1AY=
Fix use of API methods not available in Go 1.16 Apparently, url.Values.Has and math.MaxInt was added to Go 1.17, but on Debian Bullseye there is only Go 1.16. I do not want to install a new version of Go to the server unless there is an overwhelming reason, and a couple of methods are not. Thus, now i use Go 1.16 too on my development machine, to avoid situations like this.
2023-02-13 09:32:26 +00:00
golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4/go.mod h1:jJ57K6gSWd91VN4djpZkiMVwK6gcyfeH4XE8wZrZaV4=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
golang.org/x/net v0.0.0-20190311183353-d8887717615a/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
golang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
golang.org/x/net v0.0.0-20190813141303-74dc4d7220e7/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
golang.org/x/net v0.0.0-20210226172049-e18ecbb05110/go.mod h1:m0MpNAwzfU5UDzcl9v0D8zg8gWTRqZa9RBIspLL5mdg=
Add Catalan and Spanish translation with gotext[3] I had to choose between [1], [2], and [3]. As far as i could find, [1] is not easy to work with templates[4] and at the moment is not maintained[5]. Both [2] and [3] use the same approach to be used from within templates: you have to define a FuncMap with template functions that call the message catalog. Also, both libraries seems to be reasonably maintained, and have packages in Debian’s repository. However, [2] repeats the same mistakes that POSIX did with its catalogs—using identifiers that are not the strings in the source language—, however this time the catalogs are written in JSON or YAML! This, somehow, makes things worse…. [3], the one i settled with, is fine and decently maintained. There are some surprising things, such as to be able to use directly the PO file, and that it has higher priority over the corresponding MO, or that the order of parameters is reversed in respect to gettext. However, it uses a saner format, and is a lot easier to work with than [3]. The problem, of course, is that xgettext does not know how to find translatable strings inside the template. [3] includes a CLI tool similar to xgettext, but is not a drop-in replacement[6] and does not process templates. The proper way to handle this would be to add a parser to xgettext, but for now i found out that if i surround the call to the translation functions from within the template with parentheses, i can trick xgettext into believing it is parsing Scheme code, and extracts the strings successfully—at least, for what i have tried. Had to add the keyword for pgettext, because Schemed does not have it, but at least i can do that with command line parameters. For now i left only Spanish and Catalan as the two available languages, even though the source text is written in English, because that way i can make sure i do not leave strings untranslated. [1]: https://golang.org/x/text [2]: https://github.com/nicksnyder/go-i18n [3]: https://github.com/leonelquinteros/gotext [4]: https://github.com/golang/go/issues/39954 [5]: https://github.com/golang/go/issues/12750 [6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
golang.org/x/net v0.0.0-20211015210444-4f30a5c0130f/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
golang.org/x/net v0.0.0-20211112202133-69e39bad7dc2/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y=
Fix use of API methods not available in Go 1.16 Apparently, url.Values.Has and math.MaxInt was added to Go 1.17, but on Debian Bullseye there is only Go 1.16. I do not want to install a new version of Go to the server unless there is an overwhelming reason, and a couple of methods are not. Thus, now i use Go 1.16 too on my development machine, to avoid situations like this.
2023-02-13 09:32:26 +00:00
golang.org/x/net v0.0.0-20220722155237-a158d28d115b/go.mod h1:XRhObCWvk6IyKnWLug+ECip1KBveYUHfp+8e9klMJ9c=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
golang.org/x/sync v0.0.0-20190423024810-112230192c58/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
Add Catalan and Spanish translation with gotext[3] I had to choose between [1], [2], and [3]. As far as i could find, [1] is not easy to work with templates[4] and at the moment is not maintained[5]. Both [2] and [3] use the same approach to be used from within templates: you have to define a FuncMap with template functions that call the message catalog. Also, both libraries seems to be reasonably maintained, and have packages in Debian’s repository. However, [2] repeats the same mistakes that POSIX did with its catalogs—using identifiers that are not the strings in the source language—, however this time the catalogs are written in JSON or YAML! This, somehow, makes things worse…. [3], the one i settled with, is fine and decently maintained. There are some surprising things, such as to be able to use directly the PO file, and that it has higher priority over the corresponding MO, or that the order of parameters is reversed in respect to gettext. However, it uses a saner format, and is a lot easier to work with than [3]. The problem, of course, is that xgettext does not know how to find translatable strings inside the template. [3] includes a CLI tool similar to xgettext, but is not a drop-in replacement[6] and does not process templates. The proper way to handle this would be to add a parser to xgettext, but for now i found out that if i surround the call to the translation functions from within the template with parentheses, i can trick xgettext into believing it is parsing Scheme code, and extracts the strings successfully—at least, for what i have tried. Had to add the keyword for pgettext, because Schemed does not have it, but at least i can do that with command line parameters. For now i left only Spanish and Catalan as the two available languages, even though the source text is written in English, because that way i can make sure i do not leave strings untranslated. [1]: https://golang.org/x/text [2]: https://github.com/nicksnyder/go-i18n [3]: https://github.com/leonelquinteros/gotext [4]: https://github.com/golang/go/issues/39954 [5]: https://github.com/golang/go/issues/12750 [6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
golang.org/x/sync v0.0.0-20210220032951-036812b2e83c/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
Fix use of API methods not available in Go 1.16 Apparently, url.Values.Has and math.MaxInt was added to Go 1.17, but on Debian Bullseye there is only Go 1.16. I do not want to install a new version of Go to the server unless there is an overwhelming reason, and a couple of methods are not. Thus, now i use Go 1.16 too on my development machine, to avoid situations like this.
2023-02-13 09:32:26 +00:00
golang.org/x/sync v0.0.0-20220722155255-886fb9371eb4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
golang.org/x/sys v0.0.0-20180905080454-ebe1bf3edb33/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
golang.org/x/sys v0.0.0-20190222072716-a9d3bda3a223/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
golang.org/x/sys v0.0.0-20190403152447-81d4e9dc473e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20190422165155-953cdadca894/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20190813064441-fde4db37ae7a/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20191026070338-33540a1f6037/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20200116001909-b77594299b42/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20200223170610-d5e6a3e2c0ae/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20201119102817-f84b799fce68/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20210423082822-04245dca01da/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
Add Catalan and Spanish translation with gotext[3] I had to choose between [1], [2], and [3]. As far as i could find, [1] is not easy to work with templates[4] and at the moment is not maintained[5]. Both [2] and [3] use the same approach to be used from within templates: you have to define a FuncMap with template functions that call the message catalog. Also, both libraries seems to be reasonably maintained, and have packages in Debian’s repository. However, [2] repeats the same mistakes that POSIX did with its catalogs—using identifiers that are not the strings in the source language—, however this time the catalogs are written in JSON or YAML! This, somehow, makes things worse…. [3], the one i settled with, is fine and decently maintained. There are some surprising things, such as to be able to use directly the PO file, and that it has higher priority over the corresponding MO, or that the order of parameters is reversed in respect to gettext. However, it uses a saner format, and is a lot easier to work with than [3]. The problem, of course, is that xgettext does not know how to find translatable strings inside the template. [3] includes a CLI tool similar to xgettext, but is not a drop-in replacement[6] and does not process templates. The proper way to handle this would be to add a parser to xgettext, but for now i found out that if i surround the call to the translation functions from within the template with parentheses, i can trick xgettext into believing it is parsing Scheme code, and extracts the strings successfully—at least, for what i have tried. Had to add the keyword for pgettext, because Schemed does not have it, but at least i can do that with command line parameters. For now i left only Spanish and Catalan as the two available languages, even though the source text is written in English, because that way i can make sure i do not leave strings untranslated. [1]: https://golang.org/x/text [2]: https://github.com/nicksnyder/go-i18n [3]: https://github.com/leonelquinteros/gotext [4]: https://github.com/golang/go/issues/39954 [5]: https://github.com/golang/go/issues/12750 [6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
golang.org/x/sys v0.0.0-20211019181941-9d821ace8654/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
Fix use of API methods not available in Go 1.16 Apparently, url.Values.Has and math.MaxInt was added to Go 1.17, but on Debian Bullseye there is only Go 1.16. I do not want to install a new version of Go to the server unless there is an overwhelming reason, and a couple of methods are not. Thus, now i use Go 1.16 too on my development machine, to avoid situations like this.
2023-02-13 09:32:26 +00:00
golang.org/x/sys v0.0.0-20220520151302-bc2c85ada10a/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
golang.org/x/sys v0.0.0-20220722155257-8c9f86f7a55f/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
golang.org/x/term v0.0.0-20201117132131-f5c789dd3221/go.mod h1:Nr5EML6q2oocZ2LXRh80K7BxOlk5/8JxuGnuhpl+muw=
golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo=
Fix use of API methods not available in Go 1.16 Apparently, url.Values.Has and math.MaxInt was added to Go 1.17, but on Debian Bullseye there is only Go 1.16. I do not want to install a new version of Go to the server unless there is an overwhelming reason, and a couple of methods are not. Thus, now i use Go 1.16 too on my development machine, to avoid situations like this.
2023-02-13 09:32:26 +00:00
golang.org/x/term v0.0.0-20210927222741-03fcf44c2211/go.mod h1:jbD1KX2456YbFQfuXm/mYQcufACuNUgVhRMnK/tPxf8=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
golang.org/x/text v0.3.2/go.mod h1:bEr9sfX3Q8Zfm5fL9x+3itogRgK3+ptLWKqgva+5dAk=
golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
golang.org/x/text v0.3.4/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
golang.org/x/text v0.3.6/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
golang.org/x/text v0.3.7/go.mod h1:u+2+/6zg+i71rQMx5EYifcz6MCKuco9NR6JIITiCfzQ=
Add the simplest possible web server to test login This is a very rough test to actually check the login function outside pgTAP; it is very ugly, in both design and code, and (i hope) does not reflect future quality. I was about to use Echo[0] as a “web framework”, but something feels wrong when using a framework with Go—i do not know what. I actually tried it and was even more put off by the JSON-formatted logger that can not be disabled; i was already losing control of the application! I created the folder following the apparently de facto guidelines for Go projects, and i see no problem with mixing Go’s folders with Sqitch’s: both are part of the same application and there are not conflicts. [0]: https://echo.labstack.com/ [1]: https://github.com/golang-standards/project-layout
2023-01-13 19:43:42 +00:00
golang.org/x/text v0.3.8 h1:nAL+RVCQ9uMn3vJZbV+MRnydTJFPf8qqY42YiA6MrqY=
golang.org/x/text v0.3.8/go.mod h1:E6s5w1FMmriuDzIBO73fBruAKo1PCIq6d2Q6DHfQ8WQ=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
golang.org/x/tools v0.0.0-20190311212946-11955173bddd/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs=
golang.org/x/tools v0.0.0-20190425163242-31fd60d6bfdc/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q=
golang.org/x/tools v0.0.0-20190621195816-6e04913cbbac/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc=
golang.org/x/tools v0.0.0-20190823170909-c4a336ef6a2f/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
golang.org/x/tools v0.0.0-20191029041327-9cc4af7d6b2c/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
golang.org/x/tools v0.0.0-20191029190741-b9c20aec41a5/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
Add Catalan and Spanish translation with gotext[3] I had to choose between [1], [2], and [3]. As far as i could find, [1] is not easy to work with templates[4] and at the moment is not maintained[5]. Both [2] and [3] use the same approach to be used from within templates: you have to define a FuncMap with template functions that call the message catalog. Also, both libraries seems to be reasonably maintained, and have packages in Debian’s repository. However, [2] repeats the same mistakes that POSIX did with its catalogs—using identifiers that are not the strings in the source language—, however this time the catalogs are written in JSON or YAML! This, somehow, makes things worse…. [3], the one i settled with, is fine and decently maintained. There are some surprising things, such as to be able to use directly the PO file, and that it has higher priority over the corresponding MO, or that the order of parameters is reversed in respect to gettext. However, it uses a saner format, and is a lot easier to work with than [3]. The problem, of course, is that xgettext does not know how to find translatable strings inside the template. [3] includes a CLI tool similar to xgettext, but is not a drop-in replacement[6] and does not process templates. The proper way to handle this would be to add a parser to xgettext, but for now i found out that if i surround the call to the translation functions from within the template with parentheses, i can trick xgettext into believing it is parsing Scheme code, and extracts the strings successfully—at least, for what i have tried. Had to add the keyword for pgettext, because Schemed does not have it, but at least i can do that with command line parameters. For now i left only Spanish and Catalan as the two available languages, even though the source text is written in English, because that way i can make sure i do not leave strings untranslated. [1]: https://golang.org/x/text [2]: https://github.com/nicksnyder/go-i18n [3]: https://github.com/leonelquinteros/gotext [4]: https://github.com/golang/go/issues/39954 [5]: https://github.com/golang/go/issues/12750 [6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
golang.org/x/tools v0.0.0-20191119224855-298f0cb1881e/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
golang.org/x/tools v0.0.0-20200103221440-774c71fcf114/go.mod h1:TB2adYChydJhpapKDTa4BR/hXlZSLoq2Wpct/0txZ28=
Add Catalan and Spanish translation with gotext[3] I had to choose between [1], [2], and [3]. As far as i could find, [1] is not easy to work with templates[4] and at the moment is not maintained[5]. Both [2] and [3] use the same approach to be used from within templates: you have to define a FuncMap with template functions that call the message catalog. Also, both libraries seems to be reasonably maintained, and have packages in Debian’s repository. However, [2] repeats the same mistakes that POSIX did with its catalogs—using identifiers that are not the strings in the source language—, however this time the catalogs are written in JSON or YAML! This, somehow, makes things worse…. [3], the one i settled with, is fine and decently maintained. There are some surprising things, such as to be able to use directly the PO file, and that it has higher priority over the corresponding MO, or that the order of parameters is reversed in respect to gettext. However, it uses a saner format, and is a lot easier to work with than [3]. The problem, of course, is that xgettext does not know how to find translatable strings inside the template. [3] includes a CLI tool similar to xgettext, but is not a drop-in replacement[6] and does not process templates. The proper way to handle this would be to add a parser to xgettext, but for now i found out that if i surround the call to the translation functions from within the template with parentheses, i can trick xgettext into believing it is parsing Scheme code, and extracts the strings successfully—at least, for what i have tried. Had to add the keyword for pgettext, because Schemed does not have it, but at least i can do that with command line parameters. For now i left only Spanish and Catalan as the two available languages, even though the source text is written in English, because that way i can make sure i do not leave strings untranslated. [1]: https://golang.org/x/text [2]: https://github.com/nicksnyder/go-i18n [3]: https://github.com/leonelquinteros/gotext [4]: https://github.com/golang/go/issues/39954 [5]: https://github.com/golang/go/issues/12750 [6]: https://github.com/leonelquinteros/gotext/issues/38
2023-01-18 18:07:42 +00:00
golang.org/x/tools v0.1.10/go.mod h1:Uh6Zz+xoGYZom868N8YTex3t7RhtHDBrE8Gzo9bV56E=
Fix use of API methods not available in Go 1.16 Apparently, url.Values.Has and math.MaxInt was added to Go 1.17, but on Debian Bullseye there is only Go 1.16. I do not want to install a new version of Go to the server unless there is an overwhelming reason, and a couple of methods are not. Thus, now i use Go 1.16 too on my development machine, to avoid situations like this.
2023-02-13 09:32:26 +00:00
golang.org/x/tools v0.1.12/go.mod h1:hNGJHUnrk76NpqgfD5Aqm5Crs+Hm0VOH/i9J2+nxYbc=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
golang.org/x/xerrors v0.0.0-20190410155217-1f06c39b4373/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
golang.org/x/xerrors v0.0.0-20190513163551-3ee3066db522/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
Add the simplest possible web server to test login This is a very rough test to actually check the login function outside pgTAP; it is very ugly, in both design and code, and (i hope) does not reflect future quality. I was about to use Echo[0] as a “web framework”, but something feels wrong when using a framework with Go—i do not know what. I actually tried it and was even more put off by the JSON-formatted logger that can not be disabled; i was already losing control of the application! I created the folder following the apparently de facto guidelines for Go projects, and i see no problem with mixing Go’s folders with Sqitch’s: both are part of the same application and there are not conflicts. [0]: https://echo.labstack.com/ [1]: https://github.com/golang-standards/project-layout
2023-01-13 19:43:42 +00:00
gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
gopkg.in/errgo.v2 v2.1.0/go.mod h1:hNsd1EY+bozCKY1Ytp96fpM3vjJbqLJn88ws8XvfDNI=
gopkg.in/inconshreveable/log15.v2 v2.0.0-20180818164646-67afb5ed74ec/go.mod h1:aPpfJ7XW+gOuirDoZ8gHhLh3kZ1B08FtV2bbmy7Jv3s=
Add the simplest possible web server to test login This is a very rough test to actually check the login function outside pgTAP; it is very ugly, in both design and code, and (i hope) does not reflect future quality. I was about to use Echo[0] as a “web framework”, but something feels wrong when using a framework with Go—i do not know what. I actually tried it and was even more put off by the JSON-formatted logger that can not be disabled; i was already losing control of the application! I created the folder following the apparently de facto guidelines for Go projects, and i see no problem with mixing Go’s folders with Sqitch’s: both are part of the same application and there are not conflicts. [0]: https://echo.labstack.com/ [1]: https://github.com/golang-standards/project-layout
2023-01-13 19:43:42 +00:00
gopkg.in/yaml.v2 v2.2.2/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=
Add the simplest possible web server to test login This is a very rough test to actually check the login function outside pgTAP; it is very ugly, in both design and code, and (i hope) does not reflect future quality. I was about to use Echo[0] as a “web framework”, but something feels wrong when using a framework with Go—i do not know what. I actually tried it and was even more put off by the JSON-formatted logger that can not be disabled; i was already losing control of the application! I created the folder following the apparently de facto guidelines for Go projects, and i see no problem with mixing Go’s folders with Sqitch’s: both are part of the same application and there are not conflicts. [0]: https://echo.labstack.com/ [1]: https://github.com/golang-standards/project-layout
2023-01-13 19:43:42 +00:00
gopkg.in/yaml.v3 v3.0.1 h1:fxVm/GzAzEWqLHuvctI91KS9hhNmmWOoWu0XTYJS7CA=
Downgrade pgx to v4 I’ve tried to make RPM packages of numerus and pgx/v4 for AlmaLinux, so install in a virtual server, but i was unable to break a build cycle between golang/x/text, required by pgx, and golang/x/tools both a dependency and a dependee of golang/x/text: once tools finished building, it would trigger a new build for text, that in turn would trigger a build for all its dependences, including tools. At the end i had to create a Debian repository, because they already have all the packages, even though i had to back port pgx/v4 from Testing to bullseye. I did not want to try my luck with writting packages for pgx/v5, so v4 it is.
2023-01-15 19:45:45 +00:00
gopkg.in/yaml.v3 v3.0.1/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=
honnef.co/go/tools v0.0.1-2019.2.3/go.mod h1:a3bituU0lyd329TUQxRnasdCoJDkEUEAqEt0JzvZhAg=