Bug#951374: RFP: gh -- the GitHub CLI

2021-08-16 Thread Brian Thompson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2021-08-16 at 21:27 -0600, Anthony Fok wrote:
>  NEW queueOn Sun, Aug 15, 2021 at 10:45 PM Brian Thompson
>  wrote:
> > 
> > Since there is already a package that uses that binary name, who should
> > change it? Do we follow a first-come first-serve binary name reservation
> > strategy? I don't think it's a big deal to change the name.
> > 
> > I'm not sure what to rename it to. I don't like binaries with long,
> > descriptive names, but I don't know what we could use that is short. I
> > will raise awareness about this issue with the upstream developers.
> 
> Hi Brian,
> 
> First of all, thank you for volunteering to help with the packaging of
> GitHub CLI.
> 

Anthony,

Thank you for being intimate with the details. 

> Here is my understanding:
> 
> Now, you might run into a problem when actually trying to name the
> package "github-cli" (or even "gh") because dh-make-golang 0.4.0 does
> not allow for overriding the package name.  For example:
> 
> dh-make-golang -type p -pristine-tar github.com/cli/cli
> 
> would name the package "cli"... I am working on packaging the latest
> dh-make-golang and will try to add a flag to allow overriding the
> package name, to be uploaded as dh-make-golang 0.4.1 or 0.5.0.

It sounds like this functionality is required for what we are trying to achieve.
I am not very familiar with the golang family and its surrounding infrastructure
regarding Debian. Perhaps I am not best-equipped to package the github-cli tool,
but I am always willing to learn.

> Then there are the yet-to-be-packaged dependencies.  Just so that you
> know, the following packages that github-cli depends on have already
> been packaged but currently sitting in the
> https://ftp-master.debian.org/new.html NEW queue:
> 
>  * golang-github-yuin-goldmark-emoji 1.0.1-1
>  * golang-github-muesli-reflow 0.3.0-1
>  * golang-github-shurcool-graphql 0.0~git20200928.18c5c31-1
>  * golang-github-shurcool-githubv4 0.0~git20210725.83ba7b4-1
> 
> I'll report back here if I were to package and upload more of these
> dependencies so as to avoid duplication of work.
> 

It sounds like we should pause the github-cli technical packaging work until
dependent features and packages are added to the ecosystem. Would you agree with
that? I'm not seeing any BTS tags specific to RFPs (or bugs in general) for
marking it as "blocked", as we would say in the corporate world. Although I am
not sure that is even necessary.
- -- 
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEbQYcTHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2GfaNpEACgqGGp/BsUjnGpALGzNbMtqY2P4b3d
EqhxUmQdEzDPKw7g4ajyYkFiDm9Djgvz2g3R6jgYcjuOlcjeI3YOZNtJMmriUw7p
CM4jgaaXn/YvKFQxqNWD7GTsWlJnej4mCmebiRTseG3MX8BEHb4Ukndiy3pR2vXx
nhHVq+JJZsti8goTcROgToG8a0lH+rUj8yc0uN/e2JQcLCHOjXZdgUDQQzUVW+3C
iVMJ1tp88vrTpXn04TxMdHIyGbWh8SMFv9Q3+F4HyWBc9UiYq4kmOw1US/0YL8PQ
rwiGXzNxS6BoYZ9W0EtRwy27asBJDpfRsGOFzqzVK+fSGk7teThL3sS8SoxR1XjQ
Z7sebgTsY+A0b8+YYR8UOZb1Ei616cmD/m2bKntHQHzTMQw1rmWJgKxeoh9ARv91
b1PUbZndsSDbOukj+nt+gD+NayAwJDceTYZ3hm5FnE4tADPWCkeSixQVBafNM1i5
ZY02qCqtP0Z37lRsAOj53jTweOmSm4Fv5sJG/FtqHEAnd/fNd17KT5ggii6uPEhD
vdyBdtlB5K8ZboT7f2HtHuoOkAHcLPKU6rq0kAI+43Dt0nw4XTSWoB3AH2dNW4ii
wKqxgOKo4j+mxc6TZckn4xNbRXrB1dGEwu7/HuRg//+EsdqNW0PWNEqpNxIRNHgz
NhR8XUSX3KW71Q==
=Bui2
-END PGP SIGNATURE-



Bug#951374: RFP: gh -- the GitHub CLI

2021-08-15 Thread Brian Thompson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, 14 Aug 2021 14:18:34 -0400 =?utf-8?Q?Antoine_Beaupr=C3=A9?= <
anar...@orangeseeds.org> wrote:
> 
> It's not on the package name, but there's already a clash on the
binary
> name, which we should be mindful of:
>  gitsome provides direct integration with GitHub and GitHub Enterprise
in
>  a terminal.
> 
> Since it's a git (and github, even!) related tool, we might even want
to
> Conflict with it directly...

Since there is already a package that uses that binary name, who should
change it? Do we follow a first-come first-serve binary name reservation
strategy? I don't think it's a big deal to change the name.

I'm not sure what to rename it to. I don't like binaries with long,
descriptive names, but I don't know what we could use that is short. I
will raise awareness about this issue with the upstream developers.
- -- 
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEZ7NQTHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2GfeX5EAChFZ4pCKTj1uvCuyAxCzr12dfdfIqC
U27Bc1UwT5DAKs9T2EjihTkhstinwN3ZKLmOOznH1+lnmbdlXccYRtV4BZvu3diD
iyzP4t+5voLnxViYzO8WjHcxSlA7qNUY1/16nmOuTvrNmpaxS/54gjOyFXjdOWVc
CGCHUm2TG3aMTaW+OfOizBG+T+ThNNrkRg/8cKStgcR2vB8gwa/gJdT4qccsLCHv
ufrxVg3p7VzjVvBD7W4Z5uczqwnYR7/3FK3M65FH1TKZTCxDIv3BYGKIIEM0nXnJ
sLzFCucItVVi/Cc7CJf/sH9T49BzVfL+GTGFbDhue70+NpfOa++z7p22qq211Zvd
5E2vRXSLpQVmMY8QZy8+xDgBvi1CP1hBx98XbSE1RquV902naHowsFxTa4nkAPiK
nYU81R8TbLGwdPUXO/SgnSLQ9IlA7IotwfXmEhPAge8rYIR+2TtE0Da6ROeT8Tj4
lDiH9p6RS78Y49wihatMkpxKNkypQdUwq5AZb8p3b2j/h7hFz6l9m0TcAxxkggjZ
HPFDt0n0hGr6KzAtemFMP04OyqurMVCEtwn84ySmUI3Sy9i42uT36c2M7+TOd2iu
C2R/kXr7ZJ9fWxwpAkyv4/4rPqu2AwSeCluzUPRLTxR/8zqlTIwGK3tDlNQH3bQD
aTB5+YZvyIHIeg==
=YHqO
-END PGP SIGNATURE-



Bug#951374: RFP: gh -- the GitHub CLI

2021-08-14 Thread Brian Thompson
On 0814, Paul Wise wrote:
>
>Could also add a Provides: gh so it is installable with the short name.
>
>I would definitely like to have this in Debian, but can't help with it.
>

This would be ideal. Is there any benefit of renaming the package to
something other than "gh"?  I can help with this during the next week.

-- 
Best regards,

Brian T


signature.asc
Description: PGP signature


Bug#951374: RFP: gh -- the GitHub CLI

2021-08-08 Thread Brian Thompson
> I personally find that "gh" is quite short name for a package that
> will go into a general purpose software catalog like Debian repository. Would
> you mind choosing something like "github-cli" as source and binary
> package name and mentioning the sortcut "gh" in a package description?
> So anyone could find the program by means of `apt-cache search`.
> Acronyms gh and gn (which stands for Google's Generate Ninja) are
> visually similar, and I'm afraid they are easily confused.
>
> What do you make of this proposal?

I like that proposal and think it makes a lot of sense. `gh` does seem
too short, and while easy to identify for current gh users, maybe it
will be more difficult to find in apt for new users. Also, as you
mentioned, a namespace clash in the future seems like an uncommon
occurence.
-- 
Best regards,

Brian T


signature.asc
Description: PGP signature


Bug#802370: ITA: docbook-xsl

2021-08-07 Thread Brian Thompson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

retitle -1 ITA: docbook-xsl -- stylesheets for processing DocBook XML
- -- 
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEPClETHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2Gfd7RD/9qIBu3K1iq1mjZ5YibRc85HonHrOJb
UlHlQ7dRHPlFjYvbXsYKVZpdzQTtz3LkZvgFvldFC0LxYtWBNQzxn4X3SgGbNNRB
b/P0cMRCgHCV0EG6B6q0NhM05+t0sPyscnu4VbjwlHlEFNrr3OP0uJJh/MbSjuST
1MG1k10Ihu+B6dOFK4Mq5Fl6LqNgUoSqXcKOib72W8vgXxkwKWmoBvbc0qRGMgGn
vYcMnwaISsHLIfwmFNQaQ+0HVhX3sTrvI1273K5fdi9hAjd/nA5i74UigQwpvb1l
gvzOjfFykK7E0aKtsEGdC3NHLd9lm17JP50iJYAZZz+JH79sj+M0TCORo8SG/lOv
6p3gRrzgX5RAZPDWXDBdJwE8rNDZQCeYIBSnsui9SpyRsjH/7dasSU1aoSigOB+U
oJcof1Q4hbXA4Viam0DHvm1EzIF97R5ZBFgGPQFnD9qpRk4pckMGD0/tnBDHcCAZ
u9oSNQCmCZ02gLSW4CiYbQ+LiGWWw6LEUoPRjhK188KqjTm6A1sPs7cK1Ibe9r/z
giT6tCVa3LTyFG0hO/FMiq73owLVzOJ9UwWzq7+NRceCQIENkZkNmQ9g2Lf6Fol2
Ul2jQDjJ755MrhspW9zO1crLsjs14meKWAAExleYmmOnpSK2cB6wSjS/VTrwdZAO
KgX+FOqMhwK9FA==
=lfHp
-END PGP SIGNATURE-



Bug#802368: ITA: docbook-xml

2021-08-07 Thread Brian Thompson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

retitle -1 ITA: docbook-xml -- standard XML documentation system

- -- 
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEPCekTHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2Gfe8VEACrpLu2smZo7oiQs2uhRyDAzj+iaScg
9C3kmOcnit9VVhuPD+VXi8+nkL5lsRvmgHuLuI9aKfHXRVgie/yswrpZIQsUA/v/
kLLcEcCUCnEfQs15fru56TT3zby2Yyzrcpy7f16aVo8urZcu6izwgJDyawzrEz/L
CpX1oFa2dIJVO1kJX72z1QGCLnQkXuy+MyvmM3wvRfNcH5DSU3PYKOqGAKT5zStz
fyuinvS8akOiTrm8AhXQmDGp1shet3jP5N5IOPqHcoUu/wNmUs2BYDY91NtIXNFq
b8sYNTM5zEBDlf2MwgcyCyIzF1Zcf/GRUW0JgxMqrUsOjgaVVvGamgzyhil6hOL3
Fd4PAa2u4NhVlq/lRumCSGA9fW7O2iRZ/rj4vO1c8YaiGKD3wqaXJWeLFILvngQk
F3nvxi4qaz0oMXlYW5Jjy4lX3q/WgVUBLpXayS7DuV7o7JDhC6Y8NHrTuruR8ckn
F4Lrvj7lBJNlaTI/2uWy7o7RPuOOE7zGJWQyAeyYKQh9KlTwAy1H9d/QRh5sLv3g
/1uVu/ZNzm1Rtt3xYcHEDfkgVuvuZCmiH0WNsxbyA46quyjGDmEP15MkThrzESFv
VPWem7Lrp/I2MRb6Drwr8c3nlkPerRkbVyZS8bFDe64n/3+F+Orp2YD7WnseKd04
9ui1uOttuJXhFQ==
=CjbS
-END PGP SIGNATURE-



Bug#951374: gh cli -- Getting it ready

2021-06-16 Thread Brian Thompson
Is anyone getting the gh CLI tool ready for packaging?  If not,
I can adopt it.  I use it quite heavily and am fairly familiar
with its development team if I have any questions.
-- 
Best regards,

Brian



Bug#907576: . dream -- A Software Digital Radio Mondiale Receiver

2021-06-16 Thread Brian Thompson
Garie,

TL;DR Use an IDE or text editor on your machine.

Local IDEs/text editors are used to develop the vast, vast majority of
software.  Most developers develop on their own machines instead of in
the browser.  It doesn't make sense to develop in a browser-based IDE
(at least not yet) since they are missing vital functionality.  Whole
OSes can't be replicated in the browser, whereby the browser greatly
limits access to common development tools.

Best regards,

Brian

On June 15, 2021, GMiller  wrote:
> Hello Christoph
> >Re: GMiller > For  the subject project, I have encountered a
> roadblock while attempting to use the 'Salsa Web Terminal'. I filed
> Gitlab Issue 233 (see attachments) seeking information to prepare a
> 'gitlab-webide.yml' file (I searched but could find no documentation
> on it). The response to 233 >says "To upload designs, you'll need to
> enable LFS and have an admin enable hashed storage". 
>  >>Sorry, I can help you with packaging hamradio software, but please
> use a normal editor like everyone else. There is no need to bother
> with funky web stuff, especially if it doesn't work out of the box.
> Christoph
>
> I am not sure I understand your comment. Are you saying in effect,
> don't use a Salsa IDE to build/test the project? Instead use an IDE on
> my local machine to build/test and develop any code changes? Is that
> how most Salsa projects are doing it?
> Thanks for your patience
> Garie Miller wb9awa
> Sent with ProtonMail  Secure Email.


Bug#985669: Happy to help

2021-04-28 Thread Brian Thompson

> While I would love to package this myself, I do not work with
> JavaScript regularally (in part due to ecosystem problems like
> NPM's love of duplication).

I have some experience packaging JavaScript projects and could help you
out here.



signature.asc
Description: PGP signature


Bug#365427: [O: apt-build] Is this package worth adopting or has it been replaced?

2021-04-27 Thread Brian Thompson
On Sat, 17 Apr 2021 05:48:48 +0200 Axel Beckert  wrote:
> Hi,
> 
> No Body wrote:
> > Is this package worth adopting or has it been replaced by something
> > else?
> 
> There's nothing like it so far AFAIK. apt-src is close, but has a
> different focus (modification instead of compile-time optimization).
> 
> > I read the entire bug message history and saw that in 2016 there was some
> > development going on to replace the package.
> 
> I don't see which message you mean. In 2016, there were only control
> messages and spam in this bug report.
> 
>   Regards, Axel
> -- 
>  ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
> : :' :  |  Debian Developer, ftp.ch.debian.org Admin
> `. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
>   `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
> 
> 

Axel, switched my email address to one that I actually use. Going to start 
looking into this package more.
-- 
Best regards,

Brian



Bug#984736:

2021-04-23 Thread Brian Thompson
>Ideally a maintainer willing to help cron move forward would support the next>major task to be done: moving the Debian-specific patches into cronie and >providing an updated package for cronie replacement that can eventually>replace cron. I’d like to help out here if no one else has responded.  I can read repositories on Salsa but don’t have an account there yet since I’m not officially a part of the Debian org. >Please contact the current maintainer if you can help in maintaining and>improving cron. @Javier, I cc’ed you and I think what is Christian’s email which I pulled from the cron git history. Best regards, Brian 


Bug#365427: Autotests for apt-build utility

2021-04-16 Thread Brian Thompson
On Thu, 15 Nov 2018 23:40:07 +0300 =?UTF-8?B?0JrQvtC70Y8g0JPRg9GA0YzQtdCy?=  wrote:> I intend to do some refactoring of apt-build, but first I'd like to> write autopkgtests for the package. I have two versions of a simple test> case for install command, and I still can't decide what language use for> tests. In attachment you'll find two identical scripts in Bash and Perl.> Comments are welcome!> > It'd be good to write full tests before new year and buster freeze.> > To be clear: I'm not going to adopt the package yet, because I'm unsure> that I have enough time for this work.>  @Axel Beckert This is the message I was referring to from “2016”. I would like to adopt this package if no one else has. Best regards, Brian Thompson