joborun linux

Jwm OpenBox Obarun RUNit

HOME WHY SUPPORT DOWNLOAD SOURCE WIKI NEWS LOGO pozol.eu


March 21st 2024 Equinox: Basu, a systemd part, forces its way into our system!

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.

SO NO BASU NO ARCH BASED LINUX

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"


November 17th+ year 40: Fresh new images to celebrate partial data autonomia

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.


    August 4th 2023 - pacman error 404 - what to do:

    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.



    essential part begins here

    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.


    non-essential part begins here :)

    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.

    Another way maybe:

    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 :

    Bottom line:

    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.

    The very technical nitty bitty details and why:

    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.


    July 27th 2023 - New image host and repository structure and mirrors

    joborun SourceForge image and pkg host

    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"#  #   # 
        #                                            
      ""                                             

    The Arch Linux name is a recognized trademark
    The Obarun trademark © 2015-2022 is a registered trademark property of Eric Vidal
    Linux® is a registered trademark of Linus Torvalds
    Copyleft © 2021-2023 joborun@disroot.org
    <