Will Maidsafe be in Debian repositories?

I said semi-dead, not dead, but “neglected” is also fine. I just took a look: out of 8-10 repos, the Web GUI and Image Builder are alive, the rest haven’t been touched for months, some for years.

Because SAFE will have its own Web GUI and Pi comes with a complete GUI which can be accessed remotely (with VNC or MSTSC), I would rather get a “clean” Pi 2 with Linux (or Windows 10 for Pi 2) image and install SAFE on it, than install this “neglected” software which probably has dozens of unfixed bugs and security holes which will remain unfixed for months and possibly years.

I think the current status of Freedombox tells you how much interest there is in such a stand-alone package without support. A non-technical user would probably want to buy a $69.90 appliance that comes with Pi 2, Raspbian and SAFE professionally integrated and properly supported. More recently that idea has been discussed here.

1 Like

Doesn’t installing a whole GUI introduce loads of extra software that can introduce vunerabilities? I always understood it was better to have a more minimal install for server stuff.

A Cubiebox 3 & case for hard drive would be £85 ish and would have double the Ram of a Pi as well as native SATA support and USB3.

I’d anticipate for farming it would outperform a Pi with 1G Ram and USB 2 to access the drive.

I’m interested in exploring the Freedombox on Cubieboard3 plus Maidsafe package combo for my own use anyway.

No it doesn’t if you do it right. For example, you can connect to the GUI (X-Windows) over SSH.
Of course it’s better to have less stuff that runs, but normally you wouldn’t connect to X-Windows, you’d only connect once when you set up the system (then you connect Pi to your monitor) and the rest would be through a Web GUI for MaidSafe and some other apps. You could always connect to X-Windows using VNC via SSH, of course.

USB 2 is about as fast as most folks’ internet connection, but some people will want faster (at more than twice the price, though).

1 Like

@sam_uk: Excellent question - and becoming relevant now…:

Few days ago the first Rust libraries was uploaded officially to Debian - and is now waiting for ftpmaster approval: https://ftp-master.debian.org/new.html
When core Rust libraries have entered the archive we can help the Rust team adding more libraries until we reach the Maidsafe ones.

Please consider join the Debian Rust team to help package and maintain those Rust libraries.

Maidsafe browser is based on Electron, which requires a lot of Nodejs libraries. Fortunately it seems most of them are packaged by now: https://wiki.debian.org/Javascript/Nodejs/Tasks/electron

Please consider join the Debian Javascript team and help package and maintain the remeaining dependencies for electron, and then the Maidsafe browser itself.


Rust libraries are now slowly entering Debian, with second batch of core libraries getting approved by ftpmaster earlier today, and getting flagged for inclusion in Ubuntu too - as can be seen at the dashboard of the Debian Rust team.


This seems to conflict with other considerations of yours on other threads:

Something in particular made you change your mind?
Or should we still be positive?


Getting code into Debian is an important first step, but getting from there to having it long-term maintained is not a given: Apart from code continuing to be relevant enough for someone to invest the needed time in continued care for the packages, the underlying stack of dependent code need to also not evolve too fast - i.e. the developers of underlying code need to maintain a stable API.


I guess what I am trying to get at, is that we should be hopeful, but also realize that the project has better chances at living long and prosper when based on stable codebase(s) - and Electron and Nodejs has so far not proven stable.


Progress on getting safenet code officially into Debian can now be tracked at #1008016 - ITP: safe-network -- network routing and service daemon for the Safe Network - Debian Bug report logs (you can subscribe to that bugreport to get notified by email whenever it is updated).

My latest post to that bugreport also lists ways you can help (no, you don’t need to be an official member of Debian to help maintain packages in Debian).


Awesome @Jonas! Subscribed :grinning::pray:t3:


I appreciate your interest, @happybeing - means a lot to me!


Similarly, official Debian packaging of the vdash tool is now in preparation, tracked at https://bugs.debian.org/1009781


Awesome ² thank you @jonas :pray:t3::grinning:


Awsome work @jonas


Getting Safe into the Debian repositories is an absolutely great project that I wholeheartedly support!


Great! The ways you can support this work is listed in the referenced bugreports.

I am looking forward to receiving your support :slight_smile:


I am personally using yunohost it has lots of apps ready to go! had some hickups with nextcloud I dont know if I failed to maintain in somehow or it was yunohost problem

Hi @jonas

I work for Maidsafe and I’m interested in whether we might be able to provide some support for this work.

Just to be clear, this work is to enable installing two packages via apt? Like so:

apt-get install safe-network-node
apt-get install safe-network-cli

However, if I’m honest, in general I don’t know a great deal about what goes into getting anything in the repositories. I hope you might forgive my ignorance and possibly answer some questions please?

Why do you need to have a mirror of the codebase? Is that a standard thing for all packages?

I don’t completely understand what this means. Does every crate in the entire dependency graph need to also be mirrored inside this Debian Gitlab?

When you build Rust code, do you use an alternate source from crates.io for pulling in the dependencies?

How do you normally keep up to date with upstream?

What exactly do you mean here in terms of testing? That the binaries would install correctly? Or that they run and work correctly?

I notice your version, 0.46.5, is very old. Development of the network has been proceeding so fast, that this will bear almost no resemblance to what we have now. Can we get a newer version?




Hi @chriso

Correct, the goal of my work is that on an official pristine Debian system you can type (your commands above, or) apt install safe-network-node safe-network-cli and get sn_node and sn_cli installed - integrated with the system, and security-tracked and upgraded as integral part of that.

Yes: All code distributed as part of Debian must be built from source in a pristine Debian environment, and must be possible to rebuild using only the distributed system.

Yes (in one interpretation of your question): All crates must be included in source form as part of Debian, and built from source to produce all binary packages part of Debian.

Needed code (crates and C libraries and build tools) need to be included with Debian, but need not be duplicated in each source package. In fact it is strongly discouraged to duplicate code in Debian, which is the main reason the current draft package is not released into Debian yet: I want to reduce the amount of embedded crates, ideally to zero, before formally pushing it to Debian.

Also, Salsa is not officially part of Debian, but is just a common (by far!) place to prepare packages to be pushed to Debian. Debian predates the invention of git, and a “Debian source package” really is a couple of tarballs (one with upstream code and one with packaging code) and a cryptographically signed metadata file.

But loosely speaking, yes: All crates in the graph must be packaged for Debian!

Yes: When a Debian package is built only other binary Debian packages can be pulled in as build-dependencies.

So each and every build-dependency need to exist as a Debian binary package (or cheating and embedding, as I do now for the draft package).

I normally maintain packages with a "slightly slower release frequency :wink:

[Not sure if you are asking how well I usually keep up, or how I techincally do, or…]

For each package update (ideally each upstream release, but can skip some or many upstream releases, there is no strict rule), I download the upstream release tarball (or when that is not available - as is the case for crates - I synthesize a tarball from upstream git release tag), and update my packaging tarball to align with that newer upstream code.

I maintain (alone or as part of teams) roughly 600 packages in Debian. By far the most of them have much fewer dependencies than to this one, though.

Here I meant invitations for regular not-so-geeky users to help out.

…but I guess your interest is more how strong testing we can expect.

Currently there is very sloppy testing: I simply execute cargo test, skipping some tests I experienced failing (likely because they rely on network but maybe I miss some environment setup) and ignore the result.

Obviously I hope that can change to check all tests and to fail the build if any of the tests fail.

Besides the build-time testing I also expect to add runtime tests, when package is officially in Debian and I can rely on Debian infrastructure for that.

Perhaps it is helpful to you to see how a Debian developer “dashboard” looks like - here is one for another (very simple) Rust package: precious - Debian Package Tracker

And here is one for a non-Rust package with test failures, that has caused the package to be kicked out of the “testing” branch of Debian: eye - Debian Package Tracker

Certainly: The version listed in initial post of the “ITP” (intent to package) bugreport reflects where work initially began, more than 4 months ago. To check which version the packaging is currently aligned with, see topmost section of the package changelog.

Feel free to ask more questions. We can also meet for an audio chat if you like - I host a lightweight videoroom service myself at https://live.jones.dk/ that I prefer to use for that purpose. Just say a time that is suitable for you - I am generally online and flexible with time (rarely in fixed-time meetings).


Here’s a summary of reasons MaidSafe might appreciate their code being officially in Debian: AdvantagesForUpstream - Debian Wiki