I uncommented only SBo-git repo branch & name in sbopkg.conf and did the below.

Then I selected find updates and got pages results. I went to queue and selected process but nothing happened. I went to view queue and it was empty. Same after I manually added a package to build.
Someone on slackbuilds-users mailing list reported same (all blank queues).
        Then I deleted /var/lib/sbopkg/* and selected master in sbopkg.conf and same happens. Only if I uncomment 15.0 do I not get blank queue.

hi David,

I'm not the sbopkg maintainer but I'm not able to reproduce this: if, after checking for updates, I let sbopkg add them to the internal queue, then I select "manage the queue" and then again "view the queue" the updates are actually there.
I tried this now on slackware64-current setting either the unofficial repository for current in sbopkg and SBo master branch (so this probably has nothing to do with the unofficial repository for current): sincerely why this happens for you escapes me.
I also looked in the mailing list for the other people you cite that should have experienced the same but unfortunately found nothing...

Maybe one was on Internet Relay Chat (IRC) but one replied on github and another replied on slackbuilds-users recently, so two or more others have same problem.

he is using an older version (pre-released version) of 0.38.2, based on the video he sent. Maybe you can check whether you have 2022 in the copyright year in /usr/sbin/sbopkg?
if you have 2021, then it's the older version

At 0:02

I think this is affecting the OP:

sbopkg 0.38.1:
https://github.com/sbopkg/sbopkg/blo...o-current.repo :
sbopkg 0.38.2:
https://github.com/sbopkg/sbopkg/blo...o-current.repo :
Github depreciated the "git://" URI scheme. The OP is likely still trying to connect using git protocol instead of the now required https.

Of course I redownloaded/configured the revised 0.38.2 and when had same problem upgraded/configured back to 20220318_8bf4e6a so my sbopkg never had problem synchronizing from git, just other things going wrong as someone else showed in his video about the issue on sbopkg's github (someone on slackbuilds-users thought he used to have the problem from some badly-named package he no longer has, and now no longer has the problem, but so far that's undocumented and unclear a policy prevents that).

That's not sbopkg's fault. It's just a tool that parses what's in the SBo repository

There's no question sbopkg downlaods/'parses' repository fine, but what's causing more & more problems such as rather than doing any/all command-line arguments/lines/switches it starts GUI, and (as most/all shown in video) can only check updates and make their queue, but not view nor remove from nor process (except saved & reloaded) queue? Viewing & removing have zero to do with the repository and shouldn't even have anything to do with what one has installed but apparently might.
        If you go to some really old Internet areas (Usenet or the original IRCnet/EFnet IRCs) some people don't use sbopkg & sbotools (which has its own problems so there isn't always a working package builder for Slackware-current SlackBuilds from SlackBuilds.org, SBo) & etc. nor slackpkg+ and sometimes not even slackpkg because they heard of all this breaking (maybe not slackpkg itself but slackpkg+ is known to break slackpkg and not all such people learned what others did in new forums & chats like that it simplifies installpkg & upgradepkg & reomvepkg).

the problem is i can't reproduce your issue here. It's just working as expected....

The problem is--for three or more people--no one's trying to analzye/reproduce what happened including no sbopkg debug mode/log anyone can even find any current or future problem, nor replying what packages name types could've (as someone on slackbuilds-users recalled happened) caused problems, all which mean any/all such & future problems will be unsolved.
        My only configuration differences from sbopkg.conf.new (with both 0.38.2 & 20220318_8bf4e6a) ever were sbopkg.conf REPO_BRANCH & REPO_NAME were git but after the problem, reverted to stable months ago (can save & overwrite or show with diff that git is only in comments so my sbopkg.conf is functionally identical to sbopkg.conf.new) so some things may not build, but didn't stop problems. Many months ago to earlier today renames.d & repos.d were overwritten by fresh reinstalls and remain as such. I've been using sbopkg since its first year (usage/configuration became very easy by 2010s) and these problems have nothing to do with anything I supposedly did to it; to be 100% sure I even reverted to default blacklist: all sbopkg configuration is default.
        Today I tested that default configuration after removing & installing 0.38.2 and after upgrading to 20220318_8bf4e6a (and checking sbopkg.conf.new) but problems continue.
        Apparently (if video showed) sbopkg queue submenus have errors which one doesn't necessarily need to reproduce breaking to check (nor for reasons some/all command-line options only start GUI).

can you post which command-line options that starts GUI ?

Apparently all did so problem (solved) was because I never used sbopkg command-line until recent years, and aliased to 'sbopkg && reset': often afterwards had blank terminal (no cursor nor writing appearing)... maybe I'd have to put some variables in for that to work with command-line but don't know how many.

maybe if you follow previous advices to test in clean environment, you won't have this issue in the first place

1 members found this post helpful.

'Clean environment' for bare OS 'testing usage' is rarer theoretical but most common is practical 'production usage' often more important to test and for which original problem (not later off-topic, sorry, admittedly my mistake) still exists... on github issue #79 I showed I have default configuration for sbopkg.conf (other than git lines all commented out) and renames.d & repos.d were resintalled/overwritten to default many times including after redownloading sbopkg stable & git earlier today and I even backed-up blacklist and restored it to blank (can paste all); what's not 'clean' about 100% default sbopkg configuration? Seems 'clean' even if one has every single extra Slackware package installed which could affect rebuilds but 'clean' in the sense should have zero effect on sbopkg menus though apparently likely does: I'll quote.

If he's correct then may be error in logic which possibly shouldn't exist: checking packages you can't search for (only '*_SBo' is checked for updates and all properly-named, right?) let alone update and breaking unrelated menu usage beforehand... maybe checking all packages is standard to speed-up before potential udpates (but unless there's a broken SBo package name and one displays installed/updates' or builds until package filename starts getting defined all that has zero to do with menus). A github issue #79 commenter videotaped issue though discovered convoluted workaround no one should need... didn't work for me. Since no one knows how/why reoccurence & re-asks may happen a few Zodaic ages maybe until Slackware65536 (x86-65536, etc.) runs a matrioshka system.

Okay; building in chroot maybe (or virtual machine... overkill, awkward) is 'clean environment' I may be running out of space for (37/118GB left saving for future packages, and other partition spaces saving for UNIXes)... of course if you setup one then install a 'weirdly formed package name' for first build process (among possible situations) then same may happen! Probability might be that could avoid most but unlikely all problems. I asked several places/threads about chroot with overlayfs (which can save space) and saw different topic posts closer to 10+ years ago, and an incompletely-commented script, and someone discussing various directories & statistics of their already-setup overlayfs. I can install to chroot but would have to learn overlayfs... saw no such Slackware/SBo documentation but now finally found it on kernel.org which seems a basic/overall technical specification with some/many things I'd never use and no detail how chroot can work with it and how to put in a bare OS so I'm mostly lost.

I used to ask how to chroot for post-installation liveCD-type usage for every new Slackware because more & more things are mounted which might've been relevant though for Slackware 15 finally am avoiding using installer as liveCD. Previously most/everyone ignored that actual question and mentioned virtual machines & mor & more containers (all overkill). I won't use docker even if only automates (preventing learning) chroot with overlayfs but I doubt is that simple. I recall squashfs as what *ubuntu for cell phone PC mounted every single installed 'snap' package on (even hundreds, making 'mount' output useless) which I never used but they added to desktop I administer KDE-based *ubuntu for users (who didn't think they could use command-line let alone slackpkg & sbopkg) so am avoiding squashfs and see no point of more & more containerization when chroot optionally with overlayfs sounds sufficient. I use chroot because use it on UNIX/*BSD... may not have overlayfs but one difference might be okay.

I recall I also have a Slackware-stable server with 108/139GB free which should be enough for Slackware-current chroot if it'd even work inside Slackware-stable... that server is usually off in this Northern hemisphere hot season: on first floor (USA English 'second floor'... UK English starts 'ground floor', 'first floor', ...) with no air conditioning directly to the room but is okay to run briefly at night.

Sorry if I seemed argumentative and didn't use environment with no packages (though 'weirdly formed package name' might be prebuilt first build dependency... I had such case... a package only in GFS repository became necessary for incrementing SBo lbench for my CPU). For all bugs I find I just try to help by reporting/discussing as much I have time. If other ones are important ones then skip this. I'll see if I can setup an environment with no extra packages.