| HOME | WHY | SUPPORT | DOWNLOAD | SOURCE | WIKI | NEWS | LOGO | pozol.eu |
Simply download, explode in a partition, update (pacman -Suy) install kernel and bootloader (or configure the one you already have in the system) personalize your options (username passwords timezone locale keyboard ..) and reboot your new system. If you want a graphic environment simply run the installX script and it will automatically take you to the default openbox X environment. Alternatively use seatd and labwc (openbox equivalent in Wayland) together with some more wayland and labwc utilities and use wayland.
Download from the sourceforge server and ask us any questions on the site above fpr SUPPORT.
Our previous support site at reddit.com/r/joborun will soon be abandoned as reddit has become too commercial too ad-rich and too google entangled hungry for user data.
Update: As it turns out it was a false alarm for us, the threat was oriented to attack systems running systemd and specifically debian/ubuntu/mint/fedora.. who package openssh with their own service script that triggered the backdoor. Everything has returned to normal now, most likely before any actual attacks ever took place, but it raised many guards in package building and code publishing throughout the FOSS community.
_________
For the past year or more a rogue contributor had taken control of xz repository, injected code via blobs used on checks used at compile time, altering the configure template resulting from the server's autoconf/automake, and through a "systemd-function sd_notify opens a back door to your sshd server, if you were using debian/fedora packaging. But this is all we know about it this far, it is too early to call.
Trust that the hundreds of arch devs are more alert on the risks, and now assuring that Arch wasn't affected, as a precaution we took xz off our repositories for now, use core/xz to replace. Right now xz can only be reproduced via stored source (rar ball or git we have both), but we will not publish rogue code for people to mess with. github has removed the repository, discussions on the resulting issue-discussion can only be found in the archive
As unfortunate this may be for the entire FOSS community, and for those saying that foss zstd can't possibly be a danger, it is a compression algorithm, ... WRONG if xz can induce an sshd backdoor so can zstd.
In anycase, openssh, systemd/libsystemd, xz, are all suspect in this BE AWARE and GET EDUCATED.
Here are some links to study deeper:
It is how it is and we are how we are. Aren't you happy now not having used systemd?
We were avoiding elogind, we knew it was an option, but now there are no alternatives providing sd-bus.
Major set back but not much we can do - basu part of systemd is in Joborun
BASU a systemd forked part IS IN JOBORUN's jobcomm repository!
at-spi2-core 2.52.0 requires libei which we didn't have/use but from Arch it requires systemd Building libei without systemd/libsystemd has 3 options for dependencies (libsystemd, elogind, basu) Basu is the systemd part that provides sd-bus, we had noticed before while playing with wayland crap, particularly things revolving around sway and its gadgets, that basu was a necsssity in the same manner of 3 options.
basu is a fork off of the systemd code that provides sd-bus, adopted by void (although they have elogind as well) and many BSD projects who port many linux desktops.
This problem is a little deeper than opting to avoid sway gadgets, as at-spi2-core is a "makedependency" of "pinentry" itself a core pkg, which is a dependency of gnupg.
We are not giving up, this is only one lost battle, we will investigate of building without it and also the consequences of building without it IF POSSIBLE .. to have at LEAST CORE built without parts of the PEST
But it will take some time to do this safely if in fact can be done.
As things are now gnupg --> pinentry ARE NOT built with this current at-spi2-core -- libei -- basu and still stand. But next upgrade round basu will be in the fine details of gnupg and core!
The point here is to maintain a certain high degree of compliance with the plethora of Arch packages with minimal sacrifice in systemd penetration. If for example building without it means you lose Qt or Gtk or Vte and all their dependents ... purity becomes worthless.
At times like this we understand and feel for the Hyperbola team attempting to move to OpenBSD (or was it FreeBSD or NetBSD??) and away from Linux, but as you can see part of the disease is transferring to anything craving Graphical User Interface "apps"
Bulletin #321 New installation and build images - quarenta años construyendo autonomía - a little struggle from below for data autonomy
To celebrate yesterday's 40th anniversary since darkness broke, a little light came through, and we now can no longer be innocently waiting, we know there is a way out.
We know we shouldn't work on anniversaries and holidays, we should celebrate, but we have little to celebrate here, we have 0 autonomy and a lot of work to begin constructing it, so we produced some fresh improved images to make it easier for those whose sight is pointing towards the same direction, and we some day will meet.
For information on how to do things click the link above named wiki
It may take 500 years, or 40, or 30, or 20, or 10, but can't imagine any less, so it will not be tomorrow, or next week, or next year, it is too early and we are too immature to recognize what it takes.
So back to work, enough with the celebration, avoid the hydra of IBM's systemd, facebook's zstd, NSA's ipv6, google's... everything! Lock them out, continue your work but not carelessly! Don't trust anything new, as being better, it is where the lure and hooks are hiding.
Arch Epoch is not accepted by SourceForge
It is most likely if you get such an error on installation or update it is a package that contains a colon : in the name for the Arch epoch, grub is a very common one that does.
What to do:
Reinstall jobo-mirror and follow the simple steps.
After re/installation of the pkg a directory with a script will be found in /tmp/sf01
Run the script as root, when it is done you will be able to do updates/upgrades without a 404 error from the SF server.
Explanation (why you have to do it):
This downloads a tarball [non-sf-pkgs.tar.xz](https://sourceforge.net/projects/joborun/files/r/non-sf-pkgs.tar.xz/download) explodes it, takes the packages that contain the : and moves them to /var/cache/pacman/pkg/ the default pacman cache directory. Next time you run pacman -Su it will not try to download them from sf (sourceforge) as they will all be in your cache.
It is 37 pkgs that cause the issue, it is a dirty solution, especially for those in lack of space (40MB) and a slow connection.
The alternative will be to do this per package on your own, substitute a \_ for a : (SF renames our packages this way, that is why they can't be found by pacman's curl) ~~then rename it back to the correct name and place it in cache or~~ install it directly with
pacman -U xxxname_1-yyy-yyy-01-pkg.tar.lz
when the name of the package was:
xxxname:1-yyy-yyy-01-pkg.tar.lz
So the missing packages are there it is just SF renaming them with a \_ instead of :
At least OSDN when it worked it used correct unix fs naming instead of this MicSoft filesystem SF uses, but in lack of alternatives this will have to do for now.
We can rebuild all 37 packages in a day or two, and remove the Arch defined epoch from the naming-numbering sequence, and it will be all OK with SF and pacman with no errors. Automatically this makes all 37 (+ 10 mesa packages since Aug 4 23) pkgs fall behind arch and will all show up daily as in need for upgrade. Even if you have a pkg samplepkg-9.99-99.pkg.tar.lz a pkg named samplepkg:1-0.00-01.pkg.tar.lz will appear ahead. There is no simple reasonable way to deal with this, and while we are tracking 700+ pkgs to keep up with the Arch speed-train this will cause more misses than help.
Other distros don't use the epoch at all, so mirrors with NTFS/fat32 servers can host their packages.
Our up and down, on and off, saga with OSDN came to an end after an 18 day downtime of the upload server. This not only prevented us from publishing new images but also kept joborun packages back by 3 weeks while Obarun and Arch kept rolling forward. Although none reported breakage of any applications (system wouldn't be affected in any way, but graphical integrity was being at risk), we located a new solution that is hopefully much more reliable than OSDN.
Our friends and comrades at sysdfree.wordpress.com watching our struggle to deal with the OSDN outtage, and understanding the dillema we were facing as a collective, took the liberty to create, configure, and provide us with a sourceforge server.
Our source repository remains at git.disroot.org/joborun-pkg to which an additional repository was added with the 3 pacman repo-databases, a copy of the latest pacman pkg, and joborun mirror package. This serves as an immediate update of the repositories for those building from source, as well as a backup upgrade notification means for (and if) binary mirrors go down again. git.disroot.org has been 100% reliable in our near 2 year experience with them. So pacman.conf remains unaffected from now on, all you need to select mirrors is edit /etc/pacman.d/mirrorlist-jobo which comes and will be updated by the jobo-mirror package.
We wish us a good summer without OSDN worries for sure, an uneventful transition to SF, and wish you happy installing and package building season.
For older news see previous NEWS entries
| " # |
| mmm mmm #mmm mmm m mm m m m mm |
| # #" "# #" "# #" "# #" " # # #" # |
| # # # # # # # # # # # # |
| # "#m#" ##m#" "#m#" # "mm"# # # |
| # |
| "" |