Bug#1008644: ITP: nala -- commandline frontend for the apt package manager

2022-03-30 Thread blake

On 2022-03-30 04:37, Stephan Lachnit wrote:

Hi,

I think this is a wonderful looking tool, and I would be willing to
sponsor this. Can you upload it to mentors.debian.net [1]?

Regards,
Stephan


Stephan,

Thanks for the kind words for Nala and volunteering to sponsor it. I've 
uploaded it to mentors.debian.net as requested. Let me know if I did 
anything wrong.


https://mentors.debian.net/package/nala/



Bug#1008644: ITP: nala -- commandline frontend for the apt package manager

2022-03-30 Thread blake

(improves… tastes are very different I guess, but that is fine.
 It reminds me of an unfinished branch though… a well, one day.)


Yes, improves here is very subjective, I agree.


Anyway, 'undo' in relation to Upgrades triggers my spider-senses as
downgrades are in general not supported.


I should probably update this in the readme, but rolling back upgrades 
is unsupported in Nala. You will receive an error if you run `undo` on 
an upgrade transaction


I have considered attempting to implement this, but it does seem like a 
bad idea. Maybe one day with a warning and an explicit flag, but for now 
there is too much other work to do.



As your entire downloading and verification process is written by you
rather than using libapt I would prefer a note here mentioning this.


I can definitely add a disclaimer saying that apt has no hand in 
downloading or verification when using Nala.




(Again, see Disclaimer. This is not a security review. I also don't 
want

 to imply that you have security bugs. Heck, perhaps libapt has more.
 My point is entirely on: Please be upfront on rolling your own)



Nala is still in active development, but it is very usable. I've had
many people ask me about getting this into the Official Debian repos 
so

this is my request for that.

I assume that I would be in need of a sponser considering I've never
uploaded anything into a Debian repository. But I did try my best to
make the debian files proper, and I personally use sbuild for building
the software.



Your 'critical' bugfix in v0.6.0 e.g.
is a bug worthy of a CVE and would need to be backported into older
versions for stable and every other release supported by Debian 
(ideally

with coordination with the other distros with embargos and such).
If Upstreams solution to that problem was so far to "just upgrade to 
the

newest version" at least one of you is in for some work (I know you are
both, its just easier to realize that these are two different jobs if 
we

pretend you are not).


There will definitely be a lot of things to get use to with having this 
in
the main repositories. But I am willing and excited to learn. I have 
packaged a few things with quilt patches so I'm a little familiar on how 
that would go for backporting.



And last but not least: If you decide you want to be a maintainer, head
over to debian-mentors and read about Requests For Sponsorship (RFS)
which helps you getting your ITP package you prepared into Debian while
you are still learning the ropes and hence do not have rights to upload
unsupervised into Debian yourself yet.

(As this is python, the python team might be interested in helping
 maintaining it if you apply to them. While I would be happy if you
 would try to interact with us from the apt team, I don't think we
 have the resources to help you with packaging through.)


I will find some time today to read up on this. I would like to be the 
maintainer as I think that may be the easiest path forward once I learn 
the ropes.


Thanks,
Blake



Bug#1008644: ITP: nala -- commandline frontend for the apt package manager

2022-03-30 Thread David Kalnischkies
Hi,

Disclaimer: As I am an APT developer, I am feeling obligated to note
that the following comment is just that, not an endorsement nor a review.
I am also not indicating interest or what not. It is just a comment.


On Tue, Mar 29, 2022 at 09:35:27PM -0400, Blake Lee wrote:
> This package is useful because it improves the UX of managing packages
> through the command line with python3-apt. Additionally provides some

(improves… tastes are very different I guess, but that is fine.
 It reminds me of an unfinished branch though… a well, one day.)


> extra quality of life features such as a transaction history you can

The README describes it as using /var/lib/nala/history.json, libapt
has /var/log/apt/history.log with I suppose roughly the some content,
although we don't have IDs in there and removing entries would be
strange. We have no interface for it so far though as we are as usual
chronically understaffed.

Anyway, 'undo' in relation to Upgrades triggers my spider-senses as
downgrades are in general not supported. The screenshots avoid that
problem supposedly by being only about installing a bunch of new
packages and eventually removing these packages again.


> […] Nala improves upon the hardwork of the apt […]

You don't mention it here, but the README features it first (after the
UI thing): Parallel Downloads.

My personal opinion on opening multiple connections to the same server
for parallel downloads aside, the bigger improvement seems to be that
you can use multiple different mirrors… except that all libapt client
can do that assuming you configure it: apt-transport-mirror(1).
(or the packages come from different sources to begin with).

As your entire downloading and verification process is written by you
rather than using libapt I would prefer a note here mentioning this.
I am of course totally biased, but I have seen enough "apt-fast"
variants doing this completely wrong while unsuspecting users were under
the impression that its just some shiny frontend on top of the good
old battle tested libapt implementations.

(Again, see Disclaimer. This is not a security review. I also don't want
 to imply that you have security bugs. Heck, perhaps libapt has more.
 My point is entirely on: Please be upfront on rolling your own)


> Nala is still in active development, but it is very usable. I've had
> many people ask me about getting this into the Official Debian repos so
> this is my request for that.
> 
> I assume that I would be in need of a sponser considering I've never
> uploaded anything into a Debian repository. But I did try my best to
> make the debian files proper, and I personally use sbuild for building
> the software.

That is two different things. A request to get it into Debian is
a Request For Packaging (RFP) – any user can ask and if the stars align
perhaps someone finds it useful enough to also want it in Debian
with the additional motivation to maintain the package within Debian
and wants to claim the work for themselves.

That is what an Intend to Package (ITP) is for. Writing debian/ once
is easy enough, the hard part is maintaining it over time. I (well,
Julian I guess, as I don't speak Python) will e.g. pester the maintainer
for this package in transitions to adapt to our newer APIs. So will the
Python teams. That might or might not align with upstream work. In
the mean time you as the maintainer (if upstream hasn't) are supposed to
interact with the security team. Your 'critical' bugfix in v0.6.0 e.g.
is a bug worthy of a CVE and would need to be backported into older
versions for stable and every other release supported by Debian (ideally
with coordination with the other distros with embargos and such).
If Upstreams solution to that problem was so far to "just upgrade to the
newest version" at least one of you is in for some work (I know you are
both, its just easier to realize that these are two different jobs if we
pretend you are not).

And last but not least: If you decide you want to be a maintainer, head
over to debian-mentors and read about Requests For Sponsorship (RFS)
which helps you getting your ITP package you prepared into Debian while
you are still learning the ropes and hence do not have rights to upload
unsupervised into Debian yourself yet.

(As this is python, the python team might be interested in helping
 maintaining it if you apply to them. While I would be happy if you
 would try to interact with us from the apt team, I don't think we
 have the resources to help you with packaging through.)


Best regards

David Kalnischkies


signature.asc
Description: PGP signature


Bug#1008644: ITP: nala -- commandline frontend for the apt package manager

2022-03-30 Thread Stephan Lachnit
Hi,

I think this is a wonderful looking tool, and I would be willing to sponsor
this. Can you upload it to mentors.debian.net?

Regards,
Stephan

On Wed, 30 Mar 2022, 03:39 Blake Lee,  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Blake Lee 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: nala
>   Version : 0.7.1
>   Upstream Author : Blake Lee 
> * URL : https://gitlab.com/volian/nala
> * License : GPLv3+
>   Programming Lang: Python
>   Description : commandline frontend for the apt package manager
>
>  nala is a frontend for the apt package manager. It has a lot
>  of the same functionality, but formats the output to be more
>  human readable. Also implements a history function to see past
>  transactions and undo/redo them. Much like Fedora's dnf history.
>
> This package is useful because it improves the UX of managing packages
> through the command line with python3-apt. Additionally provides some
> extra quality of life features such as a transaction history you can
> interact with. I use nala daily, as do many others. Similar packages
> include apt and aptitude. Nala improves upon the hardwork of the apt
> team by formatting the output in a more readable manner.
>
> At the moment I maintain this program on our GitLab. That is where we
> accept bug reports and feature requests. I don't have any problems
> accepting bug reports from Debian's system, or emails for that matter.
> I regularly accept bug reports from our GitHub as well.
>
> We currently have support for the German language, and I have someone
> working on a Spanish po file as well.
>
> Nala is still in active development, but it is very usable. I've had
> many people ask me about getting this into the Official Debian repos so
> this is my request for that.
>
> I assume that I would be in need of a sponser considering I've never
> uploaded anything into a Debian repository. But I did try my best to
> make the debian files proper, and I personally use sbuild for building
> the software.
>
> In case it is required I do have our repo already mirrored into debian
> salse https://salsa.debian.org/volian-team/nala
>
> My users would be thrilled to hear this makes it into the official
> repositories. I'm looking forward to your response.
>
>


Bug#1008644: ITP: nala -- commandline frontend for the apt package manager

2022-03-29 Thread Blake Lee
Package: wnpp
Severity: wishlist
Owner: Blake Lee 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: nala
  Version : 0.7.1
  Upstream Author : Blake Lee 
* URL : https://gitlab.com/volian/nala
* License : GPLv3+
  Programming Lang: Python
  Description : commandline frontend for the apt package manager

 nala is a frontend for the apt package manager. It has a lot
 of the same functionality, but formats the output to be more
 human readable. Also implements a history function to see past
 transactions and undo/redo them. Much like Fedora's dnf history.

This package is useful because it improves the UX of managing packages
through the command line with python3-apt. Additionally provides some
extra quality of life features such as a transaction history you can
interact with. I use nala daily, as do many others. Similar packages
include apt and aptitude. Nala improves upon the hardwork of the apt
team by formatting the output in a more readable manner.

At the moment I maintain this program on our GitLab. That is where we
accept bug reports and feature requests. I don't have any problems
accepting bug reports from Debian's system, or emails for that matter.
I regularly accept bug reports from our GitHub as well.

We currently have support for the German language, and I have someone
working on a Spanish po file as well.

Nala is still in active development, but it is very usable. I've had
many people ask me about getting this into the Official Debian repos so
this is my request for that.

I assume that I would be in need of a sponser considering I've never
uploaded anything into a Debian repository. But I did try my best to
make the debian files proper, and I personally use sbuild for building
the software.

In case it is required I do have our repo already mirrored into debian
salse https://salsa.debian.org/volian-team/nala

My users would be thrilled to hear this makes it into the official
repositories. I'm looking forward to your response.