* Package name : netbox Version : 3.2.8 Upstream Author : Jeremy Stretch <jstretch@ns1.com> * URL : https://github.com/netbox-community/netbox * License : Apache-2.0 and MIT/X Programming Lang: Python Description : WebUI based tool designed to manage and document computer networks NetBox is a Django based web application, initially conceived by the network engineering team at DigitalOcean, NetBox was developed specifically to address the needs of network and infrastructure engineers. It encompasses the following aspects of network management: . * Hierarchical regions, site groups, sites, and locations * Racks, devices, and device components * Cables and wireless connections * Power distribution * Data circuits and providers * Virtual machines and clusters * IP prefixes, ranges, and addresses * VRFs and route targets * FHRP groups (VRRP, HSRP, etc.) * AS numbers * VLANs and scoped VLAN groups * Organizational tenants and contacts . In addition to its extensive built-in models and functionality, NetBox can be customized and extended through the use of: . * Custom fields * Custom links * Configuration contexts * Custom model validation rules * Reports * Custom scripts * Export templates * Conditional webhooks * Plugins * Single sign-on (SSO) authentication * NAPALM integration * Detailed change logging . NetBox also features a complete REST API as well as a GraphQL API for easily integrating with other tools and systems. . While NetBox strives to cover many areas of network management, the scope of its feature set is necessarily limited. This ensures that development focuses on core functionality and that scope creep is reasonably contained. To that end, it might help to provide some examples of functionality that NetBox does not provide: . * Network monitoring * DNS server * RADIUS server * Configuration management * Facilities management I plan to maintain netbox within the Debian Python Team ideally together with some more interested people in managing the maintenance. Right now all needed build and binary package dependencies are fulfilled, as NetBox is getting actively developed it constantly bugfixes and new added features which might need new dependencies in the near future which are not packed yet. I'd like to see (if possible) the netbox package within the bookworm release. The NetBox UI is using some comprehensive JS files which are shipped as minimized files. Currently I'm unable to drop the shipped minimized code and rebuild all the needed files from scratch. If possible I'd like to get some help on this, currently netbox will need to go into non-free due the non rebuild-able minimized files. OTOH netbox can't go into main as it requires at least one package from non-free, it requires drf-yasg-nonfree for some Swagger functionality. Regards Carsten
Hello Lucas, Am 15.08.22 um 17:24 schrieb Lucas Castro: thanks, and thanks also for taking interest! I've forgotten t point to the current data and packages while writing the ITP. I'm working on packaging NetBox for almost a year now and run successful some small test installations locally and on my day job. I've uploaded locally created packages to p.d.o regularly. https://people.debian.org/~tijuca/netbox/ I'm using a Git tree within my namespace to hold up my work while working on netbox packaging, I'm taking the freedom to do force pushing to that tree as long the initial packaging work isn't uploaded into NEW. https://salsa.debian.org/tijuca/netbox The installed package is working if you going through README.Debian and proceed some steps manually. I'd like to minimize manual steps much as possible, but without bothering admins that using a central configuration management. If you want to try out the already existing package and internal packaging I'm sure you will find some points that are worth to get improved before a initial upload. I've also have some more ideas what to do, some of them I've written to wiki.d.o. If you want to extend please do so. Now the ITP is written a dedicated Wiki page about NetBox might a good thing to do. https://wiki.debian.org/CarstenSchoenert#NetBox
It also looks like drf-yasg-nonfree is non-free just because of the minimized JS files. This is often a problem and while not everybody agrees with this, you can workaround this issue by shipping the non-minified sources in debian/missing-sources. You may or may not use them in the build process. Maybe it does not hurt to try to run a minifier (like uglifyjs) on them if you feel like it. As long as upstream is using the files as is, the FTP masters are likely to accept a package with the sources in debian/missing.
Hello Vincent, Am 15.08.22 um 19:46 schrieb Vincent Bernat: your analysis about the reason is correct. The specific problem with drf-yasg is that even upstream could not fully explain how to rebuild or even collect the source files for the minimized files. This means not that this is solvable, but for me it's mostly the time factor (but also my nearly zero knowledge about the node.js universe) to entangle this all. This area is heavily moving target, unfortunately. It might happen that NetBox is dropping drf-yasg in favor of some other library. I wanted to do exactly this, but this requires a good knowledge what's going on under the hood. And currently I don't know enough how to get all these peaces together and if someone with more "how to analyze and rebuild the minimized JS" knowledge is willing to jump in would be really appreciated. If some things are more sorted out I wanted to run the yarn calling script from the NetBox sources to get some logging about the downloading of the source files and the kind of all the parts are glued together. There are some parts of the source for some minimized files are shipped by the NetBox project. But that's not all. https://github.com/netbox-community/netbox/tree/develop/netbox/project-static/src Thanks for your interest and feedback!
Upstream has released version 3.4.0 recently. https://netbox.dev/announcements/netbox-3.4.0-released/ A major change is dropping a version constrain on the depending package graphene_django < 3. https://github.com/netbox-community/netbox/commit/bbc68f948453801e44bea8b37702d5409a55c52e#diff-b8c805f9b40de096ba79f0019f8006e17731254bd521b29410a1c9574377b8d7 graphene_django is packaged in Debian by src:django-graphene, but currently there is only version 2.15.0-2 available in testing/unstable. I've looked at this package to get the recent version packaged but there is some work to do get this package updated to 3.0.0. Also the resulting binary package dependencies would need to get an coordinated upload to unstable. But as due the nature of the upstream NetBox package and it's quick and rapid development it would currently make less sense to try hard to get NetBox into bookworm, we can always provide recent version by backports. Currently I'll focus on get the Python related graphene packages updated for bookworm to there current upstream versions. Regards Carsten
Since my last email about the status usptream did finalize the first version 3.5.x. One major release goal was the moving to the OpenAPI 3.0 spec, which means a switching of the B-D drf-yasg [1] to drf-spectacular-sidecar [2]. From a packaging POV the new dependency has the quit ethe same issues as the olde ones, also drf-spectacular-sidecar use precompiled minimized JS libraries which are not easy rebuildable as no source of the used data is included in the upstream project. Also it's unclear right now how we might get the correct sources to recompile the files. Besides that there are no new additionl Debian packages needed to get a recent version of NetBox build and packaged. I was able to update the Graphene related packages in Debian to the most recent versions. The nearly similar problem to rebuild the minimized files in the NetBox source is still not solved, I haven't figured out yet how to do this. [1] https://github.com/axnsan12/drf-yasg [2] https://github.com/tfranzel/drf-spectacular-sidecar Regards Carsten
Upstream did moved on and is now alreday on version 4.x which did introduce a new dependency on strawberry-graphql and strawberry-graphql-django. These packages have a lot more direct and indirect depending packages which were not packaged yet in Debian. It took some effort and time since DC24 in Busan to work on the new missing dependencies. Now after some more work and preparations while DC25 all needed build depening and binary depending packages should now in the NEW queue and hopefully get processed and accepted soon. Regards Carsten